OpenAI spent $1.2M on 948 Linux exploits. The patches are still a promise

OpenAI's security team published a number on 4 November that will be quoted for the rest of the year: 948. That is how many distinct Linux kernel privilege-escalation vulnerabilities its autonomous pipeline says it found, exploited and wrote patches for in one campaign, for $1,213,430 in API credits. The work is substantial and the write-up is more detailed than most vendor research. It is also the kind of result where headline and evidence drift apart: the pipeline produced exploits and candidate patches, and whether the kernel accepted any of them is a question OpenAI does not answer.

What the pipeline actually produced

The funnel is the most useful thing in the document. Scout agents picked 5,034 audit targets, about 2.8 million lines or roughly 7 percent of a 40-million-line kernel, reachable by unprivileged users. Analyst agents produced 2,308 candidate findings in twelve hours. Triage agents built proofs of concept and ran them under KASAN, reproducing 1,724 of them, 74.7 percent, within thirty hours; OpenAI says only 3.1 percent of the misses were bad analysis. Screening split the survivors into 313 leak and 1,238 privilege-escalation candidates, and exploit agents produced 291 leak proofs and 1,169 working root exploits against a target with SMEP, SMAP, KASLR and HARDENED_USERCOPY enabled. Variant analysis collapsed those exploits into 948 distinct vulnerabilities, each with a generated patch.

Stage	API credits
Scout agents (target selection)	$3,426
Analyst agents (candidate findings)	$316,549
Dynamic validation (reproduction)	$73,330
Exploitability screening	$44,194
Exploitation (leak and privilege escalation)	$775,929
Total	$1,213,430

The distinction that gets lost is between 1,169 and 948. The first is exploits; the second is bugs, after 221 exploits turned out to duplicate something already counted. OpenAI's own opening paragraph says the run produced "948 local privilege escalation exploits", which is not what its methodology section says, and most coverage since repeated the summary rather than the body.

Three words, three different claims

"Patched", "exploited" and "candidate patch" are not synonyms, and this story uses all three. A candidate patch is a diff the model wrote and OpenAI's researchers reviewed before it left the building. It becomes a fix when a subsystem maintainer reads it, argues with it and merges it into a tree that ships. Nothing in the account establishes that for even one of the 948.

What the post offers instead is a progress snapshot: ten days in, 61 of the LPEs had been patched upstream, 43 had staging patches and 299 were being discussed publicly. OpenAI attributes part of that movement to other people, describing "over 100 Linux LPEs" fixed or staged "from other contributors". It also says it has sent "hundreds of reports and patches" for critical vulnerabilities. Those sentences do not add up to a merge count, and coverage that turned them into patches on the way was reading a progress bar as a receipt.

The "30-hour run" in several headlines is narrower than it sounds. Thirty hours is validation. Discovery ran twelve hours before it, exploitation and patching came after, and human analysis was not finished until ten days in.

The kernel has a rulebook for exactly this

The kernel's security documentation reads as though written in anticipation of this week. It requires a stable affected version or commit, says a time-dependent version such as "latest mainline" is not acceptable, and that versions of kernels not from kernel.org "are meaningless to maintainers and will not be processed". It notes that "a significant part of reports are for bugs that have already been fixed", which is what happens when a scan runs against a branch that moves beneath it.

OpenAI says it scanned "the latest Linux kernel master branch" in mid-October and that target machines ran "a stock desktop operating system". It names no commit, distribution or kernel version, so nobody can rebuild the target, and the two statements describe kernels that are not obviously the same one. The instruction for AI-assisted findings is blunter: treat the bug as public, because such findings "systematically surface simultaneously across multiple researchers", and do not attach a reproducer.

Duplicates are therefore not a technicality. OpenAI deduplicated candidates against each other and ran variant analysis, but publishes no figure for overlap with bugs already fixed or already assigned CVEs. That is the number a sceptical reader wants, and the one the post withholds.

Capacity is the other half of the story. Greg Kroah-Hartman told The Register in March that AI reports had gone from junk to real, and described his own experiment: sixty findings and fixes from one lazy prompt, about a third wrong, two thirds of the patches usable after cleanup. That implies a batch of 948 unreviewed diffs contains a few hundred needing rewrite. Linus Torvalds wrote in May that the private security list had become "almost entirely unmanageable" because researchers with the same tools were reporting the same bugs separately. Into that queue OpenAI has pushed hundreds of reports and patches.

The bill is real; the comparison is marketing

The $1,279 per vulnerability is arithmetically correct: $1,213,430 divided by 948 is $1,280, and OpenAI rounds down. It is an all-in number, and the split inside it is more interesting. Successful exploits cost an average of $360 in credits to develop, which across 1,169 is about $420,840, roughly a third of the run; the rest went to discovery, validation and the surrounding stages.

The figure excludes the expensive part: human review by OpenAI researchers and Trail of Bits engineers, coordinated disclosure, and every maintainer hour spent reading a report. OpenAI calls it an upper bound on model cost and expects better harnesses to lower it, which is fair, but credits were never the scarce input.

The bounty comparison needs the same care. Multiplying 948 by Pwn2Own's $20,000 and TyphoonPWN's $70,000 yields $18.9 million to $66.3 million, which OpenAI presents as 16x to 55x its cost. Those programmes pay for individual demonstrated exploits against targets they choose; they do not buy 948 of anything from one seller. The company's kernelCTF result is the better yardstick: 21 LPE exploits in 112 hours for $32,936, against 26 confirmed zero-day LPEs accepted there in all of 2026, and even that is framed as "if the 21 vulnerabilities were accepted".

What the run does prove

Two admissions are worth more than the headline. In an early run, 200 exploits were reported successful and 20 had reached root through a different zero-day than the one assigned, which is why the pipeline now checks that each exploit uses its intended bug. And in the kernelCTF environment the agents found and exploited a flaw in QEMU's TCG, in the test harness rather than the target, without QEMU's source. Both point the same way: a count of successes is only as good as the check behind it, and the check arrived after the counting started.

None of that makes 948 wrong. It makes 948 unverified by anyone outside OpenAI, in a field where external verification means a maintainer merging a patch or a bounty programme accepting an exploit. Neither has been shown at scale.

The operational advice is unglamorous and unchanged: update kernels and reboot into them, because a patched package that is not running is not patched; restrict unprivileged user namespaces where workloads allow; treat a low-privilege shell on an unpatched host as root, which is OpenAI's own conclusion. If a working local exploit now costs four figures, the window between disclosure and exploitation is measured in days.

The claim to watch is not the next bigger number. It is the first public commit message carrying a maintainer's Reviewed-by tag with an OpenAI-reported bug behind it. Until that exists, "948 patched" is a pipeline output, and the kernel's changelog has not been introduced to it.