OpenAI's 948 Linux Kernel Exploits: What the $1.2 Million Test Proved

OpenAI's October run shows that a funded agent pipeline can turn a kernel scan into validated local root exploits for about $1.2 million in API credits. It does not show 948 fixed flaws: ten days in, 61 of the bugs were patched upstream,⁠¹ and outlets disagree on whether 948 counts exploits or patches.⁠¹⁠² OpenAI's own post could not be opened for this article, so every figure below comes from outlets reporting it.

The claim: 948 root exploits for $1.2 million

Reported OpenAI's 4 November report, "A thousand fewer paths to root," says its agents produced 948 local privilege-escalation (LPE) exploits, each turning an unprivileged user into root, for $1,213,430 in API credits, about $1,279 each.⁠¹ OpenAI values the bugs at $18.9 million to $66.3 million at past Pwn2Own and TyphoonPWN payouts, 16 to 55 times the cost.⁠¹ It warns that an unpatched low-privileged account is "functionally equivalent to root access for a well-resourced threat actor."⁠²

GetCoreTech could not open OpenAI's post, which returned an error. The figures here come from CSO Online, SecurityWeek, Techzine and two summaries, all published 4 to 6 November. SecurityWeek mentions no in-the-wild exploitation.⁠²

The strongest case for the result

The pipeline is more careful than the headline suggests. Scout agents picked 5,034 audit targets reachable by low-privilege users, about 7% of kernel code; analyst agents scanned them; triage agents wrote a proof of concept and ran it in a virtual machine with the KASAN memory-error detector until it reproduced.⁠³⁠⁴ Exploit agents then ran against the stock distribution hardening features SMEP, SMAP and KASLR on the mid-October kernel master, and human researchers reviewed everything before reporting.⁠⁴

Reported The yield beat June's. OpenAI reports five times as many unique LPEs as its earlier GPT-5.6 Sol experiment, despite three months of kernel hardening, and at least 10 novel exploitation techniques by its own count.⁠¹ A separate run against a hardened kernelCTF target produced 21 LPE exploits in 112 hours for about $32,936.⁠⁴

For direction, the steelman wins.

The funnel and the bill, stage by stage

Shares below are GetCoreTech's arithmetic on the reported counts.

What 948 counts

CSO calls 948 distinct LPE exploits.⁠¹ SecurityWeek says it is the number of separate patches for the bugs behind the exploits, and reports 1,169 LPE exploits plus 291 information-leak proofs of concept.⁠² Techzine's headline says root exploits, its body counts vulnerabilities, and it says overlap between exploits is unclear.⁠³ An unsigned Korean-language summary also reads 948 as patches and says the gap to 1,169 is never explained.⁠⁵ Without OpenAI's post, GetCoreTech cannot settle it.

Every per-unit figure below inherits that choice.

What the $1.2 million covers

By one summary's itemization, exploit development cost $775,929 (64% of the bill), discovery $316,549 (26%) and validation $73,330 (6%).⁠⁴ Those three total $1,165,808, leaving about $47,600 unitemized; another summary reports stage figures that sum to within $2 of the total, so a fourth stage may exist.⁠⁵ OpenAI calls the total an upper bound.⁠⁴

The per-exploit price depends on the denominator. The reported $1,279 divides the bill by 948;⁠¹ by 1,169 it would be about $1,040. Two summaries put an average successful exploit attempt near $360, and one puts each of 69 failed attempts at $3,922, about 11 times as much.⁠⁴⁠⁵ None of the summaries prices the human review. Against July's scan, 166 LPEs for $513,690 or about $3,094 each, October's all-in figure is about 59% lower, though models, targets and kernels differ.⁠²

OpenAI's $18.9 million to $66.3 million value is 948 times a $20,000 to $70,000 payout range, so it inherits the unit question and assumes every bug would win a bounty; CSO notes these are not actual payouts.⁠¹

Exploits are not fixes

Reported Ten days into the campaign, 61 of the LPE bugs were fixed upstream, 43 had staging patches and 299 were under public discussion, by OpenAI's account.⁠¹ Against 948, that is 6% fixed upstream and 11% fixed or staged. The 299 may overlap the others, and no source gives the denominator or the number of OpenAI patches merged.⁠¹⁠⁵ OpenAI says it is sending the rest in stages through its Patch the Planet partners.⁠²

Human researchers reviewed findings before anything went to kernel maintainers.⁠² OpenAI's own account of the pipeline's errors is specific: in an early run, 20 of 200 "successful" exploits, 10%, reached root through a different zero-day than the one assigned, and generated patches sometimes made unnecessary changes, traded away performance or missed related variants.⁠¹ Techzine reports 3.1% of candidate findings rested on flawed analysis.⁠³

The objection: cheap exploitation is the result, and fixes are a separate job

The strongest objection is that the test measured what it set out to measure: how cheaply a funded lab can find and exploit kernel bugs. Patch status belongs to the maintainers, and OpenAI says it is staging disclosure. That is fair, and it is the point. Tom's Hardware reported on 1 September that the kernel was nearing 2,000 CVEs per release, that networking maintainer Jakub Kicinski estimated one-third to one-half of 648 net-next patches in a cycle were AI-driven low-priority fixes, cleanups or clarifications, and that he wrote, "We are completely overwhelmed."⁠⁶ Greg Kroah-Hartman barred LLM-generated patches from the staging subsystem except for real security fixes.⁠⁶

Cheap exploits delivered to a human queue are limited by that queue, which is why 61 of 948 at ten days matters more than 948.

Opinion The test proved that finding and exploiting kernel bugs has become cheap for a funded lab. It did not prove 948 fixes, 948 independent vulnerabilities or 948 real-world risks.

What would change this

OpenAI publishing CVE identifiers and the mapping from exploits to patches would settle what 948 counts. If it resolves to 948 distinct vulnerabilities with upstream commits, the unit doubt falls. An independent reproduction of a sample of the exploits on stock kernels, the validation Yash Kadakia of Security Brigade says buyers should require,⁠¹ would test the pipeline's own checks, which let 20 of 200 wrong-zero-day results through in an early run.

Merged-patch counts with a stated denominator at 30, 60 and 90 days would answer the fix question: if most of the 948 merge unchanged, the maintainer-queue argument weakens. A listing of any of these bugs in CISA's Known Exploited Vulnerabilities catalog would change the risk reading.

What to do with it

Treat this as urgent if you run untrusted or semi-trusted code on shared kernels. IDC research director Sakshi Grover names multi-tenant hosts, CI/CD runners, shared bastions, container platforms and developer fleets, and says the bigger risk is the delay between discovery and fixes reaching production, since an upstream patch does not guarantee a fix in enterprise distribution kernels.⁠¹ Ask your distributor for backport dates, and isolate those hosts: OpenAI's mitigation advice names sandboxing with Firecracker or gVisor.⁠² If nothing untrusted runs locally, keep your normal patch cadence.

Rescan old code as models improve and revalidate against upstream fixes, OpenAI's defender advice as summarized by AI/TLDR.⁠⁴ Two mistakes to avoid when repeating the story: calling 948 fixed flaws, and quoting the 16-to-55-times multiple as realized value.