OpenAI said on November 4 that an autonomous pipeline running an unreleased cyber model found and exploited 948 distinct Linux kernel bugs that let an ordinary local user become root, and wrote a candidate patch for each, for $1,213,430 in API credits. By OpenAI's own count in its writeup, "A thousand fewer paths to root", 61 of those bugs had already been patched upstream by other contributors when the 10-day scan and analysis ended, and another 43 had patches in staging. OpenAI has not published a list of the 948, their CVE numbers or the commits that fix them, so nobody outside the company can yet say how many of the fixes have reached a kernel anyone runs.
Our take: the 948 is a measure of how cheap finding kernel bugs has become, and it says almost nothing yet about how many machines are safer. The number that matters is fixes shipped, and on that number the evidence points to the kernel's reviewers, already publishing CVEs at a record pace, as the limit. More than 20 outlets repeated OpenAI's figures, many with its own bounty comparison; none of those we read set them against the kernel's review queue. That is what this piece does, using OpenAI's stage-by-stage numbers and a SaasBuzz count of every CVE the kernel published in the National Vulnerability Database (NVD) since 2024.
So, are the bugs fixed, and is your Linux system exposed until they are? Some are fixed, most cannot yet be checked from outside, and OpenAI's own advice is blunt: a low-privileged account on a system that "isn't up-to-date on its latest available patches should be considered functionally equivalent to root access for a well-resourced threat actor." The practical answer for anyone running Linux servers or containers is to take kernel updates as they ship and to treat every local account and every container as a possible path to root.
What the 948 counts, and what it leaves out
The pipeline ran in mid-October 2026 against the latest kernel master branch, on a stock desktop distribution with the usual hardening switched on. Scout agents picked 5,034 audit targets, about 2.8 million lines or roughly 7% of the kernel. Analyst agents produced 2,308 candidate findings in 12 hours; triage agents reproduced 1,724 of them in 30 hours; exploit agents then built 1,169 working root exploits, which variant analysis collapsed to 948 distinct bugs with 948 patches. Human researchers reviewed the output before anything went to maintainers.
Stage | Count | API cost |
|---|---|---|
Targets picked | 5,034 | $3,426 |
Candidates | 2,308 | $316,549 |
Reproduced | 1,724 | $73,330 |
Screened | 1,238 root, 313 leak | $44,194 |
Exploited | 948 distinct | $775,929 |
Source: OpenAI, November 4, 2026. The five stage costs add up to $1,213,428, two dollars short of the total OpenAI gives. SaasBuzz analysis in calc/calc.mjs.
Two things the headline number leaves out. First, a patch here is a candidate: OpenAI says its early patches sometimes added more code than needed, hurt performance, broke local conventions or missed variants of the same bug, and that more instructions and iteration improved them. Second, the stage that sends a patch upstream, maintainer review, carries no cost line at all, because it is not OpenAI's to spend.
How many of the 948 are fixed today?
Only OpenAI's snapshot answers that, and it is a snapshot of other people's work. OpenAI wrote that while its scan was running it saw more than 100 Linux root bugs "patched or had staging patches from other contributors", with about 300 more under public discussion. OpenAI does not say which total those counts are drawn from; set against the 948, its count of unique bugs, they split as follows.
Status at run's end | Bugs | Share |
|---|---|---|
Patched upstream | 61 | 6.4% |
Patch in staging | 43 | 4.5% |
Reported, discussed | 299 | 31.5% |
None of these | 545 | 57.5% |
Source: OpenAI, November 4, 2026; shares are SaasBuzz's, of 948.
Read plainly, 403 of OpenAI's 948 bugs, 42.5%, were already patched, staged or under public discussion within 10 days of the scan, and 104 of them, 11%, had been patched or had patches in staging from other contributors. That is the duplication Linus Torvalds complained about in May, when he wrote in his 7.1-rc4 announcement that "the continued flood of AI reports has basically made the security list almost entirely unmanageable", with "enormous duplication due to different people finding the same things with the same tools", as GamingOnLinux reproduced it. Since the run, OpenAI says it has "already sent out hundreds of reports and patches for critical vulnerabilities", following the kernel community's advice to start with the worst, and is working with its Patch the Planet partners to send the rest gradually. "Hundreds" and "gradually" are the most precise figures on offer.
Can kernel maintainers absorb 948 more patches?
They are already absorbing a record load. SaasBuzz counted every CVE in NVD whose source is the kernel's own numbering authority, by publication date, through the NVD API.
Year | Kernel CVEs | Per day |
|---|---|---|
2024 | 4,287 | 11.7 |
2025 | 5,675 | 15.5 |
2026 to Nov. 4 | 8,242 | 26.8 |
Source: SaasBuzz analysis of the NVD API, CVEs whose source is the kernel.org numbering authority, counted November 5, 2026, excluding rejected records. Code in calc/kernel-cves.mjs.
The 2026 total is already 45% above all of 2025, and the pace since May is steeper still: 3,887 CVEs between April 30 and August 27, 2,243 between August 28 and September 30, and 1,051 in October. At 2026's pace, 948 distinct root bugs equal about 35 days of everything the kernel publishes, from crashes to leaks, and the 948 are the severe end of that range. Each kernel CVE record opens with the words "In the Linux kernel, the following vulnerability has been resolved": the kernel assigns its CVEs to fixes, so the count is a proxy for fixes reviewed and merged, and the proxy's daily rate has risen by about 70% in a year.
The people doing that work have said what it costs them. Linux kernel maintainer Greg Kroah-Hartman told The Register in March that AI-made bug reports had become genuine ("Now we have real reports"), and that the result is "more reviews; it's more stuff we have to review for the kernel." In one experiment with AI-written patches he described, "About one-third were wrong." OpenAI's own writeup makes the same point from the other side: "prioritization and validation remain operational bottlenecks."
What the industry is saying
OpenAI announced the run on X with the headline number and the $1.2 million cost, linking the writeup.
Post on X by @OpenAI
Our security researchers built an autonomous cyber vulnerability discovery, exploitation, and patching pipeline. In a single run with an upcoming cyber model, it validated and generated patches for 948 local privilege escalation vulnerabilities in the Linux kernel at a total API cost of $1.2 million.
Greg Brockman, OpenAI's president and co-founder, rounded the cost to about $1,000 a bug and framed the pipeline as a way to harden proprietary software as well as open source.
Post on X by @gdb
we've found, validated, and prepared patches for almost 1,000 linux local privilege escalations using our cyber vulnerability pipeline, at the cost about $1,000 per vulnerability. an emerging scalable approach to significantly hardening both open source and proprietary projects
Guillermo Rauch, chief executive of Vercel, which launched AI security reviews on November 3, took the most optimistic reading: that AI will rewrite most human-made software and make it secure.
Post on X by @rauchg
We will all be learning in coming weeks & months, that most human-made software: ▫️ Was really slow ▫️ Had many security vulnerabilities ▫️ Was under-specified and incorrect AI will rewrite it all. Many times. It will make it fast, cost-efficient, and secure. It will think about failure modes we couldn't wrap our heads around. It will prove, formally verify, load test, harden. It will turn memory-unsafe foundations into robust, optimized ones. If you ask, it'll thoroughly document it, teach you about it, make diagrams, animations, and slide decks. In many ways, we are witnessing the true birth of software engineering.
Charles Guillemet, who lists himself on X as chief technology officer at Ledger, made the case closest to ours, under the heading "Finding bugs is not fixing bugs", and added that a $1.2 million run is affordable for a frontier lab or a state attacker but not for most maintainers.
Post on X by @P3b7_
🤖OpenAI just published research showing models found and developed exploits for 948 local privilege escalation (LPE) vulnerabilities in the Linux kernel, spending $1.2M in API credits. To put this into perspective: the Linux kernel powers almost all cloud infrastructure, Android devices, supercomputers, and modern networking. Linux enforces process isolation. An unprivileged application, like a calculator or a basic utility, is not supposed to read memory, inspect processes, or touch cryptographic keys held by another process or software wallet. A local privilege escalation simply breaks that security boundary. It allows an unprivileged process to escape its world and gain root control over the entire system (like full access to everything). OpenAI demonstrated that an automated pipeline can discover nearly a thousand ways to do this in a single campaign. While the research is impressive, it exposes three uncomfortable realities: 1️⃣ Finding bugs is not fixing bugs LLMs are remarkably good at static analysis, reproduction, and exploit generation. Generating sound patches for complex kernel code is an entirely different challenge. Kernel fixes often introduce performance regressions, subtle race conditions, or fail to address the root architectural variant. 2️⃣ The attack surface remains massive These 948 exploits targeted only local privilege escalation, and only audited a fraction of the kernel code. They do not account for remote code execution, network stack vulnerabilities, firmware flaws, or supply chain compromises. Finding 1,000 paths to root does not mean the system is secure; it simply means we mapped 1,000 holes in a 40-million-line dam. The density of vulnerabilities in software is extremely higher than anyone thought before 🫠 3️⃣ The defensive economics do not scale A $1.2M audit run is pocket change for a frontier AI lab or a patient nation-state adversary. But virtually no open-source maintainer, startup, or enterprise can spend millions of dollars per release cycle on tokens just to partially reduce latent vulnerabilities. If defense costs millions of dollars per scan while sophisticated attackers only need to find one unpatched path, the asymmetry favors the attacker. The real lesson here is that software isolation alone will always fail under automated adversarial pressure. The only durable answer is architectural: minimizing attack surfaces, proving security invariant, enforcing strict hardware roots of trust where secrets live, and building toward cryptographic guarantees that make critical compromises structurally impossible rather than merely expensive.
Found versus fixed: this year's AI bug hauls side by side
Put the 2026 hauls in one table and the gap between finding and fixing is the pattern, not the exception. Where a source gives no fixed count, the cell says "None given".
Run | Found | Fixed, as reported |
|---|---|---|
OpenAI, June | 24 kernel root exploits | None given |
OpenAI, July | 166 root bugs, $513,690 | None given |
OpenAI, October | 948 root bugs, $1.21M | 61 upstream at run's end |
Trail of Bits, June | "Hundreds", 19 projects | "Dozens" of patches merged |
Vercel, in 24 hours | 6,817 in 24 hours | 1,411 patched by agent |
Sources: OpenAI, November 4 (June, July and October runs); OpenAI, Patch the Planet, June 22 (Trail of Bits with GPT-5.5-Cyber); Vercel figures from Guillermo Rauch on X, November 4, not independently confirmed.
Rauch posted Vercel's numbers the same night as OpenAI's announcement. They come from Vercel Security Review, launched in public beta on November 3 to review customers' code on every push, rather than from an open-source project, and the agent's fix rate, about one in five findings within a day, is the only fixed-versus-found ratio any of these announcements volunteers.
Post on X by @rauchg
In just 24 hours 🤯 ✓ 𝟲,𝟴𝟭𝟳 vulnerabilities identified ✓ 𝟱𝟴𝟬 critical or high ✓ 𝟭,𝟰𝟭𝟭 already patched by Agent Vercel Security Reviews are 100% free until Nov 10
The October run found 5.7 times as many root bugs as July's and cut the cost per bug by 59%, from $3,095 to $1,280, even though three months of fixes had gone into the kernel in between. OpenAI's conclusion is that every new model generation should rescan the same code. If that holds, the review queue does not drain; it refills with each model release.
What does $1,000 a bug really cost?
Brockman's $1,000 is a rounding of $1,280 per distinct bug, and it counts tokens only. Inside it, finding the bugs was cheap: scouting and analysis took 26.4% of the bill. Exploitation took 63.9%. OpenAI reports that its 69 failed exploit attempts averaged $3,922 each against $360 for the 1,169 that worked, which by our arithmetic means the failures consumed about $270,600, or 39% of the $691,000 spent on root-exploit attempts, on candidates that produced no exploit. OpenAI says a rule to give up after an hour without progress would have cut that sharply, and calls its costs "more an upper bound."
What the price leaves out is the human side: OpenAI's researchers' review of every exploit and patch, Trail of Bits' and the other partners' disclosure work, and the maintainers' review and backporting into stable kernels. None of that is priced in the writeup. OpenAI's bounty comparison, $18.9 million to $66.3 million at historical Pwn2Own and TyphoonPWN rates, prices what an attacker could have been paid for the exploits, not what it costs to ship the fixes.
What stops an attacker doing the same before the patches ship?
For now, access. The model is unreleased, and the labs are gating their strongest cyber models: Google gave Gemini 4 Carbon to defenders first, as we covered on November 1, and OpenAI describes this work as part of its Daybreak initiative. But OpenAI's own writeup expects that "even less capable models may be able to develop exploits once disclosed" within a few years, and its exploit agents cost $360 a success. Once a fix is public, the patch itself shows where the bug was. The window that matters is between a public fix and the update on your machines, which is why OpenAI points to sandboxing such as Firecracker and gVisor to limit what a root exploit can reach.
Our take: count fixes, not finds
The finding, put so it can be checked: the cost of finding and proving a Linux kernel root bug has fallen to about $1,280 in API credits, and the binding constraint on safety is now review and release, where the kernel was already publishing 26.8 CVEs a day before OpenAI's 948 arrived. Labs should be judged by fixes merged and shipped in stable kernels, with the list published once it is safe, not by bugs found.
The strongest objection is that OpenAI already did much of the review work for maintainers. Each report comes with a root-cause analysis, a minimal reproducer, a working exploit and a candidate patch, checked by a human researcher; OpenAI says its pipeline even caught flaws in human-written patches before they merged; and it followed the kernel community's request to send critical bugs first rather than all 948 at once. A report that arrives with a tested fix costs a maintainer less than a bare crash log. That is fair, and it is why OpenAI's approach is better than the drive-by reports Torvalds complained of. It does not change the count. Kroah-Hartman's own experiment found a third of AI patches wrong, OpenAI says its patches needed iteration to be correct, and every merged fix still needs a maintainer to read it. Better-packaged work still has to be reviewed, at the same rate per maintainer.
What would change our view
A published list of the 948 with CVE numbers and fixing commits, once OpenAI and the maintainers judge it safe, would let anyone count fixes shipped, and a high count would answer the doubt. So would evidence that AI-assisted review, which OpenAI recommends for both human and AI patches, raises how many fixes each maintainer can take. Watch the kernel's monthly CVE count: a sustained jump above October's 1,051 would be the 948 arriving.
Method: the pipeline figures are OpenAI's and have not been independently reproduced. Kernel CVE counts are NVD records whose source identifier is the kernel.org numbering authority, counted by NVD publication date and excluding rejected records, so they include CVEs assigned to older fixes and are a measure of the kernel's output, not of new bugs. Calculations are in the draft's calc folder.
