Responsible disclosure

NightHall is not released yet, and this page exists before it needs to rather than after. A researcher who finds a problem should be able to read what will happen to their report without sending it first.

Where to send it

security@nighthall.io is the security address. It is also published in /.well-known/security.txt, which is the file a scanner or a reporter reads without asking us first, so the two never disagree.

While that address is still a placeholder, the general address info@litenova.solutions reaches the same person. Say in the subject line that it is a security report, so it is not filed as a support question.

What to send

• What the problem is, in a sentence a person can act on.
• How to reproduce it, ideally as the smallest request that shows it.
• What an attacker could do with it, and what they cannot.
• Which surface it is on: the webshop, the dashboard, the door client, the control panel, the API, or this website.
• Whether anyone else knows, and whether it is published anywhere.

What to expect

• An acknowledgement within one business day.
• An assessment within five working days, and an estimate of what happens next.
• A fix before disclosure, or an agreed date by which one will come.
• Credit in the changelog or the release notes if the reporter wants it, and a place to point at as the reporter of the issue.

What is asked of the reporter

• No public disclosure before the fix is in place, and never before an agreed date.
• No access to data that is not needed to demonstrate the problem. A proof of concept on synthetic data is as convincing as one on real buyer details.
• No denial of service, no persistence, and no social engineering of organizers or buyers.
• A reasonable window to respond. Ninety days from acknowledgement is the normal expectation.

The deadline

If a problem is not fixed within ninety days of acknowledgement, it may be disclosed. That is a limit rather than a threat, and NightHall would rather be found late by a reporter than never.

What is out of scope

• A missing response header on a page that sets no cookie and takes no input.
• The absence of a security header that has no effect on a static page that takes no input to inject.
• A rate limit that exists and is documented, where the report is about its exact number rather than its absence.
• Self-harm, spam, and reports against an organizer's own content, which belong to the organizer and are on the content notices page.