Vulnerability Disclosure Policy
This service accepts private security reports intended to help us remediate vulnerabilities responsibly. For non-security issue reports, see the Issue Reporting Terms instead.
Current reporting path
Security contact metadata is published through RFC 9116 security.txt. During the current project stage, detailed reports should still be submitted privately through the authenticated in-app bug reporting flow (via Contact) or the contact path referenced from security.txt. Do not submit proof-of-concept exploits, malware, or destructive test traffic against systems you do not own or control.
What to include
- A clear description of the issue
- Affected URL, route, feature, or component
- Reproduction steps
- Impact assessment
- Screenshots, logs, or safe proof-of-concept material when needed
Out of scope
- Social engineering
- Denial-of-service testing
- Spam or automated scanners without analysis
- Reports that require violating laws, contracts, or third-party rights
Safe-harbor expectations
We expect good-faith research that avoids privacy violations, data destruction, service disruption, and persistence in user or infrastructure environments.
Response expectations
We aim to acknowledge valid reports, assess severity, remediate in a reasonable timeframe, and keep a documented internal record of the handling process.
Current limitation
This project now publishes security.txt and a public disclosure policy, but it still needs a final production mailbox, formal triage SLA, and external intake workflow before a broad public launch.