OpenAI says an automated pipeline running an unreleased cyber model produced 948 distinct working Linux kernel root exploits in a single run, at an API cost of roughly $1.2m. For UK organisations the message is blunt: local privilege escalation on unpatched Linux should now be treated as cheap, fast and plentiful.
What happened
On 4 November 2026 OpenAI published a research report titled “A thousand fewer paths to root”, announced in a thread on X. It describes a run carried out in mid-October in which a set of AI agents, powered by what the company calls an upcoming cyber-focused model, worked through the Linux kernel looking for ways an ordinary, unprivileged user could become root.
The pipeline started with 2,308 candidate findings and managed to reproduce 1,724 of them in a test environment. From those it built 948 distinct local privilege escalation (LPE) exploits that worked, plus proof-of-concept code for 291 information-leak bugs, and it wrote a candidate patch for each of the 948. The Hacker News reports that the exploitation run took about 30 hours. OpenAI put the bill at $1,213,430 in API credits, which works out at roughly $1,279 for each distinct flaw.
The company also says its agents used at least ten exploitation techniques that neither its own staff nor the outside kernel experts it consulted had seen before. Details are being withheld for safety reasons.
The pace is the story. In June an earlier OpenAI model produced 24 working kernel exploits under its Patch the Planet effort; October’s run produced nearly forty times as many.
The technical picture
The pipeline has five stages: discovery, dynamic validation in a sandbox, an exploitability assessment that produces a proof of concept, patch generation, and finally human review before anything goes to kernel maintainers. According to PBX Science’s account of the report, “scout” agents first chose about 5,034 audit targets that a low-privileged user can reach, roughly 7% of the kernel’s code. Triage agents then reproduced suspected bugs on isolated virtual machines, and exploit-development agents tested their work against the protections of a stock distribution.
A few caveats matter. First, 948 is a count of validated exploits with candidate fixes, not of shipped patches. PBX Science reports that when the scan and manual analysis finished, 61 of the flaws had been fixed upstream and 43 more had patches in staging. OpenAI says it is submitting reports in priority order, following Linux kernel community guidance, and releasing the rest in stages with its partners. Second, the same report notes that the test kernel did not support the SLAB_VIRTUAL hardening feature, so that protection was switched off. In a separate, harder test modelled on Google’s kernelCTF programme, the yield was far lower: 21 privilege escalation exploits over 112 hours.
Even so, the cost comparison stands out. Using past Pwn2Own and TyphoonPWN payouts, OpenAI values the exploits at $18.9m to $66.3m, between 16 and 55 times what the run cost.
Why it matters for UK organisations
Linux runs most of the UK’s cloud workloads, web estates, containers, network appliances and a fair amount of operational technology. Most of those systems depend on the assumption that a foothold as a low-privileged user is a long way from full control. OpenAI’s own advice turns that assumption on its head. For now, it says, a low-privileged account on an unpatched host is, for a capable and well-funded adversary, little different from root itself.
The research fits the wider trend. Google Threat Intelligence Group figures cited by The Hacker News show monthly vulnerability disclosures rising from 5,045 in January 2026 to 10,740 in August. The NCSC’s assessment on AI and cyber intrusion, published the day before OpenAI’s report, sets out a 2028 baseline scenario in which widely available AI tools have almost certainly driven a significant rise in zero-day discovery, and internal patching and testing processes must evolve.
The uncomfortable part is the gap between finding and fixing. Defenders benefit only once a fix is merged upstream, rebuilt by a distribution, tested by a vendor and deployed by an operator. Appliances built on old kernels may never be patched at all, while an attacker with comparable tooling faces none of those delays.
Expert view
For years, Linux privilege escalation on an engagement has been a matter of patience and craft: enumerate the host, check the kernel version, look for misconfigurations, and only occasionally find a reliable kernel bug. The craft is not going away, but the scarcity is. If a validated root exploit costs a few hundred to a few thousand dollars in compute, the question stops being whether one exists for your kernel and becomes how soon somebody runs the pipeline.
I would be wary of the more dramatic readings: this is a vendor’s own research, the hardened test yielded far less, and independent review is still to come. The direction, though, is clear.
In my experience, the organisations that cope best with a surge like this are not the ones with the cleverest detection. They are the ones that already know exactly which kernels they run and can rebuild a host quickly. Assume a breach at user level and design for it: limit who can get a shell, and treat container escape and lateral movement as the controls that really count.
There is also a pressure point for the open source supply chain. Kernel maintainers now face a large volume of AI-generated reports and patches. OpenAI stresses that human review and maintainer-controlled patching remain essential. Review capacity is now the bottleneck, and UK businesses that rely on Linux have a stake in funding it.
What to do now
- Inventory your kernels. List kernel versions across servers, container hosts, appliances and OT gateways. You cannot prioritise what you cannot see.
- Shorten the patch cycle for Linux. Cyber Essentials already expects high and critical updates within 14 days. Aim to beat that for internet-facing and multi-user hosts, and use live patching where your distribution supports it.
- Reduce who can run code locally. Remove shared and dormant accounts, restrict interactive shells, and review CI runners, jump boxes and build servers where untrusted code runs as an ordinary user. This maps to the Cyber Essentials user access control and secure configuration controls.
- Turn on kernel hardening. Enable the mitigations your distribution offers, restrict unprivileged user namespaces and eBPF where workloads allow, and run untrusted workloads in stronger isolation such as separate virtual machines.
- Plan for end-of-life devices. Identify appliances on kernels that no longer receive fixes and segment them, put compensating controls around them, or schedule their replacement.
- Watch for post-exploitation. Make sure endpoint and audit logging on Linux hosts would flag unexpected privilege changes, new setuid binaries and kernel module loads.
Bottom line
OpenAI’s run does not mean 948 live zero-days are loose on the internet. They are being reported to maintainers in stages, and the hardened test was far less productive. What it shows is that kernel root exploits are becoming an industrial product, cheaper than ever to produce. UK organisations should respond by tightening the basics they can control: knowing their estate, patching Linux faster, and making a low-privileged foothold worth as little as possible.
Sources
- The Hacker News: OpenAI AI Pipeline Generates 948 Linux Root Escalation Exploits in 30-Hour Run
- PBX Science: OpenAI’s AI Pipeline Validates 948 Linux Root-Access Exploits in One $1.21 Million Run
- RuntimeWire: OpenAI says its agents exploited and patched 948 Linux kernel flaws for $1.2M
- OpenAI: A thousand fewer paths to root
- NCSC: Artificial intelligence and cyber intrusion
