On August 5, Novee Security demonstrated at Black Hat USA how two widely used AI coding assistants could leak CI/CD secrets through a simple attack: a crafted GitHub issue. Both Anthropic's Claude Code and Google's Gemini CLI, running in their default configurations, allowed unauthorized code execution that could exfiltrate workflow secrets, API tokens, and environment variables.
The vulnerabilities received CVE assignments and patches, but the incident highlights a broader problem: your CI/CD pipeline's trust boundaries weren't designed for AI agents that autonomously fetch and execute code suggestions.
What Happened
Novee Security researchers found that both tools would process specially crafted GitHub issues as if they were legitimate code context. When an AI coding assistant runs in a CI environment and encounters one of these issues, it treats the malicious payload as a coding suggestion and executes it within the workflow context.
These tools integrate directly into CI/CD pipelines to provide AI-assisted code reviews, automated fixes, and development suggestions. They run with the same permissions as your build process, which typically includes access to:
- Repository secrets (API keys, database credentials)
- Cloud provider tokens
- Container registry credentials
- Third-party service authentication
An attacker doesn't need repository access. They only need to create a public GitHub issue that references your repository or gets indexed by the AI tool's context-gathering mechanism.
Timeline
Before August 5: Both tools shipped in default configurations that allowed external issue processing in CI contexts.
August 5: Novee Security presented findings at Black Hat USA, demonstrating live exploitation of both platforms.
Post-disclosure: CVE-2026-12537 assigned to Gemini CLI (CVSS v4: 10.0), CVE-2026-54316 assigned to Claude Code.
Current status: Both vendors have released patches. Default configurations have been updated to restrict external input processing in CI environments.
Which Controls Failed
The core failure wasn't a code bug. It was an architectural assumption that broke when AI agents entered the CI/CD trust boundary.
Input validation at the CI boundary: Neither tool treated external GitHub issues as untrusted input when running in CI mode. Your pipeline probably validates webhook payloads and checks branch permissions, but these AI tools introduced a new input vector that bypassed those controls.
Least privilege in CI contexts: The tools ran with full CI workflow permissions rather than a restricted subset. If they only needed read access to repository contents, they shouldn't have had access to secrets.
Secrets exposure to AI context: Both tools could access environment variables and secrets that should have been isolated from code analysis processes. Your secrets manager might enforce rotation and encryption at rest, but it can't prevent exposure if the CI runtime hands credentials to every process.
Default-deny for external integrations: The default configuration allowed external content processing. Secure defaults would require explicit opt-in for any external input in CI contexts.
What Standards Require
NIST 800-53 Rev 5, Control SA-15(8) requires continuous monitoring of developer security practices and tools. When you add an AI coding assistant to your CI pipeline, that's a new tool in your SDLC that needs the same scrutiny as any other build dependency.
ISO/IEC 27001:2022, Annex A.8.31 implies that your CI environment should enforce boundaries between code analysis tools and production secrets. If your AI assistant can read the same environment variables as your deployment scripts, you've violated this separation.
PCI DSS v4.0.1, Requirement 6.3.2 mandates that custom software is developed securely according to industry standards. If you're using AI tools to generate or review code in scope for PCI, those tools must not introduce new vectors for secrets exposure. The requirement doesn't exempt AI-generated code from secure development practices.
SOC 2 Type II, CC6.6 requires that access to data and system resources is limited to authorized users. Your CI secrets are system resources. An AI tool that processes untrusted external input without validation fails this control.
The CVSS scoring discrepancy is worth noting: Anthropic rated CVE-2026-54316 at 6.0 (Moderate) under CVSS v4, while NVD assigned 9.1 (Critical) under v3.1. This isn't just a version difference. It reflects different assumptions about attack complexity and scope. For your risk assessment, use the higher score unless you've documented specific mitigating controls in your environment.
Lessons and Action Items
Audit your CI integrations for AI tools: List every AI assistant, code analysis tool, and automated suggestion system that runs in your CI environment. For each one, document:
- What secrets or environment variables it can access
- What external inputs it processes (API calls, repository references, issue content)
- Whether it runs with the same permissions as your build process
Implement least privilege for code analysis: Create a separate CI job for AI-assisted code review that runs in an isolated environment without access to deployment secrets. It should only read repository contents and write analysis results. Your deployment jobs can consume those results without exposing credentials.
Default-deny external content in CI: Configure AI tools to ignore external issues, pull requests from forks, and any input that didn't originate from your authenticated team members. If you need external contributions, route them through a manual review step before AI processing.
Separate secrets by job purpose: Your code analysis jobs don't need production database credentials. Use your CI platform's secrets scoping (GitHub Actions environments, GitLab CI protected variables) to limit which jobs can access which secrets.
Monitor AI tool permissions: Add detection rules for AI coding assistants that attempt to access secrets outside their documented scope. If your code review tool suddenly reads AWS credentials, that's an indicator of compromise or misconfiguration.
Test your isolation: Create a test repository with a planted secret and a malicious issue. Run your AI tools against it in a staging CI environment. If they can exfiltrate the test secret, your production secrets are at risk.
The broader lesson: every new tool you add to CI/CD inherits the trust level of your build process unless you explicitly constrain it. AI coding assistants are powerful, but they're also parsers of untrusted input. Treat them accordingly.
