OpenAI's Agents Found 948 Ways to Root Linux — at $1,279 a Path

An unprivileged account on a Linux machine that is a few patches behind is now, in practice, root — if the attacker has a frontier model and a budget. That is not our reading of a trend piece. It is the conclusion OpenAI drew from its own run, published on 4 November 2026, and the arithmetic behind it is the interesting part: 948 working local privilege escalation exploits for $1,213,430 in API credits, or $1,279 per root shell.[1]

What actually happened

OpenAI's Cyber team built a five-stage pipeline — vulnerability discovery, dynamic validation, exploitability assessment, patch generation, and human review — and pointed it at the Linux kernel in mid-October 2026. The model at its core is described only as "an upcoming cyber model", not a released product.[1]

The funnel is public and unusually specific. Scout agents picked 5,034 audit targets, about 2.8 million lines and roughly 7% of the kernel, for $3,426. Analyst agents produced 2,308 candidate findings within 12 hours for $316,549. Triage agents then reproduced 1,724 of them (74.7%) inside isolated KASAN virtual machines within 30 hours for $73,330 — and OpenAI reports that only 3.1% of the failures were the model analysing code incorrectly; the rest were races, trigger conditions, or privilege requirements that fell outside the validation budget.[1]

Exploit development is where the money went. A screening agent narrowed 1,724 validated bugs to 313 information-leak and 1,238 LPE candidates for $44,194, then ExploitDev agents produced 291 leak proof-of-concepts and 1,169 working LPE exploits for $775,929, with protections like SMEP, SMAP, KASLR and HARDENED_USERCOPY enabled. Variant analysis collapsed those exploits into 948 distinct vulnerabilities, each with a candidate patch.[1]

The targets were not weakened. They ran a stock desktop distribution under the same threat model used by Pwn2Own and TyphoonPWN competitions — where a Linux kernel LPE has historically been worth $20,000 and $70,000 respectively. Applying those figures to 948 exploits gives a hypothetical value of $18.9M–$66.3M, or 16x to 55x the pipeline's cost.[1]

A second campaign against an adapted kernelCTF environment — a kernel with deliberately reduced attack surface — produced 25 leak PoCs and 21 LPE exploits for about $32,936. Those 21 bugs, if accepted at programme rates, would be worth around $1.5M: roughly 45x the scanning cost. For scale, kernelCTF had accepted 26 confirmed zero-day LPEs across all of 2026 at the time of writing.[1][2]

The part that should worry a defender

The ten-day patch race is real, and it is not being lost. While the scan ran, 61 of the reported LPEs were already patched upstream, 43 had staging patches, and 299 were in public discussion.[1] The kernel community has not gone quiet; the discovery rate simply changed.

The model got better fast. In late July 2026, GPT-5.6 Sol found and exploited 166 unique LPEs for $513,690 end to end. Mid-October's model found 948 for $1,213,430 — more than 5x the bugs at roughly 2.4x the cost, on the same harness, after three months of upstream hardening.[1]

It is not pattern-matching. Sampling 166 of the generated exploits, OpenAI counted at least 10 exploitation techniques it believes are novel — two new persistent elastic objects for kernel-cache spraying, two new page-grooming methods for reliability, five data-only techniques, and one arbitrary type confusion — and says third-party kernel exploitation experts had not seen them either.[1] The technical details are deliberately withheld.

It also found a bug in the test rig. During the kernelCTF run, an agent hit an unexpected crash while probing privilege transitions and traced it to a QEMU TCG flaw, without access to QEMU's source, and exploited it. The bug was already fixed upstream but not in the release build in use.[1]

OpenAI's own recommendation is blunt: for the near and medium term, a low-privileged account on an operating system that is not current on patches "should be considered functionally equivalent to root access for a well-resourced threat actor" — and isolation layers such as Firecracker and gVisor matter because they limit the blast radius after the bug is hit, not because they prevent it.[1]

Why it matters for Indian SMBs and mid-market teams

Almost every small Indian business already runs this software. The Linux kernel is under Android, cloud VMs, NAS boxes, routers, CCTV recorders and the ₹400-a-month VPS that hosts the company website and the billing app. The realistic attack path was never a nation-state cracking the perimeter; it is a compromised WordPress plugin, a shared-hosting account, or a leaked SSH key — a low-privileged local account — and then an LPE to root, then the neighbouring containers.[1]

"We are behind a firewall" is not the control that matters any more. The threat model here is post-authentication. Ask the practical question: if an attacker gets one unprivileged shell today, how far do they get, and how do you know? Most SMB stacks we see cannot answer the second half, because nobody records kernel and package versions per host, or the date of the last successful patch cycle.

Patching cadence is now a security boundary you have to prove. The gap between "a fix exists upstream" and "the box is patched" is where these 948 exploits live. A monthly reboot is not a patch. A patch policy with a named owner, a maintenance window, a reboot test, and a log of what version ran on which date is the evidence an auditor — or an insurance questionnaire — will eventually ask for.

The asymmetry cuts both ways, briefly. At roughly $1,279 per exploit in raw API spend, offensive capability has become a line item, not a research programme. Defenders get the same models: the same pipeline can be pointed at your own codebase to find the bugs before someone else's does, which is exactly what OpenAI argues automated patch generation is for.[1]

Containers are not a security boundary by themselves. Docker on a shared host reduces convenience-risk, not kernel-risk: a kernel LPE escapes the container. If you are consolidating ten services onto one VPS to save money, that is a deliberate concentration of kernel risk and should be written down as such, with gVisor or a separate host for anything customer-facing.

The uncomfortable 2027 question is provenance. If a capable model can find vulnerabilities in any code, "we bought it from a vendor" stops being a security answer. Buyers will start asking for patch SLAs, SBOM-level component versions, and evidence of a re-scan after each model generation — the same paperwork we already build for asset registers.

Where Guruji Corporation fits in

We did not run this pipeline and we do not sell exploit capabilities. What we build is the boring half that this research assumes exists: a per-host inventory that records kernel and package versions with their last patch date, a container-isolation review that names which services share a kernel and why, a patch log with an owner and a window, and an incident trail that survives an audit six months later.

If any of that is missing on your servers today, the honest starting point is a two-week baseline — inventory, patch state, isolation boundaries — before any tooling purchase. Start with a short project brief and we will scope it against what you already run.

Sources

• OpenAI — A thousand fewer paths to root (4 November 2026)
• kernelCTF — programme rules and scoring (Google Security Research)
• OpenAI — Patch the Planet (Daybreak initiative)
• OpenAI — Securing our frontier model training environment (infrastructure hardening findings)
• Pwn2Own Berlin 2026 — target and bounty list (Zero Day Initiative)
• TyphoonPWN 2026 — competition targets