Facts checked Nov 6, 2026
We would plan as if a foothold on a shared Linux host can reach root, after OpenAI said on Nov. 4 that one run of its agents built working root exploits for 948 kernel flaws.
What to decide
Decide which Linux hosts run code you do not fully trust and what stops one lost host taking the rest. An attacker needs a foothold first, and as of Nov. 6 we found no report of these exploits in use, released or independently reproduced.
What OpenAI reports
In a mid-October run, by OpenAI's own figures, its agents produced 2,308 candidate findings, reproduced 1,724 and built 1,169 working local privilege escalation exploits. OpenAI counts 948 distinct patches behind those exploits as its number of unique flaws. The run cost $1,213,430 in API credits, or $1,279 per flaw, which OpenAI calls more an upper bound, with no researcher or VM cost given. The model, GPT-6 Cyber, was limited to approved customers as of Nov. 5, and OpenAI sells this capability.
What limits it
OpenAI names no distribution or kernel version and says nothing about LTS or enterprise kernels, so we cannot tell how many of the 948 exist on yours; it scanned the latest master branch. The human review it describes is its own. Its targets ran a stock desktop OS with default protections on, including SMEP, SMAP and KASLR, so we would not count on default hardening.
Why patching is not enough
OpenAI says a low-privileged account on a host not up to date should count as root for a well-resourced attacker. We would go further where that attacker is in your threat model. By Nov. 5 OpenAI had disclosed 304 critical findings to maintainers with candidate patches and gave no merged count. If those sit inside the 948, OpenAI had yet to disclose 644, so a fully patched host may have had no fix to apply for flaws its kernel contains.
OpenAI recommends Firecracker and gVisor to limit damage. Its Oct. 23 post says its agents chained flaws into microVM escapes, in tests with source code and configuration, and that OpenAI contributed fixes to Kata Containers, gVisor and Moby/Docker. It names neither Firecracker nor the escaped microVM. We read isolation as raising the cost and needing its own patches.
OpenAI designs its outer network controls to hold after a host is lost. Its agents found flaws giving limited internet access in almost every service left open, though OpenAI found no route they could trivially exploit unseen.
OpenAI predicts that within the next few years weaker models may build exploits for disclosed flaws. Microsoft's own 2026 data puts the median vulnerability on Linux servers, not kernel flaws alone, at 10-plus weeks to patch. We read that as a case for a faster kernel cycle.
What to do now
- Platform, this quarter: CI runners with untrusted or cross-team code get one throwaway VM per job and job-scoped secrets. On shared-kernel container nodes, split by trust level or use a sandboxed runtime; assume node credentials leak if one tenant gets root.
- Infrastructure, this month: on shared hosts, jump boxes and dev servers, cut accounts, stored secrets and long-lived keys.
- Security engineering and the CISO, this month: count an RCE as a service user as root, and reopen exceptions and ratings that lean on "non-root" or "local only" for internet-facing apps.
- Infrastructure, next patch cycle: track the running kernel, not the installed package, and shorten the reboot or live-patch cycle. With no CVE list, stay on your distribution's current kernel.
- Network and identity, this quarter: limit each host's egress and credentials. Alert on unexpected non-root to root moves, since OpenAI withholds technique details.
A single-purpose host where only admins run code gains little here.
