Required policies

We require that all researchers:

• Do not access customer or employee personal information. If you accidentally access any of these, please stop testing and submit the vulnerability.
• Do not degrade the user experience, disrupting production systems, or destroy data during security testing.
• Use the WhiteHub report submission form to report vulnerability information to us.
• Collect only the information necessary to demonstrate the vulnerability.
• Submit any necessary screenshots, screen captures, network requests, reproduction steps or similar using the WhiteHub submission form (you can use third-party file sharing sites but you have to make sure they are not disclosed to anyone other than us).
• When investigating a vulnerability, please only target your own account and do not attempt to access data from anyone else’s account.
• It is compulsory for you to send all questions and reports to WhiteHub so that we can ensure your benefits and avoid any unnecessary problems. Please do not directly contact the business.
• Public discussion about this program is not permitted
• Your report is not allowed to disclose publicly without our consent. In case of the agreement reached, we can disclose your report on WhiteHub.

Violations will be dealt with by warning, refusing to reward or permanently banning the account on WhiteHub

Qualifying vulnerabilities

Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:

• Sensitive information leakage (e.g., private keys wallets, seeds, shielded transaction de-anonymization, etc), public keys are excluded from this scope
• Transaction/certificate tampering (e.g., Changing the recipient address or amount)
• Transaction/certificate replay without majority mining hashrate (e.g., double-spend)
• Transaction/certificate withholding (e.g., censorship of transactions)
• Coin supply inflation (e.g., minting more coins than intended by the emission schedule)
• Bugs that cause the service to crash (e.g., Non-network-based DoS)
• Remote code execution vulnerabilities (proof of concept required)
• Attacks that result in harm to the quality of the blockchain or linked/neighbor nodes (e.g., attacks causing DoS score increase of honest behaving neighbours, etc)
• Effective non-network-bandwidth-flooding DDoS attacks (e.g., transaction hammering, etc)
• Bugs that cause bypassing of certificates’ acceptance validation rules
• Bugs that cause the software to behave in a different way from the expected behaviour defined in the Cellframe whitepaper

Non-qualifying vulnerabilities

Depending on their impact, some of the reported issues may not qualify. Although we review them on a case-by-case basis, here are some of the common low-risk issues that typically do not earn a monetary reward:

• Mainnet use of software is out of scope
• Any attack requiring the majority of the mining hashrate
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Missing best practices in SSL/TLS configuration.
• Any activity that could lead to the disruption of our service (DoS).
• Rate limiting or bruteforce issues on non-authentication / local endpoints (e.g., RPCs, websocket)
• Missing best practices in Content Security Policy.
• Missing HttpOnly or Secure flags on cookies
• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.), email spoofing
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.
• Open redirect - unless an additional security impact can be demonstrated
• Issues that require unlikely user interaction