Skip to main content
Security fixes are provided for the latest published release of cc-safety-net. If you use an older version, upgrade before you report an issue unless the vulnerability also affects the latest release. This page explains how to report an issue. For trust boundaries, fail-closed enforcement, and attack surface, see Security model. The canonical policy is SECURITY.md in the source repository. A command that was not blocked is a public bug. Harmful behavior by CC Safety Net is a private vulnerability. If you are not sure which report you have, read Choose a public or private report. If you still need to diagnose the behavior, start at Troubleshooting.

Report a vulnerability privately

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 this information when it is safe to share:
  • The affected cc-safety-net version
  • Your operating system and runtime version
  • The affected integration, such as Claude Code, OpenCode, Gemini CLI, GitHub Copilot CLI, Grok Build, or Codex
  • 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
  • Whether the issue can cause data loss, command execution, secret exposure, or another concrete security impact
Redact tokens, credentials, private repository names, and sensitive file paths before sending logs or command output.
explain and doctor output is not automatically safe to attach. Redaction covers recognized credential shapes only. The output includes the command text you supplied, its parsed tokens, absolute paths including your home directory, hostnames, and your configuration paths. Reproduce the issue with placeholder credentials and read the output before you send it.

Choose a public or private report

CC Safety Net stops agents from running destructive commands within the selected safety level’s documented guarantees. A report that the tool failed to do that job is a bug, and it belongs in a public GitHub issue. The strict and paranoid threat model assumes that an attacker can emit any destructive command through prompt injection or adversarial context. Publishing “this command shape is not caught” does not give the attacker a new capability. It helps fix the gap faster and lets users add a custom rule as an immediate workaround. If the tool itself leaked a secret, wrote a file outside its own directory, or shipped a tampered package, report a vulnerability. The method that caused this harm may not be obvious, so report it privately. Use this dividing line: did the tool fail to stop a destructive command, or did the tool itself cause the harm?

What counts as a security issue

Report these privately:
  • Leakage of secrets through block messages, audit logs, diagnostics, debug output, or a false-positive report prefill, including a redaction bypass for a specific token format or a path the report preview claims to have replaced
  • 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. This includes a coverage gap for a command the rules do not block yet, a parser, tokenizer, or wrapper-analysis edge case, or an analysis error that allows a command instead of blocking it. Report the command shape, not a ready-to-paste weaponized prompt-injection payload.
  • False positives where a safe command is blocked
  • Missing convenience rules or new feature requests
  • Documentation bugs
  • Installation problems without a security impact
  • Questions about custom rules or configuration
Grok Build hooks are fail-open by design, and the host exposes no failClosed knob. Only an explicit deny on stdout blocks a tool call, so a hook that crashes, times out, or emits malformed output lets the call proceed. The adapter still emits an explicit deny for its own fail-closed outcomes, such as truncated tool input or an unusable working directory. A failure that leaves the adapter with no output at all does not block the call on this host. That is host behavior, not a coverage gap.
A destructive-command coverage gap stays public even when it looks severe. It is not reclassified as a vulnerability. Use the private path only for the categories listed above. A command allowed under standard mode’s documented relaxations is not a gap. Standard is best-effort, while strict and paranoid fail closed on those forms.

What happens after you report

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. Give the maintainer reasonable time to investigate before you publish details. When a vulnerability is confirmed, the maintainer publishes a fix as soon as practical. The maintainer can also publish a GitHub security advisory or release note with appropriate credit unless you request otherwise. Do not disclose exploit details until a fixed version is available.
Last modified on August 26, 2026