← Tools I Use

One GitHub issue could hijack any repo running Claude Code's Action, and Anthropic's own pipeline was in range

2026-06-06 · ~8 min read · Conor Dobbs

RyotaK of GMO Flatt Security found a way to take over a public repository that runs Anthropic's Claude Code GitHub Action with nothing more than a single opened issue. No commit access, no stolen password, no social engineering of a maintainer. Open an issue, and if the repo had wired Claude into its CI the way the docs suggested, the attacker walked away with write access to the code, the issues, and the workflows. Anthropic rated it 7.8 on CVSS v4.0, fixed the core bypass within four days of the January report, and kept hardening it through the spring. The patch is in claude-code-action v1.0.94. The bug is closed. The shape of it is what you want to keep.

The trust check that anyone could satisfy

The Action needs to decide whose comments and issues Claude is allowed to act on. You do not want a random drive-by issue steering an agent that holds repo credentials. The check it used was a name test: it waved through any actor whose username ended in [bot], on the reasonable-sounding theory that GitHub Apps are trusted things an admin chose to install.

The hole is that the premise is false. Anyone can register a GitHub App. Register one, install it on a repository you own, and you now hold an app token whose actor name ends in [bot]. Use that token to open an issue or a pull request on someone else's public repo, and you have presented exactly the credential the trust check was looking for. The gate was checking for a costume, not an identity, and the costume was free.

From a fake error message to remote code execution

Passing the trust check only gets your text in front of the model. The next step is indirect prompt injection: planting instructions inside content the AI reads so it follows them instead of the task it was given. RyotaK wrote an issue whose body looked like an error report, then tuned the wording until Claude, trying to be helpful, would "recover" from the fake error by running the commands buried inside it. The agent was not tricked into a clever exploit. It was asked to run commands, and it did, because the content telling it to do so had already been blessed as coming from a trusted bot.

What the planted commands went after was the environment of the running job. On Linux, /proc/self/environ holds a process's environment variables, secrets included. The valuable pair in there is the credential GitHub Actions uses to request an OIDC token, the short-lived signed token that proves "I am this workflow, running in this repo." In normal operation Claude Code hands that OIDC token to Anthropic's backend and trades it for a Claude GitHub App installation token that carries write access, which is how the Action edits your repo on your behalf. Lift the underlying credential out of the environment, replay the exchange yourself, and you mint the same write-access token from outside. At that point you are not commenting on the repo. You are writing to it.

Why the blast radius reached Anthropic itself

The part that turns a per-repo bug into a supply-chain story is where the vulnerable workflow ran. Anthropic's own action repository used the same workflow it ships to everyone else. A working exploit there would not have stopped at one project. It could have pushed malicious code into the Action itself, and every downstream repo that pins to it would pull the poisoned version on its next run. The same self-propagating shape we have been writing about for a month, where the npm worm rode published packages and MCP servers carried RCE across the ecosystem, showed up again. This time the carrier was a CI Action with an AI agent behind it, and the upstream in the blast radius was the vendor.

To Anthropic's credit, the response was fast and unglamorous in the right way: reported in January, core bypass closed in four days, additional hardening across the spring, a paid bounty, a CVSS rating that did not soft-pedal the severity. Microsoft's security team published its own writeup on June 5 framing this as a CI/CD problem in an agentic world rather than a one-off Claude bug, which is the correct altitude to read it at.

The general lesson: an agent in CI is a new identity in your pipeline

Strip the specifics and the structure is plain. You put an AI agent into a privileged automation context. The agent reads untrusted input by design, because reading issues and pull requests is the whole job. And the agent holds credentials, because acting on the repo is the other half of the job. Untrusted input plus held credentials plus an executor that follows instructions written in prose is a remote code execution primitive waiting for someone to phrase the prompt correctly. Every assistant you bolt into a pipeline inherits this shape unless you design against it.

Three controls take most of the risk out, and none of them depend on the agent never being fooled:

Authenticate identity, not appearance. The [bot] suffix was a string, and strings are forgeable. If a trust decision gates access to credentials, it has to verify something an attacker cannot mint for free: the specific app installation ID, an allowlist of known actors, repository membership confirmed against the API. "Looks like a bot" is not authentication.

Scope the token to the job, not the account. The reason a single replayed exchange was worth so much is that the resulting token could write code, issues, and workflows. A token that can only do what this specific run needs turns a full takeover into a contained incident. GitHub's fine-grained tokens and per-job permission blocks exist precisely so a stolen credential is bounded by what it was allowed to do, not by everything the account could do.

Treat injected output as untrusted, and put a human between the agent and anything irreversible. An agent that can read an attacker-controlled issue should not, in the same breath, be able to run arbitrary shell or push to a protected branch without review. The gap between "the agent decided to do X" and "X happened to your main branch" is where the only reliable safety check lives.

You cannot review a pipeline you cannot see

There is a quieter failure mode under all of this. The exploit ran inside CI, the place teams look at least and trust most. A green check mark says the build passed. It does not say what the agent read, which commands it chose to run, or whether the token it minted left the building. When the privileged thing in your pipeline is a model that improvises, the postmortem question stops being "did the job succeed" and becomes "what did the job do, and would I have noticed if it did something else." That is an observability problem as much as a permissions one. Log what your automated jobs touch, alert when a run does something outside its normal envelope, and make sure a silent compromise leaves a trail you can read after the fact. An external check that watches whether your pipeline behaved, independent of the pipeline reporting on itself, is the difference between catching this in an hour and catching it in a breach disclosure.

What to do this week

If you run the Claude Code GitHub Action, update to v1.0.94 or later; the specific bypass is fixed there. Then take the general lesson to the rest of your CI, because this was never only about one Action. Inventory every automated job that both reads untrusted input and holds a writable credential. Replace name-based or appearance-based trust checks with real identity verification. Scope every CI token down to the single repo and the single permission set the job needs, so a leak is survivable. And put a review gate in front of anything an agent does that you could not cleanly undo. A breach is a question of when. The size of it is a question of the scoping and the gates you decided on in advance, while the build was still green.

Sources