A GitHub issue could hijack Claude Code and Gemini CLI

Anyone can open a GitHub issue. That is the whole point of them.

At Black Hat USA on August 5, researchers showed what happens when an AI agent reads one. On several repositories, filing an issue was enough to run code on the build machine behind it.

The repositories were not obscure side projects. They belonged to Anthropic, Google and OpenAI, and they were running each vendor's own coding agent.

Key Takeaways

• Novee Security demonstrated three separate attack chains against Claude Code, Gemini CLI and OpenAI Codex, all reachable from an unprivileged GitHub issue.
• The Gemini CLI flaw scored a perfect 10.0 on CVSS, and Google fixed it by changing the trust model rather than patching a workflow.
• None of the three required a misconfiguration. Every chain worked against shipped defaults, which is why upgrading matters more than tightening settings.

What the researchers actually broke

Prompt injection is the trick of hiding instructions inside content a model reads, so the model follows the attacker instead of its operator. That part is old news by now.

What is new is where the instructions landed. They landed on a build server holding live credentials.

A GitHub Actions runner is the temporary virtual machine that executes a repository's automation. It normally holds a token for the repository and any API keys the workflow needs. Code execution there is not a sandbox escape. It is a key handover.

Novee Security walked through all three chains in its Black Hat write-up, and the conference coverage at eSecurity Planet confirms the same three vendors were affected.

Product	Identifier	What an issue could reach
Claude Code Action	CVE-2026-54316	Code execution on the runner, then workflow secrets
Gemini CLI action	GHSA-wpqr-6v78-jr5g, CVSS 10.0	The parent process environment, including the repository token
OpenAI Codex action	No CVE assigned	Standing control of a second agent pass

How the Claude Code chain reached the runner

The Claude Code bug is the most instructive of the three, because the guardrail was there and simply looked the wrong way.

Claude Code Action screens shell commands before running them. The screening stripped quoted text before it inspected the command. So a push command carrying a payload inside quotes was inspected as if the quotes held nothing.

Git then executed that payload. Flag injection is exactly this: smuggling behaviour into an option value that a validator treats as inert text.

Two more rounds followed. One read files the allowlist was supposed to protect, because a second read command had no path checking. The last round is the clever one, and it is the reason the CVE exists. The agent was pre-approved to fetch Hugging Face URLs, so the researchers leaked an API key one character at a time through public download counters.

Anthropic's fixes were structural. It replaced wildcard push matching with an explicit allowlist, removed most shell tools, turned off report display by default, and narrowed the Hugging Face permission to documentation paths.

The Gemini CLI bug that scored a perfect 10

A CVSS score of 10.0 is rare. CVSS is the industry's severity scale, and a 10.0 means the worst rating on every axis at once.

Two mistakes stacked here. First, the tool restriction was checked with a prefix match, so a narrow shell permission registered the unrestricted shell tool instead. Second, the runtime never rechecked the allowlist at all.

Google's answer was not a workflow patch. It shipped a change to the trust model for headless execution, replacing environment scrubbing with real process isolation. Coverage of the perfect-10 advisory makes the practical consequence clear. A configuration tweak will not save you. Only the upgrade will.

The scrubbing failure is worth pausing on. The parent process handed the child a cleaned environment. But both ran as the same user in the same process namespace, so the child could simply read the parent's environment back out.

Why the Codex finding never got a CVE number

The Codex issue is not a memory bug or a parser bug. It is a workflow design that trusted its own scratch space.

Two agent passes shared one workspace with write access. The first pass could be steered into writing an instruction file. The second pass then loaded that file as authoritative guidance.

Nothing was technically broken, which is why no CVE was assigned. The workflow validated where data came from and never validated what was already sitting on disk.

OpenAI split the passes into separate jobs with independent checkouts, then moved its Codex steps to read-only sandboxes. The uncomfortable part is that the fix did not travel. Novee reports that over 100 public repositories still run the vulnerable pattern, and an independent account of the CI/CD chain reaches the same conclusion.

What to change in your workflows this week

If an agent reads issues or pull requests in your repository, three changes carry most of the value.

Start by removing write permissions from anything triggered by untrusted input. A job that only needs to comment does not need the ability to push. Consider splitting the job in two, so the privileged half never sees attacker-controlled text.

Next, upgrade the actions themselves. All three vendors shipped fixes, and two of them cannot be replicated through settings.

Then treat every file your workflow wrote as untrusted input. That is the Codex lesson, and it applies to any multi-step agent, such as a review bot that hands notes to a second stage. If you run a stateless MCP server behind an agent, the same rule holds for anything it persists between calls.

This is the same shape as the keyv npm supply chain attack that reached VS Code and Claude Code earlier this summer. Both turned an ordinary developer convenience into credential theft. Neither needed a zero-day in the language runtime. The reporting at GBHackers and the on-site notes from Hackread both frame the risk as supply chain rather than model behaviour, and that framing is the right one.

Frequently asked questions

Is Claude Code itself vulnerable, or just the GitHub action?

The reported chain targets Claude Code Action, the GitHub Actions wrapper, in its default tag mode. Local interactive use is a different threat model, because no untrusted issue text is being fed in automatically.

Do I need to do anything if my agent only runs on my own commits?

The risk drops sharply, because the attacker needs a way to get text in front of the model. Repositories that accept issues or forked pull requests are the exposed case.

Was any of this exploited in the wild?

No public exploitation has been reported. The chains come from researchers who disclosed to the vendors before presenting at Black Hat.

What does CVE-2026-54316 actually cover?

It covers the Hugging Face exfiltration round, where a pre-approved domain was used to leak an API key through public download counters rather than a direct network call.

The pattern worth keeping

Every one of these bugs sat in the seam between two systems that each behaved correctly. A validator that stripped quotes. A registration check that matched prefixes. A workflow that trusted its own disk.

Agents make those seams load-bearing, because the agent will happily carry an instruction across one. The fix is not smarter prompts. It is refusing to hand privileges to any job that reads text a stranger wrote.