The following advisories were identified and remediated prior to their respective releases. Documented here for transparency.

⚠️ Reference architecture notice: CAGE is a reference architecture and is not deployed to production. These advisories are tracked for completeness and to ensure the codebase accurately represents the security posture claimed in associated research publications.

Please do not report security vulnerabilities through public GitHub issues.

To report a security vulnerability, please use the GitHub Security Advisory "Report a Vulnerability" feature.

Alternatively, you may email the maintainers directly. Please include:

• A description of the vulnerability and its potential impact
• Steps to reproduce the issue
• Any proof-of-concept code (if applicable)
• Your suggested fix (if you have one)

You should receive a response within 5 business days. If you do not receive a response, please follow up to ensure your report was received.

We follow a coordinated disclosure model:

1. You report the vulnerability privately.
2. We confirm receipt and begin investigation within 5 business days.
3. We develop and test a fix.
4. We release the fix and publish a security advisory.
5. You may publicly disclose the vulnerability after the fix is released, or after 90 days from the initial report — whichever comes first.

The following are in scope for security reports:

• Remote code execution in the governance gateway or compliance bridge
• Authentication/authorisation bypass in the governance pipeline
• Governance tier bypass (violations of the NoDirectBind invariant)
• Injection vulnerabilities (prompt injection, SQL injection, etc.)
• Cryptographic weaknesses in the Cloud KMS signing, HMAC-SHA256 fallback, or SHA-256 hash-chain implementation
• Control Barrier Function (CBF) race conditions or invariant violations
• Secrets or credentials exposed in the repository

The following are out of scope:

• Vulnerabilities in third-party dependencies (report these upstream)
• Denial-of-service attacks requiring physical access
• Social engineering attacks
• Issues in documentation only

CAGE is designed for regulated financial services environments. Key security controls are documented in:

• docs/security/SECURITY_STATUS.md — full security posture, NIST RMF status, and all open POA&M items
• docs/architecture/GATEWAY_ARCHITECTURE.md
• deployment/k8s/K8S_SECURITY_HARDENING.md
• COMPLIANCE.md

Note: CAGE v2.1.x has not received a NIST Authorization to Operate (ATO). Regulated-environment deployers must conduct their own risk assessment before production use. See docs/security/SECURITY_STATUS.md for the complete posture breakdown and pre-deployment checklist.

Replay-attack closure (2026-08-06): KMS-signed reconciliation payloads now embed a signed_at Unix timestamp. The verifier (KmsSigner.verify()) rejects any payload where now - signed_at > 300 s (MAX_KMS_PAYLOAD_AGE_SECONDS). Previously, a compromised agent with Redis write access could overwrite a validly-signed payload immediately before TTL expiry, resetting the verification window indefinitely. This vector is now closed.

Causal Gatekeeper fail-closed hardening (2026-08-06): The CausalGatekeeper's Redis fallback is now fail-closed: connection errors raise RuntimeError("Redis unavailable: cannot compute deflection rate; failing closed") rather than returning a zero-deflection sentinel. Absent Redis keys (cache miss on first boot) continue to return None safely. The previous fail-open behaviour created an attack surface: an adversary disrupting Redis connectivity during evaluation could suppress FPR reporting.

FTRA trust-boundary note: Tier 0.5 (FTRA) currently executes at the LangGraph graph level, inside the untrusted reasoning plane (Plant). An adversarial agent with direct HTTP access to the Controller could bypass this check. Hardening options include moving the FTRA check to the Controller ingress boundary or enforcing it via a cryptographic capability token. This is tracked as a security limitation.

CBF intra-window double-spend hardening (2026-08-06): The CBF now tracks _local_debits locally between reconciliation snapshots. effective_balance = snapshot - local_debits is used for all threshold checks, preventing repeated trades within the same 300 s snapshot window from being evaluated against the same un-decremented balance.