OpenAI's Model Built 948 Linux Root Exploits in One Run. Ten Days Later, 61 Were Patched Upstream

For most of the history of Linux security, the scarce thing was the exploit. Finding a kernel bug was hard, proving it could hand an ordinary user root was harder, and a working privilege escalation was valuable enough to win a hacking contest. Research OpenAI published on November 4 suggests that scarcity is over. One automated run produced 948 of them. The number IT teams should watch is not 948, though. It is the distance between 948 and the 61 fixes that had landed upstream ten days after the scan began.

From 2,308 Leads to 948 Working Exploits

According to Help Net Security, OpenAI's Cyber team pointed the pipeline at the latest Linux kernel in mid-October, with targets running a stock desktop operating system from a widely used distribution. Unite.AI reports that the test machines had the usual hardening switched on, including SMEP, SMAP, KASLR and HARDENED_USERCOPY. In a kernel of more than 40 million lines, scout agents picked 5,034 audit targets covering about 2.8 million lines of code, roughly 7%.

The funnel from there was fast. Analyst agents produced 2,308 deduplicated candidate findings within 12 hours, triage agents reproduced 1,724 of them in virtual machines within 30 hours, and only 3.1% of findings rested on incorrect analysis by the model. The exploit stage then produced 1,169 working privilege escalation exploits and 291 information leak proofs of concept. Variant analysis collapsed those into 948 distinct patches, which OpenAI uses as its count of unique flaws.

The pipeline was not trusted blindly. In an early run, the exploit stage claimed 200 successful root exploits, and human review found that 20 of them reached root through a different zero-day than the one they had been assigned. OpenAI tightened the task rules and added an independent check that each exploit uses its intended bug, concluding that even successful exploitation by agents needs proper validation. In a sample of 166 exploits, OpenAI and outside kernel experts identified ten techniques they believed were new. The details are being withheld for safety reasons.

The Bottleneck Has Moved to the Maintainers

Every exploit, patch and proposed severity rating was reviewed by a human researcher before anything went to the kernel community. OpenAI says it has sent hundreds of reports and patches so far, starting with the most serious flaws at the community's suggestion, and is releasing the rest gradually through its Patch the Planet initiative with partners. Unite.AI is careful on the point that matters most: the 948 figure is a count of candidate patches for maintainers to review, not a count of merged fixes.

Kernel maintainers were already stretched before this landed. In May, Tech Newsday reported that Linus Torvalds had called the kernel's private security mailing list almost entirely unmanageable because of a surge in AI-generated bug reports. Researchers using the same AI tools were filing duplicate findings, and because the list is private none of them could see what others had already sent, so maintainers spent their time triaging duplicates and pointing out bugs fixed weeks or months earlier. Torvalds did not reject AI tools. He asked contributors to verify issues, check existing discussions and, ideally, send a fix.

Torvalds called the cycle of duplicate AI reports “pointless churn.”

Tech Newsday, reporting his weekly kernel update of May 2026

OpenAI's approach, reproduced findings with a patch attached, is close to what Torvalds asked for. The duplicate problem cuts the other way for defenders, though. If a well-funded lab can find these flaws with a frontier model, so can a well-funded attacker, and nothing guarantees the attacker reports what it finds. OpenAI's own researchers say that for now a limited-privilege account on an unpatched system should be considered functionally equivalent to root access for a well-resourced threat actor.

What $1,279 an Exploit Means for Defenders

The economics are the sharpest part of the research. At $1,279 per exploit, the October run cost a small fraction of what contests have historically paid for one Linux kernel escalation, and OpenAI puts the hypothetical value of the run at $18.9 million to $66.3 million. In a separate test against Google's hardened kernelCTF setup, the pipeline spent 112 hours and $32,936 in API credits to produce 21 privilege escalation exploits and 25 information leak proofs of concept. Google's kernelCTF rules list a reward of $71,337 per eligible exploit, so OpenAI describes the work as net profitable at the time of the research.

For IT leaders, the practical consequence is that local privilege escalation can no longer be treated as a second-order risk that only matters after something else has gone wrong. Any route to an unprivileged shell on a Linux host, whether a phished login, a compromised build runner, a vulnerable web service or a shared server, should now be assumed to end at root on any machine running an older kernel. OpenAI's recommendations are layered defenses, isolation tools such as Firecracker and gVisor, and keeping software up to date.

What Infrastructure and Security Teams Should Do Now

• Treat a local account as root on unpatched Linux. Re-rate risks that were discounted because an attacker would first need a low-privilege foothold, since that second step is now cheap to find.
• Shorten the kernel patch cycle. Fixes from this research will arrive in stable releases over the coming weeks, so plan for more frequent kernel updates and reboots than a quarterly cycle allows.
• Put untrusted code behind a stronger boundary. Containers share the host kernel, so CI jobs, customer workloads and anything multi-tenant belong in micro-VMs or sandboxes such as Firecracker or gVisor.
• Close the routes to a first shell. Phishing-resistant sign-in, locked-down build runners and fewer interactive accounts on servers all shrink the foothold an escalation exploit needs.
• Find the Linux you forget about. Appliances, embedded devices and vendor images often run old kernels and patch slowly, so inventory them and press suppliers on their update timelines.
• Hold AI-assisted research to the kernel's rules. If your own teams use AI to hunt bugs, require a reproduction and a tested patch before anything goes to a maintainer or a vendor.

OpenAI's run shows that discovering and exploiting kernel flaws can now be run as an industrial process. Fixing them still runs at the speed of human review, and the gap between the two is where attackers will look. Until the 948 candidate patches are merged and deployed, the safest plan is to assume every unpatched Linux host has a way to root that someone has already found.