What OpenAI says
On 4 November OpenAI published the results of an automated pipeline run against the Linux kernel in October. Its agents scanned about 2.8 million lines that ordinary users can reach, roughly 7% of the kernel, produced 2,308 candidate findings, reproduced 1,724 of them in virtual machines, and built 948 separate local privilege-escalation exploits, for about US$1.21 million over 10 days with human researchers reviewing the output (vendor, via iTnews).
The line that matters for buyers is not the count. OpenAI says a low-privileged account on an unpatched system "should be considered functionally equivalent to root access for a well-resourced threat actor" (vendor, via iTnews).
Read every figure here as OpenAI's own. iTnews notes that parts of the research cannot yet be independently verified (independent, iTnews). OpenAI's post would not load for our tools, so we work from that report of it. Our 6 November note covered the patch-speed question. This one covers what the patch window leaves exposed.
The consequence: every shared kernel is a root host
A standard container is a set of kernel features: namespaces, cgroups, and a filtered system-call list. They separate workloads only while the kernel underneath holds. A kernel privilege escalation crosses all of them at once.
OpenAI gives its own example. In a July internal test, its agents found a publicly disclosed flaw, CVE-2026-53362, in the host's Linux kernel and "took root control of the underlying worker node" (vendor, via iTnews). Root on a node reads every secret mounted into every pod on that node.
OpenAI also says 61 of the escalation flaws were already patched upstream by other contributors, 43 had staging patches, and 299 more were under public discussion (vendor, via iTnews). iTnews presents those counts against the 948; on that reading, about 11% were patched or staged when OpenAI published (our maths: 61 plus 43, divided by 948). Until the rest ship, your container boundary is only as strong as a kernel you cannot yet fix.
OpenAI's recommendation is defence in depth, "such as sandboxing and isolation with Firecracker and gVisor" (vendor, via iTnews).
Which workloads need a second boundary
The question is not whether you run containers. It is where code you did not write runs as a local user beside something you care about.
| Workload | Who writes the code | Shared kernel acceptable? | Boundary to use |
|---|---|---|---|
| AI agent and code-interpreter sandboxes | A model, steered by prompts and tool output | No | MicroVM or VM per session, no standing secrets inside |
| CI runners building pull requests or third-party code | Contributors, dependencies, build scripts | No | Ephemeral VM or microVM per job |
| Customer code in your product: plugins, notebooks, scripts | Your customers | No | MicroVM or gVisor per tenant |
| Shared bastions, jump hosts, multi-user Linux desktops | Many staff accounts | Only with fast kernel patching | Fewer shared logins, per-user VMs where practical |
| First-party services on Kubernetes | Your engineers | Yes, if patched fast | Standard containers; your patch window is the control |
The first three rows have one thing in common: the attacker does not need to break in first. The local foothold OpenAI's exploits assume is the workload's normal job.
The options, in their makers' words
| Runtime | What it puts between the workload and the host kernel | Cost its makers state |
|---|---|---|
| Standard containers | Nothing beyond kernel features | None; the host kernel is the whole boundary |
| gVisor | "An application kernel" that "intercepts application system calls and acts as the guest kernel" (vendor, gVisor) | "Reduced application compatibility and higher per-system call overhead"; may perform poorly for system-call-heavy workloads (vendor, gVisor) |
| Kata Containers | Each container or pod in its own lightweight VM with a separate guest kernel (vendor, Kata Containers) | Not stated in the overview we read |
| Firecracker | MicroVMs on KVM with a minimalist device model, built at AWS for Lambda and Fargate (vendor, Firecracker) | Not stated in the README; by design it excludes unnecessary devices and guest-facing functionality |
A second boundary is not immunity. OpenAI says testing of its own infrastructure "turned up many vulnerabilities in Kata, Moby/Docker, gVisor and other projects" (vendor, via iTnews). It has not said which, in anything we read. A sandbox narrows the attack to a smaller, separately patched surface. KVM still runs in the host kernel, so the host still needs patching.
Six steps
Prerequisites: a list of Linux hosts and node pools, and who owns each.
- Step 1. Find every place untrusted code runs as a local user. Agent sandboxes, CI runners, notebook servers, plugin hosts, shared bastions. Owner: platform engineering lead.
- Step 2. Classify each against the matrix. Record the current boundary: shared kernel, gVisor, or VM. Owner: CISO with platform engineering.
- Step 3. Move agent sandboxes and CI runners first. They run the most code nobody reviewed. Test compatibility and overhead on your own workload before committing; we have not measured any of these runtimes. Owner: platform engineering.
- Step 4. Take secrets off shared nodes. A rooted node reads what is mounted on it. Use short-lived, per-workload credentials and keep long-lived keys out of sandboxes entirely. Owner: security engineering.
- Step 5. Keep patching the hosts under the sandboxes. Fix reboot capacity for kernel updates, as set out in our patch-speed note. Owner: infrastructure lead.
- Step 6. Ask every vendor that runs your code one question. CI services, agent platforms, notebook hosts: what separates my workload from another tenant's, a shared kernel, gVisor, or a VM? Put the answer in renewal terms. Owner: procurement with the CISO.
Trade-offs
- Move everything to microVMs. The strongest boundary, but it changes images, networking, and start-up behaviour. Reserve it for the rows that run untrusted code.
- Use gVisor. Less change to how you package workloads. Its makers state the cost: some system calls and files are missing, and system-call-heavy work slows down.
- Patch faster and stay on shared kernels. Right for first-party services. Wrong for agent sandboxes and CI, where the foothold is the job.
Missing
- OpenAI's own post. It would not load for our tools, so we have not read its wording, method, or caveats.
- Independent verification of the 948. iTnews says parts cannot yet be verified.
- Which Kata, Docker, and gVisor flaws OpenAI found, and whether they are fixed.
- OpenAI's model and the distribution it tested, both withheld per iTnews.
- A test by Prestanda. We have not measured isolation overhead or run these steps in a client estate.
Frequently asked questions
Does this mean containers are unsafe?
Not for first-party code on hosts you patch quickly. It means a container is not a boundary against code you did not write while known kernel flaws are unpatched.
Is gVisor or a microVM enough on its own?
No. OpenAI says it also found vulnerabilities in Kata, Moby/Docker, and gVisor. A second boundary reduces what an attacker can reach, and the host kernel under it still needs patching.
Where should we start?
With AI agent sandboxes and CI runners. Both run unreviewed code as a local user by design, so they already have the foothold the 948 exploits assume.
Living page. Last updated 7 Nov 2026. We update this note when OpenAI's post can be read or an independent test appears.