Responsible Disclosure

Security issues in this codebase — authentication, session handling, access control between accounts, the SSRF guards, the scan input validation, or the audit chain — are in scope. So are issues in a specific deployment's configuration, reported to whoever runs that deployment.

Findings that this application reports about your own scanned targets are not disclosures against this project; those are simply scan results.

• Report it to whoever operates the specific deployment you found it in, privately, before any public disclosure.
• Do not access, modify, or exfiltrate data belonging to a deployment you don't operate or have explicit written authorization to test.
• Give the operator reasonable time to remediate before disclosing publicly.
• Include enough detail to reproduce: the affected route or component, the account role you were using, and what you expected to happen instead.

Before reporting, check the Security Policy. Its known-limitations section documents the gaps that are already understood and deliberately disclosed — no encryption at rest, in-memory rate limiting, the residual DNS-rebinding window on webhook delivery, and the audit chain living in the database it protects, among others. A report that restates one of those is still welcome, but it will not be news.

If you are standing this application up for a team or organization, replace this page with your actual security contact — an email address or a security.txt reference — before anyone relies on it. A disclosure policy with no reachable contact is worse than none, because it implies one exists.