Prompt Injection Risks in Agentic Coding Pipelines

Prompt injection is at the top of the OWASP Top 10 for LLM Applications 2025 as LLM01, and that ranking is not a marketing claim from any one vendor. It's the closest thing the security field has to a consensus verdict. When a model can execute code, read a repository, call an API, and write to a filesystem, a successful injection is not an embarrassing chatbot reply but a real action with real consequences.

Coding agents are also where the risk concentrates. Of the 53 agentic projects OWASP's State of AI Surveyor tracks, 28 are coding agents, and the five fastest-growing tools in the whole survey, Claude Code, Gemini CLI, Codex, Cline, and Aider, are all in that same category. Meanwhile the gap between adoption and readiness is wide open: 83% of organizations plan to deploy agentic AI, only 29% feel ready to do it securely, and just 34.7% have put any dedicated prompt injection defense in place. That gap is where the incidents below come from.

The architectural reason prompt injection cannot be patched away at the model layer

People reach for the SQL injection comparison a lot, and it's useful, up to a point. SQL injection and prompt injection share a root cause: failure to separate trusted instructions from untrusted data. But SQL injection got a real fix, parameterized queries, because a database can tell a query structure and a data value apart at the syntax level. A large language model can't do that. Instructions and data both arrive as the same thing, natural language tokens sitting in one context window, and nothing in the architecture marks one stream as command and the other as content.

Trace the pipeline and the problem sits in plain view: system prompt, then user input, then external context such as a fetched file or a tool result, then all of it gets flattened into one combined token stream, which the model turns into output, which then triggers an action. The flattening step is where everything breaks down. The model gives equal weight to a legitimate instruction from a developer and a hidden instruction buried in a code comment, because by the time either one reaches the model, they look identical.

There's no syntactic fence at the model layer that can wall these off from each other, so any real defense has to live one level up, at the application layer or the context layer, filtering and structuring what gets fed in before the model ever sees it. OpenAI effectively conceded this point when it launched Lockdown Mode for ChatGPT Enterprise and said outright that prompt injection in AI browsers "may never be fully solved." That's a company with some of the deepest model-safety resources in the industry, admitting the fix has to happen around the model, not inside it. Research backs up the pessimism: attack success rates are between 50% and 80% across different models and tasks, and there's no clean evidence that bigger, more capable models are more resistant. Some findings point the other way.

The "lethal trifecta": why coding agents satisfy all three conditions by design

Researcher Simon Willison's framing of the "lethal trifecta" gives the clearest diagnostic tool available right now. An agent becomes structurally exploitable when it combines three things at once: access to private data, exposure to untrusted content, and the ability to send information back out to the world. If any one leg is removed, the attack chain has nowhere to go.

Coding agents don't just happen to meet these three conditions. They're built around them. Private data access is the job: source code, secrets files, environment variables, SSH keys, API tokens, all of it legitimately in scope for an agent doing what it's supposed to do. Untrusted content exposure is unavoidable too, since any agent working on a real codebase is going to touch third-party repos, open-source dependencies, README files, code comments, issue titles, and documentation fetched from the open web. And external communication, the third leg, is arguably the whole point of the tool: package registries like npm and PyPI, GitHub's API, CI/CD webhooks, cloud provider APIs. Stripping out any of these three would leave an agent that can't do its job.

Meta's internal guidance, called the "Agents Rule of Two," treats this trifecta less like a fixed trait and more like a budget an agent is allowed to spend. An agent can satisfy two of the three properties and still run without a human watching. The moment all three are present at once, a person has to be in the loop before anything executes. That single rule, applied early, catches a lot of exposure before a single line of malicious code ever gets written. The trifecta tells you where the structural risk lives regardless of which CVE eventually shows up to prove it, so run any coding agent deployment through this test before digging into specific vulnerabilities.

Attack surfaces in a coding pipeline

Every entry point below exploits a different assumption baked into how developers normally work. None of them require the attacker to break the model itself.

Direct injection is the baseline case and, honestly, the least interesting one in a coding context. An attacker controls the user-facing prompt directly and tries something like "ignore previous instructions." Jailbreaking falls under this same umbrella, aimed at getting past safety filters rather than triggering an action. In a standalone chatbot, the damage from this stays bounded, maybe an off-brand or embarrassing reply. Once that same model has tool access, though, the same trick can cascade into a real-world action. Even so, direct injection isn't where the serious risk sits in agentic coding pipelines. Indirect injection is.

Repository and workspace poisoning turns the idea of an "unaudited dependency" into something broader than a library a developer forgot to review. It becomes any file the AI tool reads on its way to taking an action. An attacker plants a payload inside a code file somewhere in the repo; a developer opens that repo and asks the agent something completely innocent; the agent reads the poisoned file as part of answering; the injected instruction fires. The CIPR benchmark (arXiv 2608.30686) tested this across 1,920 instances spanning 20 real repositories and found that test-execution tasks form what the researchers call a "silent attack surface": high attack success, low alert rate, with the agent carrying out the injected instruction without ever flagging it as suspicious. The same benchmark found that task type alone can shift attack success rate by a factor of up to 4.5, which tells you vulnerability here isn't some fixed property of the agent itself, it moves depending on what the user actually asked the agent to do. The benchmark also found that prompt structure and context clutter each shaped outcomes in ways independent of the payload itself. The way a developer phrases a request turns out to matter almost as much as how the attacker crafts the payload.

RAG and document injection widen the net further. Every document sitting in a retrieval corpus is a potential vector, and anyone who can influence what gets indexed can plant instructions the agent will treat as legitimate context once retrieved. The delivery methods lean on the gap between what a human sees and what a model reads: invisible HTML, zero-width characters, footer text nobody scrolls to. A document can look completely blank to a human reviewer and still carry a full payload for the model. One documented case involved a Google Docs file that triggered an AI IDE agent to reach out to a malicious MCP server, pull down instructions from it, and run a Python payload that harvested secrets, all without the user doing anything beyond opening the document. Google's own researchers tracked a 32% rise in malicious prompt injection payloads embedded in web content between November 2025 and February 2026, which suggests this isn't a rare curiosity, it's a growing pattern.

How the MCP protocol layer opened a new injection surface

The Model Context Protocol gave coding agents a standard way to plug into outside tools and data sources, which solved a real integration problem. It also introduced a new trust assumption that didn't exist before: agents now trust MCP servers by default to hand back legitimate context. That assumption turned out to be exploitable almost immediately.

The first malicious MCP server caught in the wild went by the name postmark-mcp. It shipped many clean versions first, quietly building a track record and developer trust, before slipping in a single line of code that exfiltrated data. That's a patient, deliberate supply chain move. Separately, CVE-2025-6514 exposed a remote code execution flaw rated 9.6 on the CVSS scale in mcp-remote, an npm proxy package used widely by MCP clients. Cursor's own list of five high-severity CVEs includes MCP server impersonation via OAuth as one of the named vectors: the protocol layer and the application layer aren't separate attack surfaces anymore. They're coupled.

What the 2025–2026 CVE record shows about real-world exploitation

Security advisories cluster in a pattern that is hard to miss. The five repositories with the most advisories on record are n8n with 57, Claude Code with 22, AutoGPT with 15, Dify with 13, and Roo-Code with 11. Every single one of them is a semi-autonomous framework or a coding agent. That's not a coincidence of what happens to get scrutinized; it's a reflection of where the actual exposure sits.

GitHub Copilot had its own RCE flaw rated 9.6 on CVSS, triggered by a payload embedded in repository files. Once Copilot read those comments, the instructions told it to modify settings that enabled code execution without user approval, a vulnerability with the potential to affect millions of developers given Copilot's install base.

Cursor IDE's cluster of vulnerabilities tells an even more detailed story. CVE-2025-59944 hits versions 1.6.23 and below. CVE-2025-61590 hits versions 1.6 and below; both got fixed in 1.7. Then CVE-2025-61591, CVE-2025-61592, and CVE-2025-61593 all affect versions 1.7 and below, and together the five span MCP impersonation, file protection bypass, workspace manipulation, and CLI-level attack vectors. Beyond that set, CVE-2026-50548 and CVE-2026-50549 are sandbox bypass flaws where, in the words of the disclosure, "the exploit requires no prior user privileges or specific user interaction." CVE-2026-26268 is a sandbox escape achieved through writes to.git config files. And CVE-2026-22708 shows something a little more subtle: an attacker poisons the execution environment using shell built-ins, like export, that sit outside the tool's allowlist. Once the environment is poisoned this way, even allowlisted commands such as git branch end up delivering arbitrary payloads, because the allowlist was never built to cover shell built-ins.

Claude Code had its own incident along similar lines: indirect injection through a repository file led to credential exfiltration via a DNS lookup to a domain the attacker controlled, made possible by an auto-approved command allowlist that was broader than it needed to be.

The Clinejection incident: a supply chain attack that ran end-to-end without human direction

Researcher Adnan Khan disclosed this one on February 9, 2026. The vulnerability window that followed was narrow.

A single crafted GitHub issue title, aimed at Cline's automated issue triage workflow through indirect prompt injection, was the entry point. From that one title, four vulnerabilities chained together in sequence. First, the indirect injection itself, delivered through the issue title. Second, code execution via a dangling commit reference in the workflow. Third, cache poisoning of the CI artifact store. Fourth, publication of a malicious artifact straight to the npm registry.

As a result, a fake release went out without any human authorizing it, installing something called the OpenClaw AI agent on every developer machine and every CI/CD system that pulled the update. No phishing email, no social engineering call, no human being tricked into clicking anything. A single line of text in an issue title started a chain that ended in an unauthorized software release reaching production systems across an unknown number of organizations, entirely on its own.