AI Coding Tools as a CI/CD Attack Surface

Key Takeaways

• Google patched a maximum-severity (CVSS 10.0) vulnerability in Gemini CLI, tracked as GHSA-wpqr-6v78-jr5g, in which headless CI/CD execution automatically trusted attacker-controlled workspace files, allowing arbitrary command execution on CI/CD build runners [1][2].
• Researchers have documented over 30 vulnerabilities across major AI coding assistants — including Cursor, Windsurf, GitHub Copilot, Cline, and Roo Code — in a disclosure campaign termed IDEsaster, establishing that 100% of tested AI IDEs are vulnerable to prompt injection-based attack chains [6].
• The structural risk is architectural, not incidental: when an AI agent runs inside a CI/CD pipeline with repository write access and cloud credential access, its compromise may be operationally equivalent to compromising the build system itself, depending on the credential scope and repository access the agent holds.
• Security teams must treat AI coding assistants, including their configuration files, MCP server integrations, and headless execution modes, as security-critical infrastructure rather than productivity add-ons.

Background

The software build pipeline occupies an unusually sensitive position in the enterprise attack surface. A compromise that reaches the CI/CD environment — whether through credential theft, a supply chain intrusion, or a dependency injection attack — can propagate malicious code into production artifacts at scale, bypass code review controls, and persist across release cycles. Build pipeline attacks have been a recurring feature of high-profile supply chain compromises, and the addition of AI coding agents into that environment deserves careful security scrutiny.

AI coding assistants occupy a privileged position in the development environment. They read and write source code, execute shell commands, manage configuration files, communicate with external APIs, and increasingly operate in unattended headless modes within GitHub Actions, GitLab CI, and similar automation platforms. This is not coincidental: the productivity case for AI-powered automation in CI/CD is compelling, and adoption has accelerated rapidly. According to Wiz’s 2026 State of AI in the Cloud report, 57% of surveyed organizations had deployed self-hosted AI agents as of early 2026, and 80% of cloud environments were running Model Context Protocol (MCP) server instances — a strong indicator of how deeply agentic AI has embedded into the software delivery infrastructure [10]. The vulnerability disclosures discussed in this note suggest that security hardening has not kept pace with this adoption — gaps are evident in the tools themselves, in the policies governing their runtime privileges, and in the organizational frameworks for reasoning about the trust relationships they create.

The vulnerability and research disclosures that emerged in April 2026 represent a confluence rather than a novelty. Individual vulnerabilities in AI coding tools had been documented throughout 2025, including a CVSS 8.7 RCE in Claude Code (CVE-2025-59536, CVSS 4.0 score per NVD) that enabled arbitrary command execution through malicious project configuration files [8]. What makes the current moment distinct is the breadth: multiple researchers, working independently, have now characterized AI developer tooling as a high-priority attack surface with consistent, exploitable vulnerability patterns. The Gemini CLI advisory is the highest-severity expression of this trend, but it is part of a larger structural story.

Security Analysis

The Gemini CLI CVSS 10.0: Workspace Trust in Headless Mode

On April 24, 2026, Google published GHSA-wpqr-6v78-jr5g, a GitHub Security Advisory disclosing a CVSS 10.0 remote code execution vulnerability in versions of Gemini CLI prior to 0.39.1 and in the google-github-actions/run-gemini-cli GitHub Action prior to 0.1.22 [1]. The vulnerability was identified and reported by Elad Meged of Novee Security and Dan Lisichkin of Pillar Security.

The root cause lies in how Gemini CLI handles workspace trust in headless, non-interactive environments — exactly the mode used in CI/CD pipelines. When the tool runs without an interactive terminal, it automatically extends trust to the current workspace directory and loads configuration from .gemini/ files present in that directory. In a CI/CD workflow, the workspace directory is typically populated from repository content — meaning an attacker who can introduce files into a repository (through a pull request, a forked repository, or a supply chain compromise of any upstream dependency) can deliver malicious Gemini configuration to the build runner without any user interaction. The attack requires no authentication against the CI/CD platform itself; the vulnerability is entirely in the agent’s trust decision.

The second component of the vulnerability involves the --yolo execution mode, which is commonly enabled in automated pipelines to allow Gemini CLI to proceed without operator confirmations. In this mode, the tool’s allowlist for permitted commands and tools is bypassed entirely, meaning that even if an operator had attempted to constrain the agent’s actions through explicit allowlists, those constraints provided no protection. The net effect is that a remote attacker with the ability to influence any file in a CI/CD workspace — a baseline capability for many supply chain attack scenarios — could achieve arbitrary command execution on the build runner with the full privileges of the CI/CD service account [2][3][4].

Google addressed the vulnerability by requiring explicit trust decisions before loading workspace configurations. Operators must now set GEMINI_TRUST_WORKSPACE: 'true' as an explicit environment variable to restore the prior behavior, converting the default from implicit trust to explicit opt-in. For the GitHub Action specifically, the fix was incorporated in version 0.1.22. Organizations using any prior version of either package should treat affected pipeline runs as potentially compromised and rotate any secrets or credentials accessible from those runners.

A Broader Pattern: IDEsaster and the AI IDE Vulnerability Landscape

The Gemini CLI advisory did not emerge in isolation. Concurrently, security researcher Ari Marzouk published the IDEsaster disclosure, documenting more than 30 distinct vulnerabilities across AI-integrated development environments, including Cursor, Windsurf, GitHub Copilot, Zed, Cline, and Roo Code [6]. Twenty-four of these vulnerabilities received formal CVE identifiers [6]. The research found that every tested AI IDE was vulnerable to prompt injection attacks, and that these injection attacks could be chained with legitimate IDE features to achieve remote code execution and data exfiltration.

The attack architecture documented in IDEsaster follows a consistent three-stage pattern. In the first stage, attacker-controlled content — typically embedded in a repository file, an imported dependency, a web page the developer visits, or an external data source the AI agent queries — injects instructions into the model’s context. These instructions direct the model to take specific actions using its available tools: reading credential files, executing shell commands, or modifying configuration. In the second stage, the AI agent’s tool-calling capabilities translate the injected instructions into concrete operations on the developer’s system. In the third stage, results are exfiltrated or persisted, often through channels that blend with normal AI-assisted development activity such as code suggestions, clipboard operations, or outbound API calls [7].

A related disclosure from Pillar Security documented what researchers termed the “Rules File Backdoor”: hidden Unicode characters embedded in AI coding assistant configuration files (such as Cursor rules files or Copilot instruction files) that cause the AI model to produce malicious output while appearing to generate benign code [9]. These invisible instructions — using zero-width joiners, bidirectional text markers, and similar Unicode control characters — are not visible in standard code review interfaces, can propagate through repository forks, and can affect entire development teams who share the poisoned configuration. According to the Pillar Security disclosure, GitHub Copilot subsequently added warnings for files containing suspicious Unicode sequences; Cursor was reported at the time of disclosure to have characterized the risk as a user responsibility [9]. The broader lesson is that AI configuration files must be treated as code artifacts subject to the same version control, review, and integrity verification processes as source code itself.

Also documented in this research cycle is CVE-2026-26268, a vulnerability in Cursor IDE through which git hook injection enables arbitrary code execution [5]. Git hooks are shell scripts that execute automatically on repository events such as commits and merges; Cursor’s vulnerability allowed malicious repository content to introduce hook files that would execute on the developer’s machine during normal development operations. This is a meaningful escalation from prompt injection: it does not rely on the AI model taking any action, but instead exploits the IDE’s interaction with the underlying version control system to achieve execution through a path that bypasses the AI’s safety mechanisms entirely.

CI/CD as the Force Multiplier

Understanding why AI coding tool vulnerabilities warrant elevated concern requires situating them in the context of what CI/CD pipelines actually do and what credentials they hold. Many GitHub Actions workflows — particularly those that perform deployments or automated commits — operate with a token scoped to repository write operations, and frequently have access to additional secrets: cloud provider credentials, container registry credentials, package signing keys, deployment keys for production infrastructure, and API tokens for third-party services. CI/CD credentials have been the demonstrated objective in major supply chain incidents, including the SolarWinds and Codecov compromises, because their capture translates directly into the ability to modify production deployments, inject malicious code into published packages, or pivot into cloud infrastructure.

When an AI coding agent runs inside this environment — reading repository files, executing commands, and making outbound network requests — any vulnerability that allows attacker-controlled content to influence the agent’s behavior becomes a potential path to all of those credentials. Trail of Bits has characterized this architecture as “prompt injection to RCE”: the injection is the entry point, but the execution environment is the actual target [7]. The GHSA-wpqr-6v78-jr5g advisory makes this explicit: the vulnerability allowed an unauthenticated external attacker to execute commands on CI runners with the full privileges available to the automated workflow. In the case of a workflow with cloud credentials and repository write access, those privileges are substantial.

John Stawinski’s documented analysis of the Claude Code GitHub Action illustrates the same dynamic through a different mechanism [11]. In that case, the AI coding agent’s access to issue titles, pull request bodies, and comment content — all user-supplied inputs — created a prompt injection vector. An external contributor could craft an issue or PR comment containing injected instructions that the agent would execute during its automated processing. Because the agent had shell access and repository write permissions by design, the injection translated into a full code execution capability accessible to any unauthenticated GitHub user who could open an issue on the target repository.

The pattern is consistent enough across these disclosures to describe as a class: AI coding agents that process untrusted content as part of their normal operation, while holding elevated privileges in CI/CD environments, create prompt injection to RCE attack chains that are exploitable by unauthenticated external attackers. This is not a single vendor’s oversight; it reflects a gap between the security assumptions embedded when these tools were first built — optimized for the individual developer context — and how they are now being deployed as privileged automated agents in shared build infrastructure.

Supply Chain Angles: Slopsquatting and Dependency Poisoning

The CI/CD attack surface extends beyond direct code execution to include the package recommendations that AI coding assistants generate. Research published by Trend Micro and others has documented a vulnerability class termed “slopsquatting”: when AI models recommend package installation commands, they occasionally hallucinate package names that do not exist, and attackers can pre-register those names with malicious payloads [12]. Studies across multiple models found that approximately 20% of packages recommended by AI code generation tools in certain contexts were fictitious, and that 58% of hallucinated package names were repeated consistently across multiple model runs — making them predictable targets for malicious registration [12]. When AI coding agents operate autonomously in CI/CD contexts and can execute the installation commands they generate, this hallucination pattern becomes a direct supply chain attack vector requiring no adversarial input at all.

This is distinct from traditional supply chain attacks because the attack vector is the model’s own output rather than a compromise of an external repository or registry. It raises important questions about the appropriate scope of autonomous action for AI coding agents: a developer who can pause and verify a package suggestion provides a meaningful safety check; an unattended CI/CD agent that installs packages based on its own recommendations does not.

Recommendations

Immediate Actions

Organizations running Gemini CLI in any CI/CD context should update to version 0.39.1 or later and update the google-github-actions/run-gemini-cli action to version 0.1.22 or later immediately. The same urgency applies to auditing the pipeline configurations that used prior versions: if any workflow ran against pull requests or repository content from uncontrolled sources using a vulnerable version, associated credentials should be rotated and build artifacts reviewed for signs of tampering. The GHSA-wpqr-6v78-jr5g advisory’s CVSS 10.0 score reflects the absence of any authentication requirement for exploitation. Detection of exploitation may be difficult without comprehensive audit logging, but organizations should review available pipeline execution logs and credential access records for anomalous activity before concluding that no exploitation occurred.

For organizations running other AI coding assistants in CI/CD contexts, an immediate audit of the trust assumptions embedded in those workflows is warranted. The specific questions to address are: does the agent process untrusted user input (issue titles, PR bodies, repository files from external contributors) as part of its operation? Does the agent have access to secrets, cloud credentials, or package signing keys? Does the agent have the ability to execute shell commands or write to the repository? Affirmative answers to all three questions describe a high-risk configuration regardless of which agent is involved.

Short-Term Mitigations

The mitigation framework for AI coding agents in CI/CD environments mirrors the principle of least privilege applied to the specific capabilities these agents require. Workflows should be structured to grant AI agents only the repository scopes they need for their specific task, explicitly excluding write access where the agent’s function does not require it. Secrets should be scoped to the minimum set required and rotated frequently; long-lived credentials with broad scope should be replaced with short-lived, task-scoped tokens wherever the infrastructure supports it. The GitHub Actions permission model, AWS IAM with session conditions, and similar mechanisms provide the technical foundation; what has been lacking is the recognition that AI coding agents should be subject to the same rigor as any other privileged service account.

Configuration files used by AI coding assistants — rules files, .gemini/ directories, .cursor/ configurations, MCP server definitions, and similar artifacts — should be treated as executable code for purposes of review and integrity verification [14]. Changes to these files should require the same code review process as changes to deployment scripts or security-relevant source code. Organizations deploying AI agent tools at scale should implement content scanning for suspicious Unicode characters and validate the integrity of configuration files through cryptographic signing or similar mechanisms wherever the deployment tooling supports it.

Strategic Considerations

The deeper strategic question is whether the current model of deploying AI coding agents as fully privileged participants in CI/CD pipelines represents an acceptable risk posture for production build infrastructure. The answer should depend on a clear-eyed assessment of the threat model: CI/CD pipelines that process contributions from external users or that build software distributed to customers are operating in an adversarial environment where the cost of compromise — malicious code in published releases, credential exfiltration from build runners — can be severe.

Organizations should evaluate whether the specific automation benefits of AI agents in CI/CD justify the expanded attack surface they introduce, and should design accordingly. This may mean restricting AI agent integration to internal-only workflows where inputs are more controlled, implementing strict network egress filtering on runners where AI agents operate, or adopting an architecture where the AI agent generates a plan for human review rather than executing directly. The slopsquatting research suggests that even package installation recommendations from autonomous agents deserve human validation checkpoints in environments where an erroneous or malicious package installation could propagate into published artifacts.

CSA Resource Alignment

The vulnerability class documented in this note maps directly to Layer 3 (Agent Frameworks) and Layer 4 (Deployment Infrastructure) of CSA’s MAESTRO threat modeling framework for agentic AI systems [16]. MAESTRO characterizes the combination of broad tool access and untrusted input processing as a primary risk vector for agentic systems, and the CI/CD prompt injection to RCE pattern is a concrete instantiation of this risk in production environments. Security teams applying MAESTRO to their agentic deployments should treat CI/CD pipeline integration as one of the highest-priority scenarios for threat modeling, given the credential access and downstream deployment impact these pipelines represent.

CSA’s guidance on securing autonomous AI agents [15] addresses the integration of AI agents into the software delivery process, covering runtime isolation, explicit capability scoping, and the enforcement of trust boundaries between agent and environment. These controls map directly to the mitigations described above. Organizations evaluating AI coding assistant deployment in automated pipelines should reference this guidance alongside the MAESTRO threat model as primary architectural references when designing their AI agent governance posture.

The AI Controls Matrix (AICM) [17], CSA’s control framework for AI-specific risks, addresses the supply chain dimensions of AI developer tooling, including third-party model provider risk, dependency integrity, and the governance of AI-generated code artifacts [13]. The slopsquatting risk described in this note — where an agent’s own hallucinated recommendations become a supply chain attack vector — falls within AICM control domains addressing AI output integrity and human oversight requirements. Organizations using the AICM for AI governance should ensure that controls addressing AI-generated code review and package installation validation are instantiated for agentic CI/CD use cases. CSA’s Zero Trust guidance is also directly applicable: the principle that no system component — including an AI coding agent — should be implicitly trusted based on its network location or identity alone is exactly the principle violated by Gemini CLI’s automatic workspace trust in headless mode.

References

[1] Google. “GHSA-wpqr-6v78-jr5g: Gemini CLI Remote Code Execution via Workspace Trust Bypass.” GitHub Security Advisory, April 24, 2026.

[2] The Hacker News. “Google Fixes CVSS 10 Gemini CLI CI RCE and Cursor Flaws Enable Code Execution.” April 2026.

[3] Cyera Research Labs. “Cyera Research Labs Discloses Command & Prompt Injection Vulnerabilities in Gemini CLI.” Cyera, November 2025.

[4] Penligent. “Gemini CLI RCE, Workspace Trust and the CI/CD Agent Attack Surface.” Penligent, April 2026.

[5] Novee Security. “CVE-2026-26268: How an AI Coding Agent Can Run Exploits in Cursor IDE.” Novee Security, April 2026.

[6] Cloud Security Newsletter / Ari Marzouk. “IDEsaster: AI IDE Vulnerabilities and the Attack Surface of AI-Augmented Development.” 2026.

[7] Trail of Bits. “Prompt Injection to RCE in AI Agents.” Trail of Bits Blog, October 2025.

[8] Check Point Research. “RCE and API Token Exfiltration Through Claude Code Project Files (CVE-2025-59536).” Check Point Research, 2026.

[9] Pillar Security. “New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents Through Compromised Rule Files.” Pillar Security, March 2025.

[10] Wiz. “State of AI in the Cloud 2026.” Wiz Blog, April 29, 2026.

[11] Stawinski, John. “Trusting Claude With a Knife: Unauthorized Prompt Injection to RCE in Anthropic’s Claude Code Action.” February 2026.

[12] Trend Micro. “Slopsquatting: When AI Agents Hallucinate Malicious Packages.” Trend Micro, 2025.

[13] Cloud Security Alliance. “AI Organizational Responsibilities: AI Tools and Applications.” CSA, 2025.

[14] Cloud Security Alliance. “The Six Pillars of DevSecOps: Automation.” CSA, 2020.

[15] Cloud Security Alliance. “Securing Autonomous AI Agents.” CSA, 2026.

[16] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” CSA Blog, February 2025.

[17] Cloud Security Alliance. “AI Controls Matrix.” CSA, 2025.

This research note was produced by the Cloud Security Alliance AI Safety Initiative as a point-in-time analysis based on publicly available information as of April 30, 2026. It is intended to inform security professionals and development teams about emerging threats and does not constitute legal, compliance, or audit guidance.