OpenAI says an agent pipeline running an unreleased cyber model produced 948 working local-root exploits against the Linux kernel, on about $1.2 million of API credits. That works out to roughly $1,280 each. Every Linux sandbox on a shared kernel now has a rough price, and the rules inside the sandbox don't change it.
Take the numbers as a vendor's numbers. OpenAI's post wouldn't open for me, so all of this comes through Help Net Security and a DEV Community breakdown. The cost is credits only, and security researchers review each exploit before anything goes to maintainers. I found no reaction yet from kernel maintainers.
The mechanism is the plain part. Scout agents cut 40 million lines down to the code worth reading, analysts proposed bugs, triage agents tried to trigger each one in a VM, exploit agents went after the strongest. The DEV write-up says targets were reachable by low-privileged users, on test machines with SMEP, SMAP and KASLR on. That's roughly the position of a job you handed an unprivileged uid and called contained.
What's Under the Sandbox
Claude Code says on Linux it "uses bubblewrap for isolation". Codex says "Linux uses bwrap plus seccomp by default." Both are good tools, and both are the same deal: the sandboxed process makes its syscalls to the host's kernel. Same for a default Docker container. Seccomp narrows the door (Docker's profile disables "around 44 system calls out of 300+"), and nothing here says how many of the 948 survive that, since neither write-up mentions containers. So don't read this as 948 container escapes. Read it as the one component everything shares being the thing that got cheap to break.
I argued recently that subtraction never finishes because the machine always has another door. This is the door under the floor. No deny list reaches it.
The Check
On any box that runs containers for code you didn't write:
runc means your containers talk to the host kernel directly. On Kubernetes, the same question is which pods run without a runtimeClassName that points somewhere stronger.
What to Change
- Put a kernel between the job and the host, where the code is untrusted. A VM per workload (Firecracker's "virtual machine barrier") or gVisor, which "intercepts application system calls and acts as the guest kernel". Agents that run dependencies they just installed count as untrusted.
- Throw the host away. GitHub says its hosted runners use "ephemeral and clean isolated virtual machines", while self-hosted ones "can be persistently compromised by untrusted code in a workflow". A long-lived shared runner is where a local root pays off most.
- Keep credentials off the box. Root on a host with nothing on it is a much smaller story.
The Tradeoff
VMs cost startup time, density and GPU pain, and gVisor costs syscall performance and some compatibility. I wouldn't do this for a trusted team's internal builds. It's also a patch, not the answer: I think repo, shell and network aren't the primitives agents end up living in, and a VM around a human's computer is still a human's computer.
Patching won't carry this alone. When the 10-day run ended, 61 had a fix upstream and 43 a staging patch. The rest are headed to a community whose networking maintainer already wrote "We are completely overwhelmed". Each fix is also a public commit, which starts its own clock.
The model stays gated for now. My bet is that doesn't last: open models catch up, and attackers never asked anyone for access. Price your sandbox as if they already have it.