Please report security issues privately, not as a public issue.

Use GitHub's private vulnerability reporting on this repository. That opens a draft advisory only the maintainers can see.

Useful things to include:

• what an attacker can do, and what access they need to start
• affected version (red-clippy --version) and platform
• steps to reproduce, ideally against a fresh red-clippy serve
• a proof of concept, if you have one

Please give us a reasonable window to ship a fix before disclosing publicly.

This is a young project with no long-term support branches. Fixes land on main and go out in the next tagged release. Please confirm an issue against the latest release before reporting.

Red Clippy is an operator tool. It is designed to run on a machine you control, bound to 127.0.0.1:7337 by default, and used by the testers on an engagement. It is not hardened for exposure to the public internet, and there is no bug bounty.

That framing matters for triage:

In scope. Anything that lets one organization's data reach another (engagements are the tenancy boundary and it must hold), authentication or session bypass, API keys leaking or being forgeable, path traversal out of storage_root, SQL injection, and code execution triggered by content Red Clippy ingests. That last category is the interesting one: scanner output, evidence files, and observations all originate from the systems under test, so they are attacker-influenced by definition. A malicious nmap XML or an uploaded .svg that runs script in the panel's origin is a real finding.

Out of scope. Missing hardening that only matters when the server is deliberately exposed: the absence of the Secure cookie flag (terminate TLS upstream and set it there), no CSRF tokens on the session-cookie path, no rate limiting on login, and no Content-Security-Policy. Also out of scope: anything requiring an already-authenticated operator to attack their own instance, and the behaviour of local_open, which shells out to the host's file manager by design and ships disabled.

If you are unsure which side of that line something falls on, report it and say so.

Everything lives in a local SQLite database and storage_root on the machine running the server. Nothing is sent anywhere else: there is no telemetry, no crash reporting, and no update check that phones home. Passwords are hashed with Argon2id and API keys are stored as SHA-256 of the full token.