OpenAI says its AI built 948 Linux root exploits in one run. The count is smaller than the headline number.
The pipeline produced 1,169 working exploits but counted 948 distinct flaws. OpenAI's own report also shows where the work stalls: with the people who have to patch.
OpenAI published a research report on November 4 saying an unreleased cyber model, wrapped in an automated pipeline, built working root exploits for 948 separate Linux kernel vulnerabilities in a single run. The bill was $1,213,430 in API credits. That’s about $1,279 per exploit, by OpenAI’s own division.
The headline number needs a footnote, and OpenAI supplies it. The pipeline actually produced 1,169 working exploits. Several of them traced back to the same underlying flaw, so after grouping them OpenAI counted 948 distinct vulnerabilities and wrote one patch for each, according to SecurityWeek’s reading of the report.
How 2,308 leads became 948 bugs
Here is the funnel as OpenAI describes it. Everything in the table is the company’s own account of a run it designed and graded itself.
| Stage | Result | Time or cost |
|---|---|---|
| Scout agents pick what to audit | 5,034 targets, about 7% of the kernel | $3,426 |
| Analyst agents scan those targets | 2,308 candidate bugs | 12 hours, $316,549 |
| Triage agents try to trigger each one | 1,724 reproduced (74.7%) | 30 hours |
| Screening for impact | 1,238 root-access candidates, 313 information leaks | n/a |
| Exploit agents | 1,169 root exploits, 291 leak proofs of concept | n/a |
| Grouped by underlying flaw | 948 distinct vulnerabilities, 948 patches | $1,213,430 total |
The target was the newest code on the kernel’s main development branch, run on virtual machines with a stock desktop Linux setup and the usual protections switched on (KASLR, SMEP and SMAP, per SecurityWeek). So this wasn’t a deliberately weakened machine. Only 3.1% of the candidates, by OpenAI’s count, were the model misreading the code.
The part where the agents were wrong
Help Net Security picked up a detail I liked more than the big number. In an early run the exploit stage reported 200 successes. Human review found that 20 of them had reached root through a different zero-day than the one the agent was assigned. OpenAI’s report says this shows successful exploitation by agents still needs checking, and the team added an independent check that each exploit really uses the bug it was meant to.
By that count it’s a 10% error rate in a step that sounds like it either works or doesn’t. A person reviews every exploit and patch before anything goes to the kernel maintainers, according to OpenAI. I’d keep that sentence in mind before reading “autonomous” in the headlines.
How much is actually fixed?
The report says that within 10 days, while the scan was still running, over 100 of the privilege escalation bugs had been patched or had staged patches from other contributors, and about 300 more were being discussed publicly. Help Net Security breaks the first group down as 61 patched upstream and 43 with staged patches. The remaining hundreds are, as far as OpenAI says, in the queue.
OpenAI says it started with the critical bugs, on advice from the Linux kernel community, and has sent hundreds of reports and patches so far. It’s releasing the rest in stages through its Patch the Planet partners. I couldn’t find a statement from kernel maintainers themselves about how the volume feels on their side, and that is the number I’d most like to see. Reproduced exploits and a ready patch are help. They’re also several hundred things for volunteers to read.
What OpenAI wants defenders to take from it
The report’s blunt advice: for the near and medium term, a low-privileged account on an operating system that isn’t fully patched should be treated as equivalent to root access against a well-resourced attacker. It suggests layered defenses such as Firecracker and gVisor sandboxes to limit the damage.
It also reports that the agents used at least 10 exploitation techniques that outside kernel experts hadn’t seen. It’s keeping the details private “for safety reasons”, so nobody can check that claim.
The cost framing is OpenAI’s too. It multiplies the 948 bugs by the $20,000 and $70,000 that Pwn2Own and TyphoonPWN have historically paid for Linux privilege escalations, gets $18.9 million to $66.3 million, and calls the run net profitable. My read: that’s a thought experiment. Nobody was going to pay out 948 bounties, and a market flooded with that many kernel bugs would pay a lot less per bug.
On a hardened test kernel (an adapted version of Google’s kernelCTF), the same pipeline produced 21 exploits over 112 hours for about $32,936, per OpenAI. kernelCTF has accepted 26 confirmed zero-day exploits in 2026 so far. My read: plentiful on the newest code, expensive on a hardened kernel, so I wouldn’t call that a clean win for either attackers or defenders.
My read
My read: the useful finding here isn’t 948. It’s that finding bugs stopped being the slow step. OpenAI says so itself, writing that discovery wasn’t the challenge, deciding which findings were real and which deserved attention first was. When one $1.2 million run can produce hundreds of reproducible bugs, the scarce resource becomes the maintainer’s afternoon.
I also can’t tell from the outside how much of this generalizes. The model is unreleased, the details are held back, and OpenAI chose the target, the protections and the way to count. That doesn’t make the work fake. It means the claims are a vendor’s, and independent confirmation will come from whether the patches keep landing in kernel releases over the next few weeks. We covered the same pattern on a smaller scale with the Xen virtualization flaws that Claude found, and the safety side of OpenAI’s cyber models in the GPT-6 Cyber scope test.
If you run Linux machines that other people can log in to, the practical step is the boring one: install kernel updates when your distribution ships them. The distribution’s security advisory page is the place to watch.