RyotaK says he has now reported around 50 separate ways to bypass Claude Code's permission system and run commands.
The flaw in Anthropic's Claude Code GitHub Action
A security researcher, RyotaK of GMO Flatt Security, discovered a logic hole in Anthropic's claude-code-action that could allow an attacker to take over vulnerable public repositories with nothing more than a single opened GitHub issue. By default, the workflow runs with broad read and write permissions — access to a repository's code, issues, pull requests, discussions, and workflow files — and is supposed to accept triggers only from users with write access.
In January RyotaK reported the core bypass to Anthropic; the company fixed the immediate issue within four days and carried out further hardening through the spring. The fixes appear in claude-code-action v1.0.94. Anthropic rated the issues 7.8 under CVSS v4.0 and paid a bug bounty for the findings.
How a single issue could become full repository control
The trigger check in the workflow treated any actor whose name ended in “[bot]” as trusted, on the assumption GitHub Apps are trusted things admins install. But anyone can register a GitHub App, install it on a repository they own, and use its token to open an issue or pull request on any public repository. The action saw “a bot” and let the attacker's content through. Tag mode in the action had an extra check to confirm the actor was a real human; agent mode did not, leaving it open to abuse.
From there RyotaK relied on indirect prompt injection: planting instructions inside content the AI reads so the model follows them instead of its intended task. He crafted an issue body that looked like an error message and refined it until Claude would “recover” by running the commands buried in it. The attacker targeted /proc/self/environ, the Linux file that holds a process's environment variables. Claude Code blocks naive reads, but RyotaK coaxed Claude into writing those values back into the issue, where an attacker can retrieve them.
The valuable secrets in those environment variables include the credential pair GitHub Actions uses to request an OIDC token — a signed token that proves “I'm this workflow running in this repo.” Claude trades that token with Anthropic's backend for a Claude GitHub App installation token that has write access. If an attacker steals those credentials and replays the exchange, they can obtain write access to a target repository's code, issues, and workflows. If aimed at the claude-code-action repo itself, that access could be used to push malicious code into the action and onto downstream projects that pull it.
Real incidents and supply‑chain consequences
These techniques are not merely theoretical. In February, a prompt‑injected issue title against Cline's claude-code-action triage workflow let attackers steal an npm publish token and push an unauthorized cline@2.3.0. The rogue version only force‑installed a separate, non‑malicious AI agent and was pulled about eight hours later, but the same chain could have shipped malware to everyone who updated.
An autonomous “HackerBot‑Claw” bot spent late February probing GitHub Actions misconfigurations at Microsoft, Datadog, CNCF projects, and others. When it tried to prompt‑inject a Claude‑based reviewer through a poisoned config file, Claude caught it and refused. There is no public sign the exact path that would poison Anthropic's own action was used against a live target; RyotaK demonstrated that attack only in his own test repositories.
Configuration pitfalls that multiplied the risk
Anthropic's own example issue‑triage workflow shipped with allowed_non_write_users: "*", a setting that lets anyone trigger the action. Anthropic's documentation already flags that setting as risky, but plenty of repositories copied the example and inherited the hole. Worse, Claude was posting task summaries to the workflow run's publicly visible summary panel, creating an easy channel to leak data.
RyotaK also described a secondary route: an attacker who can edit issues but cannot trigger Claude directly can still win by editing a trusted user's issue after the workflow has fired but before Claude reads it. The payload then arrives as “trusted” input to the agent.
What this means for repository maintainers, enterprises, and adversaries
- Repository maintainers and CI/CD teams: Update to claude-code-action v1.0.94 or later and audit any workflow that allows users without write access — or bots — to trigger Claude. If the workflow consumes untrusted input, do not feed it any secret beyond the Anthropic API key and GITHUB_TOKEN, and remove tools and permissions that can be used for exfiltration.
- Enterprises and procurement leaders: The February supply‑chain hit shows that agent‑based automation, copied examples, and broad workflow permissions can combine into a single point of failure. Review third‑party action usage and example workflows in code you inherit.
- Adversaries and red teams: RyotaK's report and his claim of roughly 50 bypass techniques underline that prompt injection remains an active avenue. An agent with real tools and tokens can be pushed only as far as its permissions allow — so low friction access to privileged tokens remains a high‑value target.
Anthropic fixed the principal bypass rapidly after notification and hardened the action through the spring, but the episode underscores two enduring points made by the reporting: prompt injection is not solved, and convenience settings and copied examples can produce systemic risk. The immediate, concrete steps are clear — upgrade, audit, and tighten — while the broader question the facts leave is whether automation patterns will be retooled quickly enough to prevent the next supply‑chain shock.
