What did OpenAI's pipeline find in the Linux kernel?
OpenAI published a security research post on November 4, 2026. It describes a prototype that finds, validates and patches software vulnerabilities without a human driving each step. In one run in mid-October, the company says the system identified 2,308 candidate Linux kernel findings. It reproduced 1,724 of them in isolated virtual machines and turned part of that set into working exploits.
The headline number is 948. OpenAI describes these as distinct local privilege-escalation vulnerabilities. It produced working exploits that could give an ordinary local user root access, plus candidate patches for maintainers to review. The company also produced 291 proofs of concept for information leaks.
The kernel matters because it sits under Android devices, cloud infrastructure and supercomputers, as OpenAI notes. A local privilege-escalation flaw is most dangerous on shared machines, where many users or tenants already have a login. It also matters on servers that run untrusted code inside containers.
OpenAI says the scan covered the latest Linux kernel master branch at the time and a commonly used Linux distribution. The test machines ran a stock desktop operating system, not a deliberately weakened target. Standard protections stayed on, including SMEP, SMAP, KASLR and HARDENED_USERCOPY. The company compares the setup with the threat model used in Pwn2Own-style contests.
This is research, not a shipped product. OpenAI describes the model at the center of the pipeline only as an upcoming cyber model. It has not named or released it. Human security researchers reviewed the exploits, patches and severity ratings before anything went to kernel maintainers.
- •2,308 candidate findings after deduplication
- •1,724 vulnerabilities dynamically reproduced, or about 74.7%
- •291 information-leak proofs of concept
- •1,169 working local privilege-escalation exploits
- •948 distinct LPE vulnerabilities after variant analysis
How does the five-stage pipeline work?
The pipeline splits the work across specialized agents. Scout agents decide which parts of the kernel are worth auditing, based on whether a low-privileged user can reach the code. They selected 5,034 audit targets covering about 2.8 million lines, or roughly 7% of the kernel's more than 40 million lines. OpenAI says that step cost $3,426 in API credits.
Analyst agents then read the selected code and produced 2,308 candidate findings within 12 hours. That stage cost $316,549. The company says the agents followed a workflow similar to its Codex Security plugin. Candidates that advanced had to show measurable evidence of memory corruption.
Validation is the part that separates a plausible report from a real bug. Triage agents wrote proofs of concept and ran them against a kernel built with the Kernel Address Sanitizer. They watched both program output and the system console. Each test was refined until it reproduced the behavior or ran out of options. Within 30 hours, the system reproduced 1,724 findings, or 74.7% of the candidates. That stage cost $73,330.
OpenAI says incorrect analysis accounted for just 3.1%. In those cases, the reported vulnerability assumed an impossible condition. Most of the other failures required elevated privileges or hit difficult race conditions, specific trigger conditions or slow validation. A screening agent then narrowed the reproduced set to 313 information-leak candidates and 1,238 local privilege-escalation candidates for $44,194.
Exploit-development agents took over from there. They produced 291 information-leak proofs of concept and 1,169 working LPE exploits for $775,929. OpenAI says a successful exploit cost $359 on average. The 69 failed attempts averaged $3,922 each. Patch generation followed. Each bundle held a root-cause analysis, a minimal crashing proof of concept, a candidate patch and a full exploit.
The prototype also found a vulnerability outside the kernel. In the kernelCTF test, an analyst agent hit an unexpected crash while experimenting with privilege transitions. It traced the problem to QEMU's Tiny Code Generator without access to QEMU's source. OpenAI says the flaw had been fixed upstream but not in the release build used for the test.
Why does $1,279 per root exploit matter?
The total run cost $1,213,430 in API credits, which works out to $1,279 for each of the 948 unique vulnerabilities. OpenAI compares that figure with historical bounty prices for Linux kernel LPE exploits. Historically, Pwn2Own offered $20,000 and TyphoonPWN offered $70,000, according to the post. Applied to all 948 flaws, those rates imply a value of $18.9 million to $66.3 million. That is 16 to 55 times the pipeline's cost.
That comparison is illustrative, not income. Bug bounty programs pay only for accepted, novel findings that meet their rules. Duplicates, low-impact bugs and reports without a working exploit often earn nothing. OpenAI itself calls the range a hypothetical valuation.
A second test used Google's kernelCTF environment, which runs a hardened kernel with a reduced attack surface. OpenAI says the pipeline found 25 information-leak proofs of concept and 21 LPE exploits there. The campaign lasted 112 hours and cost about $32,936 in API credits. If all 21 were accepted, the bounty would be around $1.5 million, or roughly 45 times the scanning cost.
Scale matters more than the exact multiplier. OpenAI says 26 confirmed zero-day LPE exploits were accepted by kernelCTF in all of 2026 at the time of writing. A single automated campaign producing 21 working LPE exploits shows how quickly the supply of exploit primitives could grow. It also shows why patch review, not discovery, is becoming the constraint.
The cost curve is moving fast. In late July 2026, GPT-5.6 Sol found and exploited 166 unique LPE vulnerabilities for $513,690. The October run found more than five times as many, even after three months of kernel hardening. OpenAI says the newer model discovered vulnerabilities that the older one missed in code it had already audited.
Are the AI-written patches ready for kernel maintainers?
OpenAI says it followed guidance from the Linux kernel community and started with the most critical findings. It has sent hundreds of reports and patches. It is working with partners in its Patch the Planet program on the rest. The company says human researchers review each exploit and patch before sending it upstream.
The kernel community was already moving. During the 10-day scan and analysis period, 61 LPEs were patched upstream. Another 43 had staging patches, and 299 were being reported and discussed in public. That pace is a good sign for users, but it complicates automated triage. A finding can become obsolete while an agent is still working on it.
Patch quality needed work. OpenAI says early patches were often functionally correct. But they added unnecessary code, risked performance tradeoffs, ignored nearby coding conventions or missed variants of the same flaw. Extra instructions and repeated passes improved the results. In a few cases, the prototype flagged problems in patches written by human experts before those patches were merged.
Independent experience is mixed but not dismissive. Greg Kroah-Hartman, a longtime kernel maintainer, ran his own rough experiment and got 60 problem reports with fixes. He told The Register that about one-third were wrong but still pointed to a relatively real problem. Two-thirds of the patches were right. The working patches still needed human cleanup, better changelogs and integration work.
The kernel community has also set limits. Kroah-Hartman barred LLM-generated patches from the staging subsystem except for legitimate security fixes, according to Tom's Hardware. Kernel guidance warns that AI-generated reports submitted without human verification can waste maintainer time. A candidate patch is therefore a starting point for review, not evidence that a fix is ready.
What do Linux maintainers say about the AI bug-report flood?
Maintainers were already struggling before OpenAI published its results. Tom's Hardware reported in September 2026 that the kernel was approaching 2,000 CVEs fixed per release. That is up from roughly 500 through much of the Linux 6.x era. CVE counts rose above 1,000 with Linux 7.0 and above 1,500 with Linux 7.2. The article said Linux 7.3 could push the figure past 2,000.
The work is not evenly spread. In the Linux 7.3 networking pull request, maintainer Jakub Kicinski estimated a range. Between one-third and one-half of the 648 net-next patches were low-priority fixes, cleanups or clarifications driven by AI. He wrote that the team was "completely overwhelmed." Developer Andrew Lunn proposed removing nearly 28,000 lines of legacy networking code. Automated tools kept finding defects in hardware almost nobody used.
Kroah-Hartman has described a rapid shift in quality. Months earlier, he said, maintainers were getting what they called AI slop. Then, around February 2026, the reports changed. He told The Register that the world switched and that real reports were arriving. His assessment was blunt: "Our increase is real – and it's not slowing down."
He also said the kernel can absorb the load because it has a large, distributed team. Smaller open-source projects cannot. That warning is supported by the curl project's experience. Curl stopped accepting HackerOne submissions and eliminated monetary rewards to reduce low-quality reports. It later returned to HackerOne while keeping bounties off. Lead developer Daniel Stenberg warned that "this avalanche is going to make maintainer overload even worse."
The wider data points the same way. Reuters reported in October 2026 on VulnCheck research that said AI helped drive a doubling of software flaws discovered year on year. Cloudflare chief executive Matthew Prince told Reuters that every week for a couple of years could feel like the sky is falling. Not everyone expects more attacks, though. Stenberg argued that AI-found bugs tend to be exotic and hard for criminals to exploit.
What are the limits of the 948 claim?
The result is self-reported. OpenAI has not published an independent audit of the 948 figure. Outside researchers cannot reproduce the run because the model is unreleased and unnamed. The company did describe its method and cost breakdown in unusual detail, which lets readers check the internal logic. It does not prove that every count would survive a third-party review.
The scope is also narrow. The scan used one kernel snapshot and one commonly used distribution. A vulnerability that reproduces on that configuration may not affect every Linux system, and some may require specific settings. OpenAI says incorrect analyses accounted for 3.1%. Many other candidates could not be reproduced within the time budget. So the 948 is a floor on what the pipeline could confirm, not a census of all kernel bugs.
The number is also easy to misread. OpenAI produced 1,169 working LPE exploits, then used variant analysis to group them into 948 distinct vulnerabilities. The 948 is a count of unique flaws, not 948 separate reports or 948 merged kernel fixes. Some could overlap with bugs found by other researchers. The kernel changes constantly, so duplicate and obsolete reports are a real risk.
The cost figure covers API credits only. It excludes salaries, hardware, electricity and the human review that OpenAI says every finding received. OpenAI describes the reported costs as more of an upper bound because better harness engineering could reduce them. Either way, $1.2 million is not the full price of running this pipeline in production.
The valuation comparison has similar limits. Bounty prices are not a market price for every bug, and programs reject duplicates and low-impact findings. OpenAI's post also does not say whether any of the 948 flaws were exploited in the wild. The company withheld technical details of the 10 new exploitation techniques for safety. That limits outside verification of that part of the claim.
What should Linux users and defenders do now?
Patch. OpenAI's own warning is blunt. A low-privileged account on an unpatched system should be treated as "functionally equivalent to root access" for a well-resourced attacker. That raises the value of routine updates, especially on servers that run untrusted workloads or give many people local accounts.
Assume local access is valuable. The flaws in this set are privilege-escalation bugs, not remote code execution. An attacker still needs a foothold, such as a compromised service account or a malicious local user. Sandboxes and isolation layers such as Firecracker and gVisor can limit what happens after that foothold. OpenAI recommends defense in depth for exactly this reason.
Do not treat one audit as final. OpenAI found more than five times as many LPEs with a newer model than it did three months earlier. The company expects future models to find bugs that today's models miss. It argues that large projects should rescan after each meaningful model upgrade and revalidate old findings against current code.
Watch the patch pipeline, not just the discovery numbers. The useful signal is how many of the 948 fixes survive maintainer review. It also matters how quickly distributions ship them and whether the reports create more work than they save. Watch, too, whether OpenAI releases the cyber model, and whether other labs publish comparable audits with enough detail for outside checks.