On November 4, OpenAI published a research post titled A thousand fewer paths to root, describing how an automated pipeline scanned the Linux kernel. The 948 in the headline grabs attention, but the post's own judgment is the part worth keeping: vulnerability discovery is becoming easier to scale, while prioritization and validation remain operational bottlenecks. Follow that thread and you can watch the pressure move, step by step, from finding bugs to proving they are real and getting the fixes merged.
A few terms first. Local privilege escalation, or LPE, means a regular user who can already run programs on a machine uses a bug to become root, the system's administrator account. A proof of concept, or PoC, is a small program that triggers a bug to show it exists. Upstream refers to the official mainline Linux kernel tree; once a fix lands there, distributions pick it up over time.
Finding bugs can now be done in bulk: 2,308 candidate findings in 12 hours
According to OpenAI, the pipeline has five stages: discovery, dynamic validation, exploitability assessment, patch generation, and finally review by human security researchers. It runs on an upcoming cyber model that has not been released, and the scan ran in mid-October 2026 against the kernel's master branch at the time.
Discovery itself has two steps. Scout agents read through the code and picked parts that are reachable by low-privileged users and relevant to security, yielding 5,034 audit targets and about 2.8 million lines of code, roughly 7% of a kernel that has more than 40 million lines. That step cost $3,426. Analyst agents then reviewed each target and, within 12 hours, produced 2,308 candidate findings after deduplication, at a cost of $316,549.
The scaling trend is clear from two runs. In late July, GPT-5.6 Sol ran the same process and found and exploited 166 unique LPE bugs for $513,690. In mid-October the newer model reached 948 for $1,213,430. Going back further, when OpenAI reported GPT-5.5 Cyber's work in June, it had built 24 LPE exploits to validate and report its findings.
The money and time go into validation and exploitation: those stages took more than 70% of the API spend
A candidate is not a vulnerability. OpenAI had triage agents write a PoC for each candidate and run it repeatedly in an isolated virtual machine with KASAN, the Kernel Address Sanitizer, a debugging feature that catches errors such as out-of-bounds access and use-after-free. Within 30 hours, 1,724 findings were reproduced, about 74.7% of the candidates. Most of the rest needed elevated privileges or got stuck on hard-to-trigger race conditions; only 3.1% were cases where the model's analysis was wrong.
Next came severity. A screening agent narrowed the set to 313 information leak candidates and 1,238 LPE candidates. Exploit-development agents then worked in virtual machines with standard distribution protections switched on, including SMEP, SMAP and KASLR, which stop the kernel from executing or touching user memory and randomize kernel addresses. They produced 291 information leak PoCs and 1,169 working LPE exploits that reached root. OpenAI then ran variant analysis, grouped the underlying bugs into 948 distinct patches, and uses that figure as the count of unique LPE bugs.
| Stage | Output | API cost |
|---|---|---|
| Scouting (pick audit targets) | 5,034 targets, about 2.8 million lines | $3,426 |
| Analysis (find candidates) | 2,308 candidates in 12 hours | $316,549 |
| Dynamic validation | 1,724 reproduced in 30 hours | $73,330 |
| Screening | 313 leak candidates, 1,238 LPE candidates | $44,194 |
| Exploit development | 291 leak PoCs, 1,169 LPE exploits | $775,929 |
The last three rows add up to $893,453, about 73.6% of the $1,213,430 total, with exploit development alone at 63.9%. The two discovery steps total $319,975, about 26.4%. Those shares are my own arithmetic from the post's figures, and the post does not break out a separate cost for patch generation. OpenAI also notes that validating a true positive costs about the same as validating a false positive, so removing false positives early saves real money.
The post also shows why human review cannot be skipped. In an early run, the exploitation stage reported 200 successful LPE exploits, but human review found that 20 of them had reached root through a different 0-day than the one assigned. OpenAI then added an independent check that each exploit used its assigned bug. The more automated the pipeline gets, the less you can skip the work of proving why a result holds.
"A low-privileged account is as good as root" comes with clear conditions: an unpatched kernel and an attacker who can already log in
The OpenAI post contains a line that is easy to turn into a headline: for the near and medium term, a low-privileged account on an operating system that isn't up to date on its available patches should be considered functionally equivalent to root for a well-resourced threat actor. If you repeat it, keep all of its conditions.
To begin with, these are local privilege escalation bugs. The attacker must already be able to run programs on the machine as a regular user, for instance by holding an account or by getting in through some other flaw; these bugs do not by themselves provide a remote way in. Next, the system has to be missing fixes that already exist, so a kernel that has been patched is not covered. Finally, the subject is a well-resourced attacker. The post puts the average cost of a successful exploit at $359, but that assumes access to a model and toolchain of similar capability.
The test environment has limits too. OpenAI says the target virtual machines ran a stock desktop system from a commonly used distribution, not a deliberately weakened one. On Google's kernelCTF, which has a smaller attack surface, the results narrowed sharply: 112 hours and about $32,936 produced 21 LPE exploits and 25 information leak PoCs, and OpenAI dropped kernelCTF's SLAB_VIRTUAL mitigation for compatibility with the newer kernel. For reference, OpenAI says kernelCTF had accepted 26 confirmed 0-day LPE exploits in 2026 at the time of writing. The $18.9 million to $66.3 million valuation based on historical Pwn2Own and TyphoonPWN bounties is, in the post's own words, hypothetical, not money anyone paid.
Maintainers and other researchers are already patching fast: 61 LPE bugs fixed upstream within 10 days, by other contributors
The scan and manual analysis took 10 days. OpenAI says that by the end, 61 of the LPE bugs had been patched upstream, 43 had staging patches and 299 were being reported and discussed publicly. OpenAI says plainly that these more than 100 bugs patched or with staging patches came from other contributors, so others were finding and fixing the same problems in parallel. That fits the kernel docs' observation that AI-found bugs tend to surface at multiple researchers on the same day. OpenAI also says that, following the kernel community's advice, it has sent hundreds of reports and patches for critical bugs and is sending the rest in batches with Patch the Planet partners. It gives no figures for how many have gone out or been accepted.
The kernel's official rules speak to this situation directly. The security bugs page on docs.kernel.org has a section on responsible use of AI to find bugs. It opens by saying a significant fraction of reports to the security team come from AI-assisted code review, which overloads maintainers, who sometimes have to ignore reports because of poor quality. It asks for short plain-text reports that state only verifiable impact, requires a tested reproducer, and asks reporters to have their tool propose and test a fix, carrying a Fixes tag that names the commit that introduced the bug.
The rule that bears directly on disclosure pace is this one: if you used AI to find a bug, you must treat it as public, because the security team's experience is that such bugs surface at multiple researchers at once, often on the same day. Reproducers should not be posted publicly; maintainers will ask for them privately if needed. The page also says that fixes for undisclosed bugs may be held back at the request of the reporter or an affected party for up to 7 calendar days from the start of the release process, with an exceptional extension to at most 14 calendar days if it is agreed that the bug is critical enough to need more time. The only valid reason for a delay is the logistics of QA and large-scale rollouts that need coordinated releases. Fixes for publicly known bugs are released immediately.
So what maintainers face is not bugs that are hard to find but a wave of reports, often overlapping, each needing confirmation and a patch review. OpenAI's own advice points the same way: automated triage should account for the fast patching cycle and recheck findings against current code to avoid duplicate or obsolete reports. I could not find any official statement from the kernel security team or security@kernel.org about this particular batch of OpenAI reports, or about how large the queue has grown, so that remains unknown.
For you, safety comes down to update speed: patch first, then isolate
Put together, the picture is clear. The marginal cost of finding bugs is falling fast, and OpenAI's two runs show that a stronger model finds more problems in the same code. What limits how quickly security actually improves is whether results can be trusted, whether patches are correct, and whether maintainers can absorb them. OpenAI admits that patches written directly by the model sometimes added more code than needed, drifted from coding style, or missed variants of the same bug, and needed human-guided iteration.
If you run Linux servers or multi-user systems, the steps are concrete. Shorten your kernel update cycle, because dozens of fixes reached upstream within 10 days and ordinary accounts on old kernels are getting riskier. Cut unnecessary local accounts and other ways to run code on the machine, since every one of these bugs needs local execution first. Where you run untrusted code, add a sandbox or isolation layer such as Firecracker or gVisor, as OpenAI recommends, to limit the damage when something is broken. Bug-finding tools will keep multiplying; what you control is how quickly the patches reach your own machines.