Infrastructure Review Stack
FeaturesLong read

How RCE Vulnerabilities Escape Sandbox Boundaries

AI agents can escape sandboxes through kernel sharing, tool chains, and misconfiguration.

· 8 min read
Cover illustration for “How RCE Vulnerabilities Escape Sandbox Boundaries”
Features · October 27, 2026 · 8 min read · 1,875 words

Remote code execution in AI agents is less a question of whether code can run than of where its effects can reach. Sandbox escapes come from the same kinds of failures in kernel boundaries, tool paths, configuration, and authority. Builders who understand how those failures work can choose isolation that holds, even when agents keep state and work across sessions.

Why the classical RCE threat model breaks down for AI agents

Traditional RCE starts when an attacker finds a vulnerability that lets them run code. In an AI agent, execution inside the sandbox is already part of the intended workflow. The starting condition has changed. If manipulated input can influence the code an agent runs, the security question is whether that code remains confined. Input validation, WAFs, and code signing that aim to stop code from running in the first place solve a different problem from the one the sandbox faces.

Microsoft Defender Security Research explains how thin the line is between content security and a code execution primitive once a model has tools. The model need not malfunction for that line to be crossed. It can parse language into tool schemas exactly as designed while the framework gives the resulting parameters more trust than they deserve. Where, then, does the security decision belong? It belongs at the boundary that turns parsed content into permitted effects, and understanding that threat model is the prerequisite for choosing effective isolation.

How a shared kernel collapses the sandbox perimeter

Standard Docker containers share the host kernel, so workloads on the same host have the same kernel attack surface. An attacker whose code already runs inside a container does not need another application-level foothold before probing that surface. The next boundary is a kernel interface that the attacker can reach. Hardening can restrict access to it, but the container does not give the workload a separate kernel. That distinction becomes consequential when executing untrusted code is the service’s purpose.

Kodem Security documents a wave of 13 vm2 sandbox escape CVEs disclosed across early May 2026, many with CVSS scores between 9.0 and 10.0. Deprecated in 2023 but still widely deployed, vm2 isolates untrusted or LLM-generated JavaScript in agent frameworks, plugin systems, and SaaS automation services. Its escape chain has four stages. First, untrusted JavaScript enters vm2, potentially as LLM output from a manipulated prompt. Second, the attacker invokes a boundary-crossing primitive. Third, that primitive exposes Node.js host APIs, including child_process and the file system. Fourth, arbitrary shell commands run with the privileges that the Node.js runtime has.

Escaping vm2 reaches the Node.js host environment, which is not necessarily the physical host outside a container. In a containerized deployment, broader infrastructure access depends on the hardening controls around that runtime. The example nevertheless shows why nested sandboxes cannot be treated as interchangeable protection. An application-layer escape exposes capabilities that the next boundary must contain, while a shared kernel leaves the workload facing the same kernel as its neighbors.

Does seccomp or a mandatory access control system make that distinction cease to matter? Those controls shrink the exposed surface, but workloads still share the kernel. A userspace escape can cross the vm2 boundary before it reaches a protected syscall boundary, though crossing it does not defeat every OS-level restriction. MicroVMs instead give each workload its own kernel, removing the shared-kernel surface.

How frameworks hand escape to the agent's own tools

A separate route reaches beyond the sandbox through tools that already have permission to cross it. Microsoft’s Semantic Kernel vulnerability CVE-2026-25592 illustrates the sequence concretely. The SessionsPythonPlugin lets agents execute Python in isolated cloud-hosted Azure Container Apps sandboxes. A first injected instruction directs the agent to use ExecuteCode to generate a malicious script inside the container. A second directs DownloadFileAsync to write that payload into the host’s Windows\Start Menu\Programs\Startup folder. Semantic Kernel.NET SDK versions older than 1.71.0 are vulnerable.

The sandbox’s operating-system boundary can still hold here. One tool creates the payload in isolation, and another exports it to a dangerous host location. Microsoft also identifies CVE-2026-26030, which requires a prompt injection vector and an agent using the Search Plugin backed by an In-Memory Vector Store, and reaches host-level RCE. Neither case depends on a browser exploit, malicious attachment, or memory corruption. The framework’s mapping from language to tool calls supplies the path.

AI Now Institute’s proof-of-concept, published 2026-07-08, extends the concern beyond that framework. It demonstrates RCE in Claude Code CLI with Sonnet 4.6, Sonnet 5, and Opus 4.8, and in OpenAI’s Codex CLI with GPT-5.5, during assessment of an open-source or third-party library. The attack uses out-of-the-box Claude Code “auto-mode” or Codex “auto-review.” Its instructions are spread through the library’s source files, without hooks, plugins, MCP servers, or configuration files as injection vectors. The advertised review workflow itself supplies the untrusted input.

Would human approval interrupt these tool chains? CVE-2025-53773 shows why the approval mechanism must itself be protected. Injected prompts can cause GitHub Copilot to write "chat.tools.autoApprove": true to .vscode/settings.json without approval, disabling the gate before later actions. A framework acts as the agent’s operating system in the sense that it maps decisions to available effects. If that mapping trusts output that an attacker has shaped, an attacker can still break in through tools even when kernel boundaries hold.

How configuration mistakes give away escape before any exploit runs

Misconfiguration differs from both runtime escape and tool chaining because the access is already available. Quickstart documentation across major agent frameworks repeats three primitives, namely exposed Docker sockets, writable host mounts, and privileged containers. Each one on its own can give a sandboxed process access to the host. No new boundary-crossing exploit is needed. A deployment can call its execution environment a sandbox while granting the very access that confinement is meant to withhold.

The pattern grows out of framework convenience. Templates make useful capabilities easy to connect, but those connections can also put host resources within reach of untrusted execution. Microsoft calls this convenience’s “hidden cost,” because a foundational framework spreads the consequences of unsafe mappings across applications built on it. The Langflow vulnerability CVE-2025-3248 is a concrete production case. It has a CVSS score of 9.8, appears in the CISA Known Exploited Vulnerabilities catalogue, and involves an exposed execution path exploited in the wild, rooted in deployment configuration matching common quickstart patterns.

Configuration can change after review, including through an agent’s response to injected instructions. CBSE illustrates why that change can outlast the session that introduced it, rather than disappearing when the immediate interaction ends. The distinction from kernel collapse is therefore operational as well as technical. A sound runtime boundary cannot compensate for configuration that has already authorized a path around it.

How lingering tool authority extends the blast radius after escape

Coding agents often retain broad tool access for an entire task although a capability was needed for only one subgoal. PORTICO research calls this gap “lingering authority.” The permission was legitimate at one point, but its continued availability enlarges what a later compromise can do. Authority must be assessed by both who received it and when it should expire.

PORTICO defines a request–grant–invoke lifecycle that represents capability expansions as opaque, epoch-bound handles. At closure, those handles leave the next planner interface, and stale replay is blocked before it can cause side effects. Its controlled coding-agent tasks make the contrast concrete. A non-revoking comparator permitted all post-closure reuses, while PORTICO rejected them. A deterministic stale-write audit found executed forbidden effects under the comparator and zero under PORTICO across file writes, git mutation, and network egress.

The results distinguish revocation from merely discouraging unsafe actions. Broad request exposure also increased blocked proposals, even when no forbidden effect executed, showing that agents kept proposing actions that should no longer have been available. In worker-orchestrator deployments, a compromised worker can also reach an orchestrator with broader standing permissions. That escalation path makes the authority held above the worker part of its potential blast radius.

Stateful sandboxes add another complication to the lifecycle. Files, installed packages, running processes, and environment variables can persist between sessions, allowing a payload planted during elevated access to survive after that access was intended to end. Revoking the original capability and removing its effects are different operations. Checking each invocation on its own can miss both permissions that stay in place across a task and artifacts left by earlier actions that were allowed. The next boundary to examine is time.

How stateful and long-running agents turn a one-shot injection into a durable implant

CBSE documents a malicious configuration written during one Claude Code session that persists on disk and re-executes on every subsequent launch from the project directory. The attacker does not need to win each session. In this mechanism, persistence is a property of the stateful design. Storing injected instructions in an agent’s memory creates a related route by preserving the instructions across sessions.

An agent with mouse, keyboard, file, and browser control already has ways to affect the desktop it operates. Using prompt injection to redirect those capabilities can give an attacker practical RCE without a kernel-level escape. The ZombAI attack demonstrates this form of control. Indirect prompt injection targeting an agent with Claude Computer Use access connected it to an attacker’s command-and-control loop, turning the assistant into a node the attacker could steer.

None of this makes statefulness inherently undesirable. Preserving work is what makes long-horizon coding agents operationally useful, so deleting all state would discard the feature. The mitigation direction is to pair persistence with isolation, controlled patching, and session-level monitoring. Snapshot-based recovery adds controlled checkpoints from which work can return to a known-good state, bounding the window in which a planted payload can act. Given failures that span kernels, tools, permissions, and time, what must the complete isolation design protect?

What isolation that actually holds requires, given these failure modes

Builders should select isolation designed for untrusted, AI-generated code. Per-workload kernel boundaries provide microVM-class separation. That addresses the kernel layer. At the framework layer, parameters sourced from model output must remain untrusted input, with validation enforced where tool schemas map them into system operations. The model cannot decide on its own whether to trust its output to drive system operations.

Deployment defaults must preserve those boundaries. Baseline templates should expose no Docker sockets, writable host mounts, or privileged containers. Because configuration can change during operation, drift monitoring must be continuous. Authority needs a comparable lifetime control. Capabilities granted for a subgoal should be epoch-bound and automatically revoked at closure, as PORTICO’s reference monitor demonstrates is implementable without sacrificing task success.

Session-level monitoring and controlled snapshots let teams check the state they keep and roll back to a known-good checkpoint without giving up long-running work. These controls complement revocation because a permission can expire while a file or instruction created through it remains.

SOC 2, HIPAA, and GDPR requirements apply to agentic workloads as they do to other data-processing systems, while the EU AI Act’s transparency obligations are enforceable as of August 2, 2026. Endpoint choice introduces a separate constraint. Using a consumer-tier model endpoint violates HIPAA when PHI enters a prompt because no BAA covers consumer-tier endpoints. A sandbox’s ability to contain code does not, by itself, establish that the surrounding workflow is permitted to process the data it receives.

Sources

  1. When prompts become shells: RCE vulnerabilities in AI agent frameworks
  2. Friendly Fire: Hijacking Defensive Cyber AI Agents for Remote Code Execution - AI Now Institute
  3. Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents

More in Features