Skip to main content
CybersecurityHacking

AI Coding Agents Expose Sandbox Vulnerabilities

Modern computer workstation with blank screen in a bright office setting.

"One report was 'of exceptional quality,'" Pillar Security says, quoting feedback from Google's team.

How the sandbox boundary was bypassed

Security researchers at Pillar Security — Eilon Cohen, Dan Lisichkin and Ariel Fogel — spent months reproducing a set of sandbox bypasses and published the results as a Week of Sandbox Escapes. Their central finding: an agent that remains obedient to every sandbox rule can still cause code to run on the host by writing files the host later reads, loads, or executes.

The pattern is simple and persistent. Sandboxes place trust inside a workspace while protecting the host. But files inside that workspace are not inert: integrated development environments (IDEs), command-line tools, extensions and local daemons routinely read and act on workspace files. A README, issue, dependency or diff that contains a prompt-injection can thereby trigger local actions when those outside-the-sandbox tools process the file.

Pillar’s taxonomy of failure modes

  • Denylist sandboxes that cannot keep pace with the operating system;
  • Workspace configuration that functions as executable code;
  • "Safe" command allowlists that trust a command's name rather than its arguments; and
  • Privileged local daemons that sit outside the sandbox entirely.

Pillar emphasizes that these are not theoretical edge cases: IDEs and CLI agents repeatedly run tools outside the sandbox — Python interpreter discovery, Git metadata scanning, VS Code task files, hook engines, and Docker Desktop sockets among them — creating predictable points where written files become actions.

What was found, and what vendors changed

Most of Pillar's findings were patched and vendor-acknowledged.

  • Cursor: A workspace-controlled .claude hook configuration was turned into unsandboxed command execution. That bug is tracked as CVE-2026-48124 and fixed in Cursor version 3.0.0. Pillar also detailed a Cursor issue that allowed editing a virtualenv interpreter that an editor Python extension would later run during discovery, and a third bug that abused nonstandard Git metadata locations to fire execution through fsmonitor; the latter was patched in 3.0.0 and has a CVE pending.
  • OpenAI's Codex CLI: A "safe" allowlist trusted the name git show even when the specific invocation was not read-only. OpenAI patched the issue in Codex CLI v0.95.0, paid a high-severity bounty, and has a CVE pending.
  • Docker socket: A privileged local daemon reachable by the agents provided an unsandboxed execution surface. This Docker socket finding affected Codex, Cursor and Google's Gemini CLI; Pillar reports the issue has since been fixed.

Google's handling of Antigravity findings

Pillar disclosed two Antigravity findings affecting Google's tooling: a macOS Seatbelt denylist bypass and a .vscode task-config bypass of Google's Secure Mode. Google classified both as "Other valid security vulnerabilities" and applied a downgrade, judging them difficult to exploit because they require social engineering or a user to trust a repository carrying an indirect prompt injection.

Pillar notes that Google's team still rated the submissions highly, and the company quoted Google's feedback that one report was "of exceptional quality." The downgrade reflects Google's assessment of exploitability rather than a denial that the vulnerabilities existed.

An older pattern, now across multiple vendors

Pillar is not the first to document this class of issue. In April, Cymulate described the same pattern as "Configuration-Based Sandbox Escape" across Claude Code, Gemini CLI and Codex CLI, where a sandboxed file later runs on the host at next launch. What is new in Pillar's work is the breadth: the same failure mode appears across four tools from three vendors, a signal Pillar says should inform anyone weighing agentic coding tools.

Pillar's proposed mitigation is not another filename blacklist. Instead, their fix watches for the moment a trusted local tool runs something the agent wrote, addressing the dynamic handoff between sandboxed writing and unsandboxed execution.

What this means for technologists, procurement leaders, and developers

  • Technologists and security teams: Expect to prioritize detection where host tools consume workspace files. Pillar's approach — monitoring the moment a trusted local tool runs something written by an agent — points to instrumentation and logging as immediate mitigations. The source also underscores the need to manage virtualenv discovery, Git metadata handling, and Docker socket exposure.
  • Affected enterprises and procurement leaders: The same failure across Cursor, Codex CLI, Gemini CLI and Antigravity is a comparative signal. Pillar's reporting — and Cymulate's earlier work — suggests procurement decisions should weigh how vendors handle workspace-config trust boundaries and whether fixes are in place (for example, Cursor 3.0.0 and Codex CLI v0.95.0).
  • Developers and end users: The trigger for these escapes is often a prompt-injection embedded in files such as READMEs, diffs or dependency manifests. Caution when cloning or running code from unfamiliar repositories remains central, since exploitability in some cases depends on a user trusting or launching repository content.

Most issues Pillar found have been patched and vendor-acknowledged; several CVEs are assigned or pending. The reporting leaves a pointed operational question: will monitoring the handoff between sandboxed writers and unsandboxed hosts become a standard control in agentic development tooling, or will vendors continue to rely on path-based and name-based defenses that these researchers have shown can be bypassed?

Source: BleepingComputer: Cursor, Codex, Gemini CLI, Antigravity hit by sandbox escapes