A Single GitHub Issue Could Hijack Repos Using Anthropic's Claude Code Action — Now Fixed

This is a CI/CD supply-chain disclosure about a widely used automation action, and its lesson is general rather than vendor-specific: GitHub Actions that act on untrusted issue or pull-request input are a high-risk pattern, regardless of whose action is involved.

TOKYO — Security researcher RyotaK of GMO Flatt Security found a flaw in Anthropic's Claude Code GitHub Action that let an attacker take over vulnerable public repositories running it with nothing more than a single opened GitHub issue. Per The Hacker News and GMO Flatt Security's own write-up (reporting dated June 4, 2026), the issue has been addressed: RyotaK reported the core bypass to Anthropic in January, Anthropic fixed it within four days and continued hardening through the spring, with the fixes landing in claude-code-action v1.0.94. Anthropic rated the issues 7.8 under CVSS v4.0 and paid a bug bounty.

There is a notable wrinkle that makes the disclosure worth a standalone brief: because Anthropic's own action repository used the same workflow, a working attack could in principle have pushed malicious code into the action itself and onto downstream projects that pull it — a supply-chain amplification path. The defender takeaway, however, is general and product-agnostic: GitHub Actions that act on untrusted issue or pull-request input are a high-risk pattern that warrants least-privilege tokens and clear input-trust boundaries, regardless of which vendor's action is involved.

What Happened

Per GMO Flatt Security's research, the flaw lived in how the Claude Code GitHub Action decided whether an actor was allowed to trigger privileged behavior. A function named checkWritePermissions unconditionally trusted any actor whose name ended in [bot], regardless of that actor's actual permissions on the repository. Because GitHub Apps have implicit read access to public repositories and can create issues or pull requests on any public repo using only an installation token, an attacker could satisfy the flawed check entirely — appearing as a trusted bot without holding any real write permission. The result was that opening a single crafted issue on a public repository running the action could drive it to act with privileges the attacker should never have had, leading to repository takeover.

The amplification path is what elevates the finding. Anthropic's own action repository used the same workflow, so a successful attack could in principle have pushed malicious code into the action itself — and from there onto every downstream project that pulls the action into its CI/CD pipeline. That is the classic supply-chain multiplier: compromise one widely used component and inherit access to everyone who depends on it. Anthropic responded quickly to responsible disclosure: it fixed the core bypass within four days of RyotaK's January report, continued hardening through the spring, and shipped the fixes in claude-code-action v1.0.94. The company rated the issues 7.8 under CVSS v4.0 and paid a bounty, reported as $3,800 plus a $1,000 bonus for the additional bypasses. RyotaK has said he reported around 50 separate ways to bypass Claude Code's permission system over time, part of a steady run of prompt-injection and permission flaws across AI coding agents; the reporting indicates no downstream compromise occurred.

The Mechanism: Trusting a Name Instead of a Permission

The root cause is a recognizable anti-pattern: authorizing an actor based on an attribute that is attacker-influenceable rather than on its actual permissions. Trusting any actor whose name ends in [bot] treats a naming convention as an access control, and because GitHub Apps can create issues and pull requests on public repositories using only an installation token, that convention is trivially satisfiable. The deeper problem is that the action took a privileged action in response to untrusted input — an opened issue — without verifying that the input's author actually held the permissions the action assumed. This is the same family of mistake The CyberSignal documented in the Grafana pull_request_target pwn-request that hit its second major vendor: workflows that mix untrusted external input with privileged execution are dangerous unless the trust boundary is enforced explicitly.

Why an Action's Own Repo Sharing the Workflow Is the Real Story

The supply-chain wrinkle deserves emphasis because it is what turns a single-repo bug into a potential ecosystem event. When the maintainer of a widely consumed action runs that same vulnerable workflow on the action's own repository, a successful attack does not just compromise one project — it offers a path to poison the action that thousands of downstream projects pull. That is the amplification logic behind the largest CI/CD incidents The CyberSignal has covered, from the Megalodon campaign that backdoored 5,561 repositories through poisoned workflows to the TrapDoor supply-chain attack that poisoned AI coding assistants across npm, PyPI and Crates.io. The good news here is that the path was closed before it was abused; the lesson is that maintainers of shared automation must hold their own repositories to a higher standard precisely because of the downstream blast radius.

A Responsible-Disclosure Story, Not a Gotcha

It is worth being precise about what this is and is not. This is a defensive, already-fixed disclosure: a researcher found a flaw, reported it through proper channels, the vendor fixed the core issue within four days and paid a bounty, and there is no indication of real-world abuse. That is the disclosure process working as intended, and it stands in contrast to the near-zero-notice drops The CyberSignal has covered elsewhere this cycle. The fact that the affected component is an AI coding agent is incidental to the security lesson — the same flaw class appears in non-AI actions, and RyotaK's broader run of permission-bypass findings reflects how much scrutiny CI/CD automation now attracts, not a property unique to one vendor. The CyberSignal frames this as a general vulnerability-management and CI/CD-hygiene lesson, not an indictment of any single product.

Scope and Impact

The exposed population was public repositories that ran the Claude Code GitHub Action in a configuration where an opened issue could trigger privileged behavior, plus — through the amplification path — the downstream consumers that would have been affected had the action's own repository been compromised. Because the fix is shipped in claude-code-action v1.0.94 and the core bypass was closed within days of disclosure, the practical exposure window is now historical for teams that are current. The more durable scope is conceptual: any GitHub Action, from any vendor, that takes privileged actions in response to issue or pull-request input shares the underlying risk pattern, and that population is large.

The structural risk is the trust relationship between untrusted external input and privileged automation. CI/CD systems are attractive targets because they hold write access to source code and the credentials to ship it, and an action that can be steered by an outsider's issue or pull request is a direct path to that access. The amplification when a maintainer runs the vulnerable workflow on the action's own repo is the worst case, because it converts a single-project flaw into a potential supply-chain event affecting everyone downstream. That dynamic — one compromised component, many inheriting victims — is the defining feature of modern CI/CD risk.

A few specifics are best confirmed against the primary write-ups: the exact fix commit and version boundary, the precise bounty amounts, and the confirmation that no downstream compromise occurred (reporting indicates none). Anthropic's CVSS v4.0 rating of 7.8 is the vendor's assessment; RyotaK's count of roughly 50 reported bypass methods is the researcher's figure and reflects cumulative reports over time rather than 50 live vulnerabilities. The CyberSignal presents these as attributed claims from the researcher and vendor, not as independently verified totals.

Response and Attribution

For any team using GitHub Actions — and the framing here is deliberately product-agnostic — the first action is to audit workflows that trigger on issues or pull_request events from untrusted users, and to treat issue and pull-request content as hostile input that must never be used in privileged steps without an explicit permission check. Apply least-privilege GITHUB_TOKEN permissions, scoping each workflow to the minimum it needs, and avoid pull_request_target-style patterns that mix untrusted code with secrets. Authorize on actual repository permissions, never on an attacker-influenceable attribute such as an actor name ending in a particular suffix.

The second durable control is supply-chain hygiene: pin third-party actions to a reviewed commit SHA rather than a floating tag, so that an upstream compromise cannot silently flow into your pipeline. That single practice would blunt the amplification path at the heart of this disclosure, and it is the same lesson The CyberSignal has drawn from the codexui-android package that stole developer tokens and the TeamPCP breach that exfiltrated 3,800 repositories through a poisoned extension. For teams specifically running the Claude Code action, the immediate step is simpler: confirm you are on the fixed version (v1.0.94 or later) and review recent automated activity for anomalies.

On attribution, there is no threat actor and no attack: this is a researcher disclosure that was responsibly reported, promptly fixed, and rewarded with a bounty, with no indication of in-the-wild exploitation. The CyberSignal's framing leads on the product-agnostic CI/CD lesson — Actions that act on untrusted issue or pull-request input are dangerous; pin to SHA, least-privilege the token, and authorize on real permissions — precisely because that lesson is useful to every engineering team regardless of which automation they run. The AI-coding-agent angle is the occasion for the finding, not its substance.

The CyberSignal Analysis

Signal 01 — Untrusted Input Plus Privileged Automation Is the Core Risk

The single most transferable lesson is that any automation which takes privileged action in response to externally controllable input is dangerous unless the trust boundary is enforced explicitly. An opened issue or a submitted pull request is attacker-controlled content, and a workflow that acts on it with elevated permissions inherits the attacker's reach unless it verifies real authorization first. This is not an AI problem or a single-vendor problem; it is a CI/CD design problem that predates AI coding agents and will outlast this particular flaw. Teams should audit every workflow against this one question: does it ever do something privileged because of input an outsider can supply?

Signal 02 — Maintainers of Shared Components Carry Downstream Risk

The amplification path — the action's own repository running the same vulnerable workflow — is the detail that turns a contained bug into a potential supply-chain event. Whoever maintains a widely consumed component owns a blast radius that extends to every downstream consumer, which means their own repositories deserve stricter controls than an ordinary project, not looser ones. The practical defenses split cleanly: maintainers must harden the workflows on their own repos, and consumers must pin to reviewed commit SHAs so an upstream compromise cannot flow downstream silently. Both sides of that relationship have to do their part.

Signal 03 — This Is What Working Disclosure Looks Like

Amid a cycle full of disclosure conflict, this case is a useful counterexample: a researcher reported through proper channels, the vendor fixed the core issue within four days, hardened further over months, paid a bounty, and no downstream harm resulted. That is the coordinated-disclosure model functioning as designed, and it is worth naming as such rather than collapsing every AI-vendor security story into a headline-grade alarm. The substantive takeaway for defenders is the CI/CD lesson, which applies to everyone; the vendor specifics are the occasion, and the responsible handling of them is the part worth emulating.

Sources