Four AI Coding Agents Got Their Sandboxes Broken This Week — and Nobody Attacked the Sandbox. They Just Wrote a File the Grown-Ups Outside Trusted.
- Patrick Duggan
- 3 hours ago
- 4 min read
The security model of an AI coding agent rests on one promise: the agent runs in a sandbox, so even if it does something dangerous, the blast radius is contained. Pillar Security spent several months proving that promise hollow across four of the most widely used agents — Cursor, OpenAI's Codex, Google's Gemini CLI, and Antigravity — and the way they did it is the part worth understanding, because it is not the way you would expect.
They never attacked the sandbox.
The escape is a file, not an exploit
The agent, in every one of these findings, stays inside its box and follows every rule it was given. It does not break out. It writes a file. And that file is later read, loaded, run, or scanned by a trusted tool that lives outside the box — at which point the escape happens on its own, executed by the grown-up, not the child.
This is the oldest trick in security wearing new clothes. It is the confused deputy: you can't reach the thing you want, so you get something more privileged than you to reach it on your behalf. Pillar's name for the class is Configuration-Based Sandbox Escape, and the specifics are almost boringly mundane, which is exactly what makes them dangerous:
In Cursor — now tracked as CVE-2026-48124 and fixed in version 3.0.0 — a configuration file for Claude hooks could be written such that commands ran outside the sandbox. The agent writes a config file. A trusted host process reads the config file and does what it says. No sandbox was harmed in the making of this escape.
In Codex CLI, the agent's "safe command" allowlist trusted git show by name, on the assumption that it is read-only. The actual invocation was not read-only. OpenAI patched it in v0.95.0 and paid a high-severity bounty. The allowlist checked the name of the command, not what the command was actually told to do — a distinction an attacker lives in.
And the one that should make everyone sit up: a single Docker socket finding hit Codex, Cursor, and Gemini CLI all at once. A privileged local daemon that the agents could reach became an unsandboxed place to run code. If that sounds familiar, it is because we published a post this morning about ENCFORGE ransomware using a mounted Docker socket to escape a container and encrypt AI models on the host. Same primitive, different week, different attacker. The Docker socket is the skeleton key of the container era, and both a nation-grade agentic ransomware crew and a benign security research team reached for it in the same seven days.
Why this is a class problem, not a bug list
We have a beat here we care about — which AI agent held the line and which one folded when someone pushed. Usually we can report a winner. Not this time, and the absence of a winner is the finding.
This is not "Cursor had a bug." It is that four independently built agents, from four serious engineering organizations, all shipped the same category of hole, because they all made the same architectural assumption: that a sandbox around the agent is a boundary. It isn't, if anything the agent writes gets consumed by something you trust more than the agent. The boundary is not the wall around the agent. The boundary is every tool, hook, allowlist, and daemon that reads what the agent produces. Each of those is a door, and most teams never drew them on the map.
Most of these are patched now, and that matters — update Cursor to 3.0.0, Codex to v0.95.0, and take the Gemini CLI and Antigravity fixes. But patching the four named findings does not close the class. Pillar published these as a series they called the Week of Sandbox Escapes, one write-up a day, precisely because the pattern generalizes past any single tool.
What to actually do
If you run AI coding agents — and if you write software in 2026, you probably do — stop treating the agent's sandbox as your security boundary and start treating the trust relationships around it as the real perimeter.
Concretely: do not mount the Docker socket into anything an agent can reach, full stop; it converts an app-level foothold into host-level code execution and it is the single most repeated mistake in this entire genre. Audit what your agent is allowed to write and, more importantly, what trusted tools automatically consume those writes — hook configs, task runners, allowlisted commands, file scanners, IDE integrations. Assume any allowlist that trusts a command by name can be defeated by the command's arguments. And keep the agents themselves current, because the vendors are now actively patching this class and running an old version is opting out of that work.
We hold this at 95 percent, as always — the research, the CVE, and the reproductions are Pillar Security's work by Eilon Cohen, Dan Lisichkin, and Ariel Fogel, corroborated by the trade press, not our own capture. What is ours is the frame we keep returning to: the interesting attacks of this era do not break the wall, they borrow the trust of whoever stands on the other side of it. Ransomware crews do it through a Docker socket to reach a filesystem. Researchers do it through a config file to reach a shell. The agent followed every rule. The rules were the vulnerability.
Sources: Pillar Security, "The Week of Sandbox Escapes" (July 2026), via Pillar Security and BleepingComputer. Cursor sandbox escape is CVE-2026-48124 (fixed 3.0.0); Codex CLI fixed in v0.95.0 with a CVE pending. No network indicators are associated with this research; nothing was ingested. Companion piece: our July 21 coverage of ENCFORGE using the same Docker-socket primitive.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.