MCP Agent Sandbox Escape Vulnerability Patterns

MCP sandbox escapes aren't random bugs scattered across a fast-moving protocol. They follow four repeatable patterns, and once you name them, you can actually build defenses instead of shipping patches after the fact.

MCP has become the default way AI agents talk to tools and data. SDK downloads have crossed a substantial monthly total, there are more than 10,000 active public servers, and every major client, ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code, supports it as a first-class citizen. Security has not kept up with any of that growth. Independent scans put the share of public MCP servers carrying exploitable flaws somewhere between 30% and 82%, depending on what's being tested, and only 8.5% of servers use OAuth. Between January and April 2026, researchers disclosed more than 40 CVEs against MCP implementations, roughly one every four days. On May 20, 2026, the NSA published guidance called "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation," and its framing is blunt: MCP's rapid spread has outpaced the security model built to contain it. The guidance breaks the risk into eight named concerns and nine recommendations.

What follows is a walkthrough of the four patterns behind most of these failures, plus the authentication gap that produces them.

What "sandbox escape" means in an MCP context

A traditional sandbox limits what code can do: no arbitrary filesystem writes, no random network calls, no spawning new processes. MCP complicates that picture because tool invocation runs through natural-language descriptions that an LLM reads and interprets at inference time. That's a fundamentally different attack surface than a code-execution sandbox, and researchers behind the MCP-38 taxonomy (March 2026) treat it as its own category of risk.

Anyone who controls text the LLM reads, a tool description, an API response, an uploaded PDF, can steer what the agent does next. It's a semantic exploit, not a code-execution exploit in the classic sense. It's a semantic one.

Three layers matter for where an escape actually happens:

• Runtime layer: the execution environment for code a tool calls, say, a Python interpreter running inside a JavaScript process

MCP tools default to inheriting broad host privileges: file access, environment variables, network calls. That makes the blast radius of a single escape unusually large, according to the MCP-SandboxScan paper (arXiv:2601.01241v2). Part of the reason traces back to the STDIO transport MCP uses by default, which passes parameters straight to host shells without mandatory sanitization. Research findings attributed to Dev.to/piiiico found 43% of MCP vulnerabilities attributable to shell or exec injection as a direct result.

Two distinct failure categories fall out of this. One is escapes that break out of a code sandbox. The other is escapes that never touch code at all, they just abuse trust and permission logic that was never built to survive a hostile input. Treating them as one problem means your defenses will cover half the surface.

Pattern 1: Runtime bridge abuse (when the Python-to-JavaScript seam becomes an exit door)

CVE-2026-25905 is the cleanest example on record. Published to the GitHub Advisory Database on February 9, 2026, it affects mcp-run-python versions 0.0.22 and earlier. There's no patch, and the project has since been archived.

The root cause is a bridge left unguarded. The runPython and runPythonAsync functions execute Python code through Pyodide, but they don't restrict access to the underlying JavaScript bridge. Any Python that runs, whether a user wrote it or a model generated it, can reach into the js module Pyodide exposes.

From there, attacker-controlled Python can rewrite the global JavaScript environment, poke at the Node.js process directly, or change how the MCP server itself behaves. One specific technique this enables is what researchers call MCP Tool Shadowing: Python code overwrites a legitimate registered tool with a malicious stand-in. Picture a secure file-reading tool getting silently swapped for a version that quietly ships file contents to an external server, while the MCP server keeps humming along like nothing happened.

There's no configuration fix here. Remediation means either disabling the Pyodide-to-JS bridge in the source code or moving execution into a fully isolated container. The general lesson goes beyond this one advisory: whenever two runtimes share a bridge without a real isolation boundary between them, that bridge becomes the exit door. And detecting it is genuinely hard, the server looks fine from the outside. Without runtime-level visibility inside the tool process itself, description-level or traffic-level scanning cannot catch it. This is why the MCP-SandboxScan researchers pushed for WASM-based sandbox auditing.

Pattern 2: Permission self-grants (how a tool promotes its own access at runtime)

CVE-2026-86544, published September 7, 2026, affects versions of the "knowns" package and shows a completely different mechanism. Researchers classified it as a sandbox escape, but no second runtime is involved anywhere in the chain. A basic code.replace operation lets a tool grant itself delete permissions that its declared permission set was never meant to allow.

The tool never breaks out of its container. The tool never breaks out of its container; it just rewrites its own permission state from the inside. It just rewrites its own permission state from the inside, using a plain string-manipulation call that nobody flagged as dangerous because on its face, it isn't. The guard isn't circumvented from outside, it's bypassed from within, through the very update path meant to manage it.

Microsoft's Semantic Kernel disclosures from May 7, 2026 reflect a similar failure mode. CVE-2026-26030 carries a CVSS score of 9.9, and CVE-2026-25592 is between 9.9 and a full 10.0. In both cases, an internal method got exposed to the model as something it could call directly, and a model-supplied argument reached a dangerous operation with no check on whether the model should have been allowed to supply that argument.

The common thread across all three: permission systems that check declarations at install time but never re-check anything at execution time leave a window wide open. Runtime mutation just walks through it. For platform teams, that means declared permissions and runtime permissions have to be enforced as two separate checkpoints, not one. Verifying what a tool claims it can do when it's installed tells you nothing about what it can talk itself into doing mid-session.

Pattern 3: Tool shadowing and cross-server escalation (poisoning the shared context window)

The LLM sees every tool description from every connected server, all at once, in the same context window. A malicious server's tool description can shape how the agent behaves toward tools from a completely different, fully trusted server, a point security researchers have made directly.

Two sub-patterns fall under this umbrella. Active tool shadowing is when a malicious description overwrites or intercepts calls meant for a legitimate tool, and it's achievable purely through description manipulation with no code bridge required. Then there's the rug pull: a server passes review, gets added to mcp.json, runs cleanly for days or weeks, then quietly pushes an update that swaps its benign description for a hostile one. Most MCP hosts approve that update without re-prompting the user, because trust gets bound to the tool's name rather than its actual content.

CVE-2025-54136, nicknamed MCPoison, is the real-world version of that rug pull. Check Point researchers showed that Cursor kept trusting previously approved tool configurations even after their underlying content had been swapped out.

The scale of this is not theoretical. Lab benchmarking across more than 45 real-world MCP servers put tool-poisoning attack success rates above 60%, with the best-performing agent model hitting 72.8%, a CSA research note found. Invariant Labs demonstrated in April 2025 how a poisoned math tool read SSH keys off a machine and exfiltrated them encoded inside a math function's parameter, no user interaction, no trace left behind. And in March 2026, a malicious server published under the name mcp-jira-sync got installed by more than 340 developers before anyone caught it. Hidden instructions buried in its list_issues tool description caused agents to attach the contents of ~/.aws/credentials to every outbound API call, routed straight to an attacker-controlled server.

What makes cross-server escalation so dangerous is that the attacker never has to touch the trusted server. They just need one malicious server sharing the same context window, and the trusted server's authority becomes usable by the attacker's instructions by proxy. Static analysis of tool descriptions catches the known patterns, but it misses sequence-level attacks, where individually harmless, individually authorized tool calls chain together into an exfiltration pipeline nobody designed to look for.

Pattern 4: Path traversal and filesystem boundary violations

Exec and shell injection is the biggest single security-flaw category in the MCP ecosystem by count, at 43%. Path traversal is 10% by category count, but that number understates the problem: survey data across 2,614 implementations found 82% vulnerable to path traversal specifically.

Even Anthropic's own Filesystem MCP Server wasn't immune. In 2025, researchers found it vulnerable to a symlink-based sandbox escape that let arbitrary filesystem access slip past its declared directory boundaries. The lesson there isn't about sloppy implementation, it's structural. Application-level directory restrictions are systematically bypassable through symlinks unless something enforces the boundary at the OS or container level instead.

The Smithery incident shows how far this kind of flaw can travel downstream. A path traversal bug in Smithery's build configuration, which happened in June 2025 and became public in October 2025, leaked Docker credentials and ended up compromising 3,000 apps, turning one traversal flaw into a full supply-chain event. Separately, the Figma/Framelink MCP integration turned up vulnerable to command injection through unsanitized input reaching child_process.exec, a case where filesystem and shell injection risks converge into the same bug.

CVE-2025-6514 shows the client side of this same weakness. A malicious MCP server returns a crafted authorization_endpoint URL stuffed with shell metacharacters, and the vulnerable mcp-remote client executes them as commands on the host machine, full remote code execution. That client had over 437,000 downloads.

Docker socket abuse is a related vector. A server with access to the Docker socket can launch a new privileged container with the host filesystem mounted right into it, stepping outside its own container. A mount-exploitation variant does something similar from the other direction, a compromised server writes a malicious script to a mounted host directory and executes it for full host control. Every one of these sub-variants traces back to the same root cause: path restrictions enforced only at the application layer, with nothing backing them up at the OS or container level. Symlinks, relative paths, and socket access all route around application checks the same way water finds a crack.

The substrate beneath all four patterns: authentication gaps and unverified trust propagation

OAuth is written into the MCP authorization spec, but it's explicitly optional, and that single word does a lot of damage. A 2025 internet scan found at least 1,862 publicly accessible MCP instances answering unauthenticated requests. Only 8.5% of public servers use OAuth in practice.

Session handling has its own gap. Weak lifecycle management around session tokens allows message replay or unauthorized reuse of a valid session, and if hijacking occurs, an attacker can impersonate a legitimate client, inject prompts, or interact with a server without leaving a visible trace. The specification simply leaves a lot of that lifecycle unspecified. Insecure implementations are, if not encouraged, certainly not prevented.

The NSA's guidance names a related risk directly: unverified task propagation, meaning tasks get passed between MCP servers or agentic components with no check on where they originated, what scope they're supposed to have, or what they were actually meant to do. That leads to overreach, context leakage, and downstream tools firing when nobody intended them to.

The clearest illustration of how bad this gets showed up when researchers demonstrated what they called "agentjacking." Using nothing more than a public Sentry DSN, an error-reporting identifier, researchers hijacked Claude Code, Cursor, and Codex 85% of the time. No breach happened. No credentials got stolen. The error-reporting server's response simply became something the agent acted on instead of just logging, an instruction riding in on data the agent already trusted implicitly.

That case reframes the whole problem. Authentication on the primary MCP channel doesn't matter if a trusted side-channel, error reporting, telemetry, plain logging, carries instructions nobody inspected. The trust boundary has to cover every channel the agent reads, not just the one labeled "MCP." OX Security's advisory put a number on how widespread this kind of systemic flaw runs: an estimated 200,000 vulnerable instances sitting across a supply chain touching more than 150 million package downloads. That's the ecosystem, not an edge case buried in some obscure implementation. That's the ecosystem.

What a structured threat model gives security and platform

Naming these four patterns, runtime bridge abuse, permission self-grants, tool shadowing, and path traversal, turns a vague sense of unease into something a security team can actually test for. Vague warnings about "AI agent risk" don't tell an engineer what to check in code review. A known bridge-isolation gap does. A known permission-mutation path does too.

Each pattern maps to a specific control. Runtime bridges need real isolation, containers, sandboxing technology, something stronger than a shared process. Permission systems need enforcement at execution time. Cross-server context needs some way to segment trust so one poisoned tool description can't reach across to a clean one. Filesystem boundaries need OS-level or container-level enforcement, because application-layer checks alone keep losing to symlinks.

None of this closes the authentication gap that produces all four failure patterns, and no pattern-level fix will substitute for actually requiring OAuth or locking down session lifecycle handling. But a platform team that can point to a named pattern and a matching control has something to build against. A team stuck warning about "AI risk" in the abstract does not. Given that MCP adoption is still climbing and security flaw disclosures are landing roughly every four days, that difference is the whole game.