Prompt Injection Meets CI/CD: Dissecting the Permission Validation Flaw in Claude Code
A significant supply chain vulnerability has been uncovered within Anthropic’s Claude Code GitHub Actions workflow. This flaw created a pathway for attackers to compromise thousands of repositories through a single, seemingly innocuous GitHub issue. By exploiting the intersection of AI automation and CI/CD pipelines, threat actors could achieve full repository takeover.
Security researcher Ryota K from GMO Flat Security identified a series of architectural weaknesses in the Claude Code integration. These flaws allowed attackers to bypass traditional permission boundaries and inject malicious payloads into automated workflows used for issue triage, code reviews, and general repository automation.
The Anatomy of the Vulnerability: Broken Permission Validation
The technical root of the exploit lies in a flawed permission validation logic within the workflow. The system utilized a function that effectively granted any GitHub App (acting as a bot account) the ability to bypass standard write-permission checks. Because GitHub Apps can interact with public repositories without requiring explicit installation by the repository owner, an attacker could simply deploy a malicious app to trigger the vulnerability.

mcp__github__update_issue Model Context Protocol (MCP) tool. (Source: GMO)By creating a malicious issue or pull request, an attacker could provide crafted input designed to trigger the Claude Code workflow. Once the workflow was active, it processed the attacker-controlled content. Using advanced prompt injection techniques, the attacker could manipulate the LLM into executing arbitrary system commands.
In a successful exploit, the injected commands could instruct the runner to read sensitive environment variables. This included the exfiltration of OpenID Connect (OIDC) tokens. Since GitHub Actions use these tokens to authenticate and generate installation tokens for GitHub Apps, an attacker who successfully captured these credentials could replicate the authentication flow to obtain high-privilege tokens with full write access across the entire repository.

Privilege Escalation and Chained Attacks
The risk was further amplified by insecure default configurations. Many users utilized the allowed_non_write_users: * setting, which effectively opened the door to any external entity. When paired with excessive permissions—such as issues: write and access to the GITHUB_TOKEN—the attack surface became massive.
Researchers also demonstrated a sophisticated “chained” attack vector. In this scenario, an attacker would first use a minor misconfiguration to gain limited access. They would then modify existing issues created by trusted contributors. When a legitimate, high-privilege workflow was eventually triggered by a trusted user, it would ingest the attacker’s hidden payload, resulting in a full repository compromise.
Crucially, this vulnerability was not contained to third-party users; it extended to Anthropic’s own repositories. A successful compromise of the Claude Code GitHub Action itself could have allowed a threat actor to inject malicious code into the action’s core, creating a “poisoned well” effect for every developer using the tool.
Remediation and Defensive Posture
Anthropic has since released version 1.0.94 to mitigate these risks. Key security enhancements include:
- Restricting GitHub Apps from triggering workflows by default.
- Eliminating unsafe configuration patterns.
- Disabling public workflow summaries to prevent data leakage.
- Implementing stricter validation for command execution and preventing exfiltration via CLI tools.
The vulnerability was assigned a CVSS score of 7.8 and was reportedly exploited in the wild prior to its public disclosure. This incident serves as a stark reminder that as we integrate AI into our CI/CD pipelines, prompt injection is no longer a theoretical concern—it is a critical security frontier. Organizations are urged to audit their workflows, strictly adhere to the principle of least privilege (PoLP), and treat all LLM-processed inputs as untrusted.