Coordinated Vulnerability Disclosure (CVD) guideline for security researchers

If you have found a technical vulnerability in one of Neurohr Bytes Software's systems (like the portal you are currently visiting), you can report this directly to our development team (see below).

If you found a vulnerability in an IT system or IT product that does not belong to Neurohr Bytes Software e.U., the vulnerability should first be reported to the owner of the system or the manufacturer.

We promise,

• To keep each vulnerability report confidential to the extent permitted by law
• not to pass on personal data to third parties without your explicit consent
• to give feedback on every vulnerability report made.
• not to pursue criminal charges against you as long as you have complied with the Policy and Principles. This does not apply if recognizable criminal intentions have been or are being pursued.
• to be the contact person for a trusting exchange throughout the entire process.
• after completion of a CVD process, if desired, to publish your name/alias and a desired reference on our acknowledgment website.

If you have provided personal data in the report, please note our data protection policy.

We expect from you:

• The vulnerability found was not abused. This means that no damage was caused beyond the reported vulnerability.
• No attacks (such as social engineering, spam, (distributed) DoS or "brute force" attacks, etc.) were carried out against IT systems or infrastructures.
• No manipulation, compromise or modification of possible systems or data of third parties was carried out.
• No tools for exploiting vulnerabilities have been offered for a fee or free of charge that third parties could use to commit crimes.
• The vulnerability reports are not results of automated tools or scans without supporting documentation. These are not valid vulnerability reports.
• The vulnerability report relates to previously unknown information. Your report will be checked for vulnerabilities that have already been fixed, but they do not qualify for further processing as part of the CVD process.
• Valid contact data (e-mail address) is stored so that we can contact you in the case of further inqueries regarding your report. In the case of complex vulnerabilities in particular, it can not be ruled out that we will need further explanations and documentation. Since good communication is important during a CVD case, vulnerability reports without communication options (i.e. valid contact data) are only processed to a limited extent.

Vulnerability reports via Signal (preferred method)

For the quickest response time, please contact +43-680-2311-673 via the Signal messenger.

Vulnerability reports via E-Mail

Researchers who use their own reporting format (e.g. via PDF or txt) can also send vulnerability reports and coordination requests directly to Neurohr Bytes Software e.U. at [email protected].

A vulnerability report should contain the following information:

1. The name of the manufacturer/product owner and whether contact was established with them.
2. The name of the product and the tested version number.
3. A simple description (if necessary screenshots or other illustrations for better comprehensibility) showing how the vulnerability was discovered (including any tools used).
4. An assignment of the vulnerability to the OWASP Top 10 (preferably in the most current version) (see https://owasp.org/www-project-top-ten). If none of the vulnerability categories fit, this should be described in more detail as "Other"
5. Must include proof-of-concept (PoC) code or instructions showing how the vulnerability can be exploited.
6. An (informal) declaration of consent to include a name/alias in the recognition website (Hall of Fame) of Neurohr Bytes Software e.U. if desired
7. A risk assessment, taking into account the technical conditions to determine the severity of the vulnerability (e.g. by using a CVSS value and the associated matrix -- preferably in the most current version).
8. A description of the impact of the reported vulnerability or a threat model that describes a relevant attack scenario.