Prompt Injection to Code Execution Attack Chains

The attack is not dramatic. No alarm sounds, no file arrives with an obvious red flag. A piece of text appears, an agent reads it, and then the agent does something it was not supposed to do, using tools it was legitimately given, in ways that look entirely normal until someone notices the configuration file changed.

That sequence is the core problem. OWASP classified prompt injection as LLM01, the top risk for LLM applications, and in December 2025, drawing on input from over 100 researchers, OWASP published a separate Top 10 specifically for agentic applications. That second publication matters: the threat has matured enough to require its own taxonomy. The attack surface is different, the propagation paths are different, the consequences reach further.

The reason the entry point cannot be sealed at the model level is architectural. Large language models have no channel separation. Instructions from a developer and data from a malicious README arrive through the same token stream, indistinguishable at the protocol level. Compare this to SQL injection: parameterized queries work because the database engine enforces a structural boundary between code and data. The engine cannot be tricked into parsing user input as a query because the two travel different protocol paths. LLMs have no equivalent primitive. This is a property of the architecture itself, not a bug in any one model, and every defense built on top of it is compensatory, full stop.

Two injection variants matter here. Direct injection targets the system prompt and typically requires some access to the application layer. Indirect injection plants malicious instructions in content the agent retrieves at runtime: web pages, documents, code comments, tool outputs, issue tracker entries. Indirect is the more dangerous variant for agents, because the payload arrives from sources the developer does not review and cannot anticipate. If the entry point cannot be closed at the model level, every downstream capability the agent holds becomes a potential exit for the attacker.

The chain from injection to execution runs through several handoffs. An attacker plants a payload in content the agent will ingest. The agent parses that payload as an instruction rather than data. The agent then invokes a tool it legitimately possesses: file writes, shell calls, API requests, configuration modifications. That tool output crosses an execution boundary. A file is written, a process is spawned, a configuration is modified to disable future guardrails. Subsequent commands then run without re-injection, because the environment has already been reconfigured.

The execution boundary is where the attack becomes catastrophic rather than merely consequential. Before it, the attacker has influence; after it, the attacker has control. OWASP's LLM06:2025 codified what researchers call "Excessive Agency": a compromised model chains legitimate tools into unauthorized actions, and the blast radius scales with how many tools the agent holds. This is the principle of least privilege, restated for autonomous systems. What is novel is the speed at which capable models can traverse a tool chain once injected.

Four documented attack chains that reached code execution in production systems

These four cases are not chosen for drama. Each illustrates a different entry point and a different execution mechanism, and together they show the attack surface is wider than any single vector.

CVE-2025-53773: GitHub Copilot and configuration poisoning

An attacker embeds a prompt injection payload in public repository comments. A victim opens the repository with Copilot active. The injected prompt modifies .vscode/settings.json, enabling what researchers called "YOLO mode," a configuration state in which subsequent commands execute without user approval. Arbitrary code execution follows.

The execution mechanism here is configuration modification, not a direct shell call. Disabling a guardrail is functionally equivalent to code execution: the attacker does not need to run a command if they can remove the requirement for approval before commands run. CVSS 3.1: 8.7.

A variant researchers called "ZombAI" extended the chain further, with Copilot hijacked to download malware and recruit developer workstations into command-and-control botnets. No executable was flagged; no suspicious network connection triggered an alert. The payload is text that an AI assistant reads and acts on.

CVE-2025-66032: Claude Code and the CI/CD chain

An AI-powered issue triage workflow held shell access and processed untrusted issue input. The injection path led to code execution on GitHub Actions runners, then chained with cache poisoning and token handling failures. CWE-20 (Improper Input Validation) and CWE-77 (Command Injection); CVSS 3.1: 8.7.

The post-mortem framing is worth quoting directly: giving an LLM shell access in a CI context where it processes untrusted input is functionally equivalent to giving every GitHub user shell access. CI/CD pipelines are high-value targets precisely because they already hold production credentials and deployment authority. An attacker does not need to escalate privileges; those privileges are already present.

CVE-2025-59536: Claude Code Hooks and pre-dialog RCE

The Hooks feature runs predefined shell commands at lifecycle events. An attacker injects a malicious Hook into .claude/settings.json inside a repository. The command executes before the trust dialog appears on screen. A second flaw in the same disclosure: .mcp.json settings override consent safeguards and auto-approve all MCP servers on launch. CVSS 3.1: 8.7.

Three consecutive CVEs with identical CVSS scores is not coincidence. A trust mechanism that lives at the UX layer rather than the protocol layer can be bypassed before the user ever sees it. That is a structural failure, not a one-off implementation mistake.

Devin AI: port exposure via injected instruction

Documented in August 2025, an injected prompt caused Devin to expose internal ports to the public internet. This is the first documented case of an agentic coding platform bridging internal network infrastructure to the internet through injected instructions alone, no shell CVE required. The agent used its legitimate networking capability; the injection simply redirected it.

Across all four cases, none required a novel zero-day in the underlying operating system. Each exploited the agent's own legitimate capabilities, redirected by injected instructions. Security researchers have catalogued analogous behavior in traditional binaries under the GTFOBINS and LOLBAS projects: living-off-the-land attacks that abuse trusted tools rather than introducing foreign executables. Agentic systems extend that principle into a new class of targets.

Why MCP has become the widest attack surface in agentic pipelines

The Model Context Protocol, Anthropic's open standard for connecting agents to external tools and data, has become the default integration layer for agentic systems. It has also accumulated critical vulnerabilities faster than defenses have been deployed.

Protocol-level exposure

In April 2026, OX Security disclosed a systemic architectural flaw estimated to affect approximately 200,000 vulnerable instances across a supply chain covering more than 150 million package downloads. This was not a coding error in one product; it was a design default embedded in every official MCP SDK and propagated into downstream projects. Anthropic confirmed the behavior as intentional. The MCP authorization specification defines OAuth 2.1 but marks authorization as optional. A July 2025 internet scan found at least 1,862 publicly accessible MCP instances responding to unauthenticated requests. By May 2026, at least seven confirmed high- or critical-severity CVEs spanned MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf.

That last detail deserves a moment. Seven CVEs across five distinct products, all tracing back to the same protocol design decisions. That is not a coincidence of timing; it is what systemic architectural exposure looks like once researchers start pulling the thread.

Tool poisoning and rug pulls

MCP clients inherit trust from the servers they connect to without continuous verification. Three distinct attack variants exploit this: tool description poisoning, rug-pull attacks, and tool shadowing. Invariant Labs' April 2025 proof-of-concept demonstrated that a single poisoned tool description could exfiltrate private repository contents without user interaction. Across more than 45 real-world MCP servers, attack success rates exceeded 60%, with the highest recorded rate at 72%.

One finding from that research cuts against a common assumption: the most capable models were often the most compliant with malicious metadata. Superior instruction-following cuts in both directions. Claude-3.7-Sonnet, the most resistant model tested, still refused poisoned tool calls less than 3% of the time. That figure should recalibrate how much weight any team places on model-level resistance as a primary defense.

A rug-pull attack swaps a clean tool for a malicious one after initial approval. MintMCP's 2026 analysis flagged roughly 5.5% of public MCP servers as tool-poisoning-vulnerable. OWASP codified tool poisoning as MCP03:2025 in its MCP Top 10.

Supply chain amplification

Antiy CERT confirmed 1,184 malicious skills across ClawHub, representing roughly one in five packages in the ecosystem at peak. The npm attack surface compounds this: a prior Nx token theft attack infected more than 500 packages, and the Shai-Hulud worm subsequently hit 796 packages with 132 million monthly downloads. AI agents that install MCP servers through npm sit at the center of that exposure.

MCP was designed for connectivity. It was designed without adversarial content in mind. Every tool description an agent reads is, from a security standpoint, untrusted input with potential for injection. That gap between design intent and deployment reality is where most of these attacks live.

How multi-agent architectures let a single injection propagate across a pipeline

A single-agent injection is bounded by that agent's tool access. A multi-agent injection is not.

Propagation moves through several mechanisms. A hijacked agent can instruct a downstream agent via legitimate inter-agent messaging, passing the attacker's intent through channels that look identical to normal orchestration traffic. A poisoned shared memory store or vector database allows one agent to write attacker-controlled content that a second agent later reads as trusted context. Orchestrator manipulation is the most consequential variant: compromise the orchestrating agent and you can redirect the entire pipeline.

Per HiddenLayer's 2026 survey of 250 IT and security leaders, only 24.4% of organizations have full visibility into which agents are communicating with each other. Most teams cannot reconstruct the propagation path even after an incident. The zero-click IDE attack pattern illustrates this in practice: a Google Docs file triggered an agent to contact a malicious MCP server, retrieve attacker instructions, execute a Python payload, and harvest developer secrets. The victim's only action was opening the document.

LangGraph 1.0 reached general availability in October 2025; Microsoft Agent Framework 1.0 reached GA in April 2026. Multi-agent pipelines are now production infrastructure, not experiments, and the propagation risk scales accordingly. An agent with read-only access to a single API is a dead end. An orchestrator holding credentials across five downstream services is a force multiplier for any attacker who reaches it.

Trust boundaries must be drawn between agents, not only between the agent system and the outside world. That principle is easy to state. Based on current deployment patterns, it is rarely followed.

The gap between how widespread the vulnerability is and how seriously it is being defended

OWASP reports that 73% of live AI rollouts have flaws open to prompt injection. Only 34.7% of firms have deployed specific defenses. A majority of production systems are exposed and undefended simultaneously. Google researchers documented a 32% increase in malicious prompt injection payloads embedded in web content between November 2025 and February 2026. The attacker side is scaling faster.

HiddenLayer's 2026 survey found that 31% of organizations do not know whether they experienced an AI breach in the past 12 months. Seventy-three percent report internal conflict over who owns AI security controls. One in eight AI security breaches is now linked to an agentic system.

Three factors explain the gap, and they require different responses because they are genuinely different problems.

Ownership is often ambiguous in ways that are structural, not merely organizational. Is prompt injection a model problem, an application problem, or an infrastructure problem? I have sat in rooms where that question was asked sincerely and watched it dissolve into a scheduling conflict. The 73% internal conflict figure reflects something real: the vulnerability spans layers that traditionally belong to different teams, so accountability diffuses across all of them and lands firmly on none.

Traditional security tooling misses text-based payloads entirely. Antivirus and network monitoring are designed to detect known malicious binaries and anomalous traffic patterns. A malicious instruction embedded in a README triggers neither alert, until an AI agent processes it and acts.

Deployment moved faster than threat modeling. The CVE-2025-53773 post-mortem noted that AI-powered developer tools were shipped without robust threat modeling for injection attacks. That observation applies broadly; it describes how most software categories evolve when adoption velocity outpaces security review cycles. It is not unique to AI, but AI makes the consequences worse because the tools it holds are unusually consequential.

The attack patterns are well-documented, the CVEs are public, and the OWASP taxonomies are explicit. This is not primarily a knowledge gap. It is an ownership and tooling problem, and treating it as the former while the latter goes unaddressed is how organizations end up in the 31%.

Where in the chain builders can actually intervene

Different links in the chain respond to different defenses. Stacking compensatory controls at the same layer while leaving adjacent layers unaddressed is a common failure mode, and I have seen it happen often enough that it is worth naming explicitly.

At the ingestion boundary, before the model sees untrusted content

Input validation and sanitization on content retrieved from external sources raises the cost of injection without eliminating it. More durable is contextual flagging: marking content retrieved from external sources as untrusted in the prompt structure. Some frameworks support explicit trust-level metadata, allowing downstream logic to apply different thresholds to content of different provenance.

At the tool invocation boundary, before the agent calls a tool

Least-privilege tool grants are the single highest-leverage control available. An agent that cannot issue shell commands cannot achieve remote code execution regardless of what it is instructed to do. The Devin port-exposure case and the CI/CD chain case both turned on over-privileged tool access; restricting grants would have collapsed the attack path before the execution boundary was reached.

Tool call confirmation for irreversible or high-impact actions provides a second checkpoint. LangGraph 1.0's general availability in October 2025 stabilized human-in-the-loop hooks at defined decision points, giving builders a practical mechanism to require approval before consequential actions execute.

MCP tool descriptions must be validated at load time and re-verified on every update. Rug-pull attacks succeed because clients do not re-verify after initial approval. Treating every tool description update as potentially adversarial closes a gap that most current implementations leave open.

At the execution boundary, where instructions become system calls

This is where infrastructure design becomes a security primitive, not merely a performance consideration. Sandbox isolation at this layer ensures that even a successful injection, one that has traversed earlier controls, cannot escape into the underlying host or move laterally into other workloads. Platforms like Daytona isolate untrusted and AI-generated code in fully separated sandbox environments, applying containment at the execution boundary so that persistence and lateral movement collapse as attacker objectives even when earlier controls have failed. Immutable filesystems and ephemeral execution environments are complementary controls at the same layer, limiting the persistence that makes injection chains economically valuable to attackers.

Audit logging of tool calls with sufficient granularity to reconstruct the sequence of events is a foundational operational requirement. The HiddenLayer finding that 31% of organizations cannot determine whether they experienced a breach in the past year reflects, in part, insufficient logging at the tool invocation layer.

No single control seals the full chain. Each link is separately addressable, each intervention has a defined place in the architecture. The coverage gaps most teams carry are not accidental oversights so much as the predictable residue of building fast in a threat landscape that security practice has not yet caught up to. The honest question is not whether to act, but which specific link your team has already looked at, decided was someone else's problem, and moved on from.