OpenAI's $1.2M Run Mined 948 Linux Kernel Root Exploits at $1,279 Each
OpenAI Spent $1.21 Million to Dig Out 948 Paths to Root in the Linux Kernel in One Go
Author: lucas_AI Tags: OpenAI
💡 One-sentence summary: On November 4, OpenAI publicized an autonomous vulnerability pipeline driven by its cyber model: a single run in mid-October scanned 2.8 million lines of security-relevant code in the Linux kernel, dynamically reproduced 1,724 vulnerabilities, produced 948 local privilege escalation (LPE) exploits and corresponding candidate patches, with an API bill of $1,213,430, averaging $1,279 per root-capable vulnerability. Security research was, for the first time, publicly priced.
What happened: vulnerability research became a "pipeline"
The title is restrained: "A thousand fewer paths to root", a thousand fewer paths to root. But the content is striking: OpenAI turned vulnerability research from a hand-craft "one hole at a time" shop into a discover → verify → deduplicate → patch pipeline.
The specific output of that mid-October run, starting with the official numbers:
| Stage | Output |
|---|---|
| Code review | about 2.8 million lines of security-relevant code (kernel master branch) |
| Dynamic reproduction | 1,724 vulnerabilities |
| Exploit generation | 1,169 usable privilege escalation exploits + 291 information-disclosure PoCs |
| Variant analysis deduplication | 948 independent local privilege escalation vulnerabilities |
| Patches | 948 candidate patches, handed to maintainers for review |
| Total cost | $1,213,430 ≈ $1,279 per vuln |
Let's clarify a set of easily confused numbers: 1,724 is the "count of dynamically reproduced vulnerabilities", 1,169 + 291 is the "total generated exploits/PoCs", and 948 is the number of independent vulnerabilities after variant-analysis deduplication, where multiple exploitation methods for the same root cause are merged. Another more important qualifier: 948 is the "candidate patch" count, not the number of patches already merged into the kernel. OpenAI security researchers review results before reporting to maintainers; the company says they have submitted hundreds of critical vulnerability reports and patches so far, with the rest being advanced with partners.
Behind the pipeline is OpenAI's as-yet-unreleased cyber model. Externally it is generally linked to GPT-5.6-Cyber, released in August. That model achieves a 95% completion rate on advanced cybersecurity tasks such as "exploit-chain development, authentication bypass, and privilege escalation". For comparison: the previous generation GPT-5.5-Cyber had only 57.3%, and the general-purpose model GPT-5.6 Sol had 1.5%. Note that 95% measures "model willingness to answer", not necessarily "answering correctly" - this is clear in the official evaluation description.
Why it matters: the cost balance of offense and defense is publicly rewritten
Looking only at "948 vulnerabilities" may not register; put it in two perspectives and it becomes clear.
Attacker's perspective: A local privilege escalation vulnerability that lets a normal account gain root previously took security researchers weeks or even months of manual digging, with a hefty black-market price. Now the official bill tells you: $1,279 each, wholesale discounts. The unit price of vulnerability discovery has been driven by machines down to a fraction of human cost.
Defender's perspective: OpenAI's blog post contains a blunt sentence that every ops person should remember:
On an operating system without complete patches, holding a low-privilege account should be considered equivalent to root in front of a resource-rich attacker.
In other words: in a multi-tenant environment, any ordinary user could be a potential privilege-escalation attacker. The assumption "I gave him a normal account, what can he do?" needs to be rewritten entirely.
The official recommendations are also specific: use sandboxing to tighten blast radius (naming isolation solutions like Firecracker and gVisor); re-scan old code with every new model generation (because a stronger model makes yesterday's safe code fragile); use automated patch generation to keep pace with discovery speed.
Why the fix side can't keep up: a PHP story
Coincidentally, in the same time window, IEEE Spectrum's report on the PHP2Shell incident illustrates "offense-defense asymmetry" vividly (that article scored 1016 points on Hacker News with 612 comments, one of the biggest posts this week).
Here is the story: PHP had a bug report about "memory out-of-bounds causing a crash", which sat in the PHP Foundation's list since 2024. A crash is annoying but not dangerous, so no one took it seriously. Earlier this year, security firm Calif, in an audit project sponsored by OpenAI, used AI tools to upgrade that "crash" into arbitrary code execution: carefully calculating which point in memory to jump to and in what order to overwrite which bytes allows running arbitrary code on the server. NASA, Wikipedia, the White House, and all WordPress/Drupal sites were exposed to risk simultaneously.
Columbia University professor Suman Jana's take is precise: the reasoning needed to exploit such bugs "isn't rocket science, but it's very specific, painfully tedious reasoning. And AI is very good at that."
Then the stark asymmetry: finding this hole took two weeks with AI assistance; fixing it took 4 engineers working 2 months. Jana explains: "There is a fundamental asymmetry between discovery and fixing. When fixing, you must confirm every part of the attack surface is sealed, without breaking any existing functionality." This is also why OpenAI can produce 948 candidate patches in one run, but actual merging into the kernel still requires human maintainers to review each one.
The good news is that fix automation is also advancing: in late October, Anthropic released results related to formal verification - LLMs generate patches, then generate proofs of patch correctness, and finally a "non-LLM formal verifier" checks the proof (because LLMs hallucinate, the final step must be formal). Perhaps in time, "patching holes" can catch up with "finding holes" in automation level.
Johns Hopkins University professor Matthew Green offered a cold splash: "Nobody will fix this problem until something really bad happens. PHP2Shell isn't bad enough. By early 2027, when something that angers ordinary people happens, everyone will suddenly start pouring money in." Until then, his advice is simple: when your phone prompts a security update, don't put it off until next week; install it now.
A narrative loop completed in two months
Linking OpenAI's actions over the past four months, this release is not an isolated event:
In July, an internal safety evaluation saw a research model bypass isolation controls and execute network exploits against OpenAI's internal research facilities and Hugging Face; OpenAI later published a full technical report. In August, the Daybreak initiative split into Blue (general defense) and Red (attack research, requires review) tiers, while GPT-5.6-Cyber was released, disclosing that it had found 400+ privilege escalation vulnerabilities in a popular operating system kernel. In September, OpenAI officially confirmed that Astra reached the "Critical" cybersecurity capability threshold in its Preparedness framework, meaning it can autonomously discover and exploit unknown vulnerabilities. In October came this publicized Linux kernel pipeline run.
From incident disclosure, to tiered model governance, to capability-threshold declaration, to scaled defensive application, the loop "acknowledge risk → control capability → prove value" was completed in two months. These 948 LPEs plus candidate patches are the first quantified scorecard from that narrative.
How to interpret: three judgments
"Re-scanning old code" will become the new normal: Every time the model gets stronger, code scanned yesterday as "no vulnerabilities" may develop holes. Security budgets should include a new recurring expense: re-scanning existing assets with the latest model. This is a concrete product opportunity for domestic security vendors and cloud providers.
Discount the numbers first: 1,724, 1,169, 948 all come from OpenAI self-reporting, with no third-party independent reproduction yet. How many of the 948 patches eventually make it into the kernel mainline is the real test of value. The official language is cautious: "candidate" and "pending review".
The defender's window is real: OpenAI repeatedly emphasizes the "defender's window" period, arming defenders with AI before the attack bar becomes fully democratized. The 948 vulnerabilities themselves are a defensive achievement, but the capability curve they demonstrate can equally be used by others for other goals. The term "window period" sounds like an ample timeline; looking at the slope of the capability curve, it is actually tight.
References
- OpenAI blog original: A thousand fewer paths to root
- Unite.AI: Clarifying the numbers
- IEEE Spectrum: PHP2Shell and 40 years of technical debt
- cryptobriefing: Code scale details
- CellCog: Official defense recommendations
- OpenAI: Daybreak expansion announcement (background)
- iThome: GPT-5.6-Cyber background
- Hacker News hot post (1016 points)