A working Linux root exploit now costs about $1,280 in AI compute. OpenAI published that figure on November 4, 2026. One autonomous run produced exploits for 948 distinct Linux kernel flaws at a total cost of $1,213,430. OpenAI is reporting the flaws to maintainers with candidate patches, so this is defensive research. The same economics will reach attackers. CIOs need patch speed and isolation that match this pace, and that work needs an AI-native security team or a partner that runs one.
What OpenAI Measured
OpenAI built a five-stage research pipeline around an upcoming cyber model. Each flaw class in the run is a local privilege escalation (LPE). An LPE lets an ordinary logged-in user become root, and root controls the whole machine.
- Discovery. Scout agents chose 5,034 audit targets, about 2.8 million lines or 7% of the kernel. Analyst agents then produced 2,308 candidate findings in 12 hours.
- Validation. A triage agent wrote a proof of concept for each candidate and ran it in an isolated virtual machine. It reproduced 1,724 flaws in 30 hours.
- Exploitability. A screening agent kept 1,238 LPE candidates and 313 information leak candidates. Exploit agents then built 1,169 working root exploits and 291 leak proofs of concept.
- Patching. Agents drafted patches. Variant analysis produced 948 distinct patches, and OpenAI uses that count for unique flaws.
- Human review. Security researchers reviewed each exploit, patch, and severity rating before reporting.
The targets ran a stock desktop operating system with standard protections on, including SMEP, SMAP, and KASLR. These are the same conditions that competitions such as Pwn2Own use. OpenAI also says the agents used at least 10 exploitation techniques that outside kernel experts had not seen.
What a Local Exploit Needs
An LPE needs a foothold. The attacker must already run code on the machine as a normal user. OpenAI's run does not show remote takeover of Linux servers from the internet.
Anthropic's Mythos Preview work supports this limit. Its model wrote several Linux LPE exploits, and it chained up to four flaws to reach root. Kernel defenses stopped it from exploiting the remotely triggerable Linux bugs it found, even after several thousand scans.
A foothold is still easy to get. A typical chain has four steps:
- An attacker gets a low-privileged account through a stolen credential, a web application flaw, or a poisoned build job.
- The attacker runs an LPE exploit on that machine and becomes root.
- Root exposes every secret on the machine, such as deployment tokens, SSH keys, and cloud credentials.
- The attacker uses those secrets to reach production.
Mandiant's M-Trends 2026 reports that the median hand-off from initial access to a second threat group fell from more than 8 hours in 2022 to 22 seconds in 2025. OpenAI says that for the near and medium term, a low-privileged account on an unpatched system is functionally equal to root access for a well-resourced attacker.
Where the $1.2 Million Went
Exploit development took 64% of the money. Finding the flaws took about a quarter.
| Stage | Output | API cost | Share of total |
|---|---|---|---|
| Scout agents | 5,034 audit targets | $3,426 | 0.3% |
| Analyst agents | 2,308 candidates | $316,549 | 26.1% |
| Validation | 1,724 reproduced flaws | $73,330 | 6.0% |
| Exploit screening | 1,551 exploit candidates | $44,194 | 3.6% |
| Exploit development | 1,169 root exploits, 291 leak proofs | $775,929 | 63.9% |
| Full run | 948 distinct root flaws | $1,213,430 | 100% |
$1,213,430 divided by 948 distinct flaws is about $1,280. OpenAI reports $1,279. The figure covers the whole run. A successful exploit attempt alone averaged about $360.
Three numbers affect the plan for a similar program:
- Scoping is cheap. Scout agents cost $3,426 and removed 93% of the code from the audit.
- Validation works. Agents reproduced 74.7% of candidates. Of the findings that did not validate, only 3.1% came from incorrect analysis.
- Hard cases burn money. Failed root exploit attempts averaged $3,922 across 69 cases. That is about $270,600, or 39% of the root exploit budget, spent on 5.6% of the candidates. OpenAI says a give-up rule would have cut this cost.
The Price Fell 59% in Three Months
OpenAI ran the same kind of scan twice on the latest kernel, and it also tested a hardened target.
| Run | Target | Distinct root flaws | API cost | Cost per flaw |
|---|---|---|---|---|
| July 2026, GPT-5.6 Sol | Latest kernel | 166 | $513,690 | $3,094 |
| October 2026, newer cyber model | Latest kernel | 948 | $1,213,430 | $1,280 |
| kernelCTF, newer cyber model | Hardened kernel | 21 | $32,936 | $1,568 |
The October run found 5.7x more flaws than the July run, after three more months of kernel fixes. Cost per flaw fell 59%. The kernelCTF target is Google's hardened test environment, and it has a smaller attack surface. The agents still produced 21 exploits. kernelCTF has accepted 26 confirmed zero-day LPE exploits from all contributors so far in 2026.
OpenAI also compared cost to historical bounties. At $20,000 to $70,000 per exploit, 948 exploits have a hypothetical value of $18.9 million to $66.3 million. That is 16x to 55x the cost of the run. OpenAI describes its own costs as closer to an upper bound, because it did not tune the pipeline for cost.
The newest model is not public. OpenAI expects that even less capable models will develop exploits once a flaw is disclosed, within the next few years. Attackers can then study each published kernel fix and build an exploit from it.
Other Sources Show the Same Pressure
The OpenAI run fits a pattern that many organizations have reported in 2026.
- Linux maintainers. Greg Kroah-Hartman reports that kernel releases went from around 500 CVE fixes to nearly 2,000.
- CISA. The agency added Copy Fail (CVE-2026-31431) to its Known Exploited Vulnerabilities (KEV) catalog on May 1, 2026.
- Tenable. The company reports that the Dirty Frag patches do not fix Fragnesia. Teams needed a second patch within a week.
- Anthropic. Its model turned Linux flaws into root exploits, and it chained up to four flaws in nearly a dozen cases.
- Other researchers. Within the 10 days of OpenAI's work, 61 of the LPEs were patched upstream, 43 had staging patches, and 299 were under public discussion. Other contributors did much of this work. That is about 400 flaws, or 43% of the total, that other people had also reached.
When several teams reach the same flaw in 10 days, you should assume that attackers can reach it too.
Defenders are losing time on the other side:
| Measure | Latest figure | Source |
|---|---|---|
| Mean time to exploit | -7 days, an estimate | Mandiant M-Trends 2026 |
| Exploits as first entry point | 32% of intrusions | Mandiant M-Trends 2026 |
| Software flaws as first entry point | 31% of breaches | Verizon DBIR 2026 |
| Median time to patch | 43 days, up from 32 | Verizon data via Tenable |
| KEV flaws fully fixed | 26% | Verizon data via Tenable |
A negative mean time to exploit means that attacks often start before a patch exists. A 43-day patch cycle cannot answer that. Isolation must cover the gap, and patching must get much faster.
Find Where a Low-Privileged Account Equals Root
Start with shared Linux systems. On these systems, many users, jobs, or agents can run code as normal users. One LPE turns any of them into root.
| System | Who runs code there | What root exposes |
|---|---|---|
| CI and build runners | Every pipeline job | Deployment tokens, signing keys |
| Kubernetes nodes | Every container on the node | Other pods, service account tokens |
| Jump hosts | Administrators, vendors | SSH keys, paths to production |
| Data science and GPU servers | Analysts, notebooks | Data extracts, model API keys |
| AI agent sandboxes | Agents, and the code they generate | Tool tokens, customer data |
Containers share the host kernel, so an unpatched kernel flaw can cross a container boundary. The Binance theft also moved through a container deployment token. Take these actions on the systems in this table:
- Patch shared systems first. Give them a shorter deadline than single-purpose servers.
- Take whole stable kernel updates. At nearly 2,000 CVE fixes per release, teams cannot judge each CVE by hand. Plan for scheduled reboots or live patching.
- Isolate untrusted code. OpenAI names Firecracker and gVisor. gVisor passes no system call directly to the host. Firecracker puts each workload behind a virtual machine boundary. Our guide to agent sandboxes compares the options.
- Remove long-lived secrets from shared hosts. Root can read any secret on the machine. Short-lived, scoped credentials limit what an attacker takes.
- Prefer hard barriers. Anthropic warns that mitigations that only add friction will weaken against model-assisted attackers.
Apply the Same Method to Your Own Code
OpenAI says its lessons apply to proprietary software as well as open source. Cloudflare has already done this work on its own code. A harness is the software that directs agents, stores their results, and checks their work. The findings pool from Cloudflare's vulnerability harness covers 145 repositories. Cloudflare also released the starting version as an open-source security audit skill.
| Cloudflare step | Findings |
|---|---|
| Raw candidates from the discovery harness | 20,799 |
| Candidates that survived validation | About 12,057 |
| Shared pool, with findings from another harness added | 13,841 |
| Duplicates removed | 5,442 |
| Routed as wrong repository or low risk | 1,154 |
| Actionable findings for engineers | 7,245 |
About 42% of raw candidates failed validation. Duplicates and routing removed about 48% of the shared pool. Cloudflare calls these findings the result of an isolated research experiment, and it says they are not active flaws in its live production systems.
Each published finding below becomes a rule for your program.
| Finding | Source | Rule for your team |
|---|---|---|
| Hunter agents edit source so their own exploit works | Cloudflare | Run each proof against the original code. Keep source read-only and block the network |
| Two agents in disagreement beat one careful agent | Cloudflare | Send each finding to a fresh agent that tries to disprove it |
| 20 of 200 early exploits used the wrong flaw | OpenAI | Check the path to a result, plus the result |
| One run finds about half of what repeat runs find | Cloudflare | Track coverage in a ledger and rerun until the gaps close |
| The newer model found 5.7x more flaws | OpenAI | Rescan code with each new model generation |
| Better context from reconnaissance cut first-round rejections from 40% to 11% | Cloudflare | Map trust boundaries before you hunt |
| Basic exposures get missed because everyone assumes someone checked | Cloudflare | Give one agent only the basics, such as secrets, debug endpoints, and open admin pages |
| A bug and a reachable bug are two different questions | Cloudflare | Give a severity only when a finding shows real impact |
| Maintainers fixed flaws during the scan | OpenAI | Recheck each finding against the latest code |
| 69 hard cases took 39% of root exploit spend | OpenAI | Set a stop rule, such as one hour without progress |
| Agents also broke the test system through QEMU | OpenAI | Harden test systems before you run offensive agents |
| Direct patches were sometimes incomplete | OpenAI | Use a second agent to attack each patch |
Cloudflare's skill adds a limit on severity. If one layer already stops an attack, a missing second layer is a hardening note. This rule keeps engineers on flaws that attackers can use.
The two companies differ on tooling. OpenAI removed its added technique library because stronger models needed it less. The library raised GPT-5.5 Cyber's success rate from 76.2% to 88.9%, and it added only 1.5 points for GPT-5.6 Cyber. Cloudflare says the harness is the part that lasts. Its agents also ignored Semgrep, a code scanner, for a month of runs. They preferred to read and run the code. Both results fit one rule. Remove the hints and tools that tell a strong model how to think. Keep the controls that check its work, such as separate verifiers, sandboxes, ledgers, and human approval.
Agents reported 200 successful exploits in an early run. Human review found that 20 of them, or 10%, reached root through a different zero-day. The agents reached the goal by a path that nobody had asked for. Independent checks found this, so keep them in every agent workflow.
You can size a first program from OpenAI's figures. These are kernel rates, and your code will differ.
- Add the scout, analyst, and validation costs: $3,426 + $316,549 + $73,330 = $393,305.
- Divide by 2.8 million audited lines. The result is about $140,000 per million lines.
- Scope your audit. If 2 million lines of your code are reachable by low-privileged users, the estimate is about $280,000 per scan.
- Plan for more than one scan. OpenAI says large projects need repeated rounds. Cloudflare reports that each added pass costs roughly half as much as the first hunt.
- Stop at proof of impact. OpenAI spent 64% of its budget on full exploits. Cloudflare says almost all of its compute goes to the hunt. Your own code needs a working proof, and it rarely needs a full root exploit.
Each scan produces a queue of proven flaws. Your team must then fix, test, and ship those fixes.
Why Patching Needs an AI-Native Team
OpenAI found that prioritization and validation are the bottleneck. It also says automated patch generation is essential at this pace. A security team that works through tickets by hand cannot clear thousands of flaws, or watch logs at 3 a.m. while it tries.
An AI-native security team is a small group of senior engineers who run agents for routine work. Agents do the matching, reproducing, drafting, and testing. Engineers write the rules, handle exceptions, and approve high-impact changes. Each incident improves the rules, so the next flaw takes less human time.
Cloudflare publishes a benchmark. For a standard repository of about 30,000 lines, a full run takes 3 to 4 hours and yields about 80 distinct bugs. Its fixer agent reaches functional pull requests in roughly 14 hours. About 10 critical bugs reach production fixes in 5 days, and the rest roll out over 15 to 20 days. The fixer never merges code on its own. A human must review each branch.
The team also has a new job, which is to serve the agents. Cloudflare's agents write to a central wishlist when they need something they lack, such as a build environment, a virtual machine, or a configuration file. A person supplies it, and the exact task runs again. The wishlist reached 25,472 entries across 128 repositories, and Cloudflare calls it the agents' main way to reach the team. Plan engineer time for this queue. Each unanswered entry is a finding that nobody has settled.
Measure this team by time and coverage. These starting targets are OpenNash's recommendations for shared Linux systems:
| Measure | Starting target |
|---|---|
| New CVE matched to live inventory | Within 4 hours |
| Exploited kernel flaw patched or isolated | Within 72 hours |
| Stable kernel update rolled out | Within 14 days |
| Shared hosts with strong isolation | 100% of untrusted workloads |
| Findings with a working proof before a ticket | 100% of high-severity findings |
| Findings checked by a separate verifier agent | 100% |
| Repositories with a current coverage ledger | 100% of critical repositories |
| Logs reviewed | 24 hours a day, 7 days a week |
Build the Team or Use OpenNash Security
A CIO has two practical ways to reach those targets.
| Question | Build an AI-native team | Use OpenNash Security |
|---|---|---|
| Who runs the agents? | Your engineers | OpenNash engineers, inside your team |
| What do you need first? | Senior platform and security engineers | An executive owner and system access |
| When is it the better choice? | You have the talent and the time | You need 24/7 coverage soon |
| Who keeps pace with new models? | Your team | OpenNash, with your team |
| What do you own at the end? | Everything you build | Agents, playbooks, inventory, and audit logs |
The two choices can work in sequence. A partner can run the agents first while your engineers learn the system, and your team can then take over.
OpenNash Security gives you that coverage. OpenNash puts forward-deployed engineers on your team and works with Fortune 2000 companies. We deploy in your cloud, on-premises, or in air-gapped environments, on the systems you already run. A typical engagement follows these steps:
- Map the estate. We build a live inventory of systems, kernels, dependencies, owners, and exposure, and we mark every shared Linux host.
- Automate patching. Agents match new CVEs to that inventory within hours, then open, test, and stage the patch or upgrade.
- Isolate shared systems. We move untrusted jobs and AI agents behind stronger boundaries and remove long-lived secrets from those hosts.
- Watch the logs 24/7. Agents detect and investigate threats, then escalate to your team with the evidence attached.
- Test your own code. Scoped agents scan and red team your systems on a schedule. Separate agents try to disprove each finding before it reaches your team.
- Train your team. Your engineers learn to run the agents, so you can build your own AI-native team over time.
You own the agents, playbooks, inventory, and audit logs at the end.
Book a call with an OpenNash forward-deployed engineer or email us at hello@opennash.com. In the first session, we review your shared Linux systems and your top security risks, and show which steps give the highest business value and the fastest ROI.