Security fixes are provided for the latest published release of cc-safety-net. If you are running an older version, upgrade before reporting an issue unless the vulnerability also affects the latest release. This page covers reporting; for the trust model, fail-closed enforcement, and attack surface, see Security Model. The canonical policy is SECURITY.md in the source repository.
Reporting a vulnerability
Do not report security vulnerabilities in public GitHub issues. Use GitHub private vulnerability reporting for the repository when available. If that is unavailable, email the maintainer at jliew@420024lab.com.
Include as much detail as you can safely share:
- The affected
cc-safety-net version
- Your operating system and runtime version
- The affected integration (Claude Code, Codex, Copilot CLI, Gemini CLI, Kimi Code, OpenCode, or Pi)
- Steps to reproduce, and the command or input that bypasses, weakens, or abuses CC Safety Net
- Any relevant output from
cc-safety-net explain or cc-safety-net doctor
- The concrete impact: data loss, command execution, secret exposure, or something else
Redact tokens, credentials, private repository names, and sensitive file paths before sending logs or command output.
The boundary: bug or vulnerability?
CC Safety Net’s job is to stop agents from running destructive commands. A report that the tool failed to do that job is a bug, and it belongs in a public GitHub issue. The threat model already assumes an attacker (prompt injection, adversarial context) can emit any destructive command, so publishing “this command shape is not caught” does not hand the attacker a capability they did not already have — it just gets the gap fixed faster and lets users ship a custom rule as an immediate workaround.
A report that the tool did something harmful it was never supposed to do — leak a secret, write a file outside its own directory, or ship a tampered package — is a vulnerability. The non-obvious construction is the secret, so it belongs in private disclosure.
The dividing line is: did the tool fail to stop a destructive command, or did the tool itself become the harmful vector?
What counts as a security issue
Report these privately:
- Leakage of secrets through block messages, audit logs, diagnostics, or debug output, including a redaction bypass for a specific token format
- A path traversal or filesystem issue in audit logging or configuration handling, where crafted input writes outside the intended directory
- A supply-chain or packaging issue affecting the published npm package or plugin distribution, including rulebook integrity
What belongs in public issues instead
Use normal GitHub issues for:
- Any bypass or fail-open that lets a destructive command execute — a coverage gap (a command the rules do not block yet), a parser, tokenizer, or wrapper-analysis edge case, or an analysis error that lets a command through instead of blocking it. Report the command shape, not a ready-to-paste weaponized prompt-injection payload.
- False positives (safe commands blocked)
- Missing convenience rules or feature requests
- Documentation bugs
- Installation problems without a security impact
- Questions about custom rules or configuration
Response and disclosure
You should receive an initial response within 7 days. The maintainer will work with you to confirm the impact, identify affected versions, prepare a fix, and coordinate disclosure. When a vulnerability is confirmed, a fix is published as soon as practical, optionally with a GitHub security advisory and credit unless you request otherwise. Please do not publicly disclose exploit details until a fixed version is available. Last modified on June 23, 2026
