Claude Code GitHub Action Permission Bypass and Secret Exfiltration - claude-code-action

What happened

On June 1, 2026, researcher RyotaK of GMO Flatt Security disclosed a permission bypass in Anthropic claude-code-action, the GitHub Action that runs Claude Code inside a repository's workflows. The flaw affects builds before v1.0.94 in agent mode and was rated CVSS v4.0 7.8. The root cause was an authorization shortcut: the action's checkWritePermissions function trusted any actor whose username ended in [bot], assuming GitHub Apps are installed by repository administrators and are therefore privileged.

That assumption does not hold. Anyone can register a GitHub App, install it on a repository they control, and use its token to open an issue on a target repository. The issue author's username then ends in [bot], so checkWritePermissions treated the attacker-controlled App as trusted. Tag mode still enforced a human-actor gate; agent mode did not, so the inferred-trust gap was directly reachable through issue and comment events.

With the gate bypassed, the attacker used indirect prompt injection planted in the issue content to drive the agent to read process environment variables and write them back into the issue. That exposed credentials used to mint an OIDC token, exchangeable for a Claude GitHub App installation token with full write access to code, issues, and workflows - a path from an unprivileged outsider to repository write. Anthropic patched the core bypass in claude-code-action v1.0.94 within four days. Microsoft published a complementary analysis on June 5, 2026 documenting a related /proc environment-access gap, with an additional mitigation attributed to Claude Code v2.1.128.

This is not a parsing bug. It is an authorization control that inferred privilege from a naming pattern, combined with an injection that turned the agent's own capabilities against it - the same inferred-trust-plus-injection shape seen in Claude Code project-file RCE and token exfiltration (CVE-2025-59536).

Why this is an agentic-endpoint risk

A Claude Code GitHub Action is an AI agent with a hook, running on a CI endpoint with access to repository secrets, an OIDC identity, and write tools. That is the high-capability surface this advisory turns against the org: an outsider who can open an issue reaches an agent that can read environment variables and write to the repository. The danger is not a known-bad binary or a malicious packet - it is what a trusted agent was permitted to do once an injected instruction reached it.

The exposure is hard to see from the controls you already run. EDR sees a legitimate runner process; the network sees ordinary GitHub API traffic; GRC has a policy that says human approval is required, while agent mode quietly did not enforce it. AI agents and CLIs are among the eight AI artifact types adopted bottom-up to unblock a workflow and reporting to no security tool - the same dynamic that makes AI agents and MCP servers the new shadow IT. This is the artifact layer traditional controls were never built to see: you cannot tell which repositories pin a vulnerable version, which runs are agent mode, or what an agent actually read from the environment without an inventory of the artifact layer and a record of every call.

How Anomity surfaces and governs it

Anomity addresses this finding in three steps, and the structure matters because the lesson is that a human-approval policy written in one mode means nothing if the agent can act in another mode that never checks it.

First, inventory. Anomity inventories every AI agent and CLI on every managed endpoint - CI runners included - as part of the eight AI artifact types it tracks, surfacing the exact version of claude-code-action in use so finding everything before v1.0.94 is a single query rather than a repository-by-repository sweep. It classifies each agent by the capabilities it grants and flags which expose a hook. Metadata only: secrets are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On an agent that exposes a hook - for example the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. An attempt to read process environment variables, or to write those values back into an issue, is checked at the call rather than inferred from who appeared to trigger the workflow. That is what runtime governance provides: enforcement on the actual tool call, not on a [bot] suffix or a mode-specific gate - the exact assumption this bypass defeated.

Third, keep the record. Every decision, and every added, changed, or removed agent, lands in a queryable 90-day audit trail that captures attempted environment reads in CI, and decisions route to SIEM, Slack, email, or Jira. When responders ask which repositories ran a vulnerable version and whether any agent read the environment, you answer from a record rather than a guess. None of this replaces patching - upgrade to claude-code-action v1.0.94 and Claude Code v2.1.128 - but it closes the window before and after the fix lands, and complements your existing CI, EDR, DLP, and GRC tooling. See how it works for where the hook sits in a CI run.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every repository and CI runner using claude-code-action and record its pinned version; upgrade anything before v1.0.94, and update Claude Code to v2.1.128 for the related /proc mitigation.
• Find every workflow that runs the action in agent mode on issue or comment events, where the human-actor gate tag mode enforced does not apply.
• Treat the [bot] username suffix as proof of nothing - confirm no workflow infers trust from actor naming patterns rather than an explicit authorization check.
• Scope CI secrets and OIDC trust down to the minimum each workflow needs, so a single exposed environment variable cannot be exchanged for broad repository write access.
• Confirm high-risk agent actions - reading process environment variables, writing back into issues or comments, minting or exchanging tokens - are evaluated at the agent hook with allow/deny/log.
• Verify every tool call and agent version change is written to a 90-day audit trail that captures attempted environment reads in CI and is routed to your SIEM, so you can reconstruct what each run was allowed to do.

The claude-code-action bot-actor bypass is a reminder that an AI agent's gate is only as strong as the mode that enforces it, and that the reliable place to stop an injected instruction is at the call it tries to make. Patch to v1.0.94 and v2.1.128, scope CI secrets and OIDC trust down, and govern the dangerous actions at the hook. For the full attack surface across coding agents and CLIs, see the pillar guide on securing AI coding agents and CLIs, and the sibling advisory on Claude Code project-file RCE and token exfiltration. To see Anomity govern the agent and CLI layer across your fleet, request early access.