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.

  1. 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.
  2. 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.
  3. 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.
  4. Patching. Agents drafted patches. Variant analysis produced 948 distinct patches, and OpenAI uses that count for unique flaws.
  5. Human review. Security researchers reviewed each exploit, patch, and severity rating before reporting.
OpenAI's Linux kernel run, from candidate flaws to distinct root exploitsCandidate findingsCandidate findings: 2,3082,308Reproduced flawsReproduced flaws: 1,7241,724Root exploit candidatesRoot exploit candidates: 1,2381,238Working root exploitsWorking root exploits: 1,1691,169Distinct flaws exploitedDistinct flaws exploited: 948948Root exploit candidates passed a static screen. Variant analysisgrouped 1,169 exploits into 948 distinct patches.
CHARTOpenAI's Linux kernel run, from candidate flaws to distinct root exploits. Source: OpenAI, A thousand fewer paths to root; chart by OpenNash.

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:

  1. An attacker gets a low-privileged account through a stolen credential, a web application flaw, or a poisoned build job.
  2. The attacker runs an LPE exploit on that machine and becomes root.
  3. Root exposes every secret on the machine, such as deployment tokens, SSH keys, and cloud credentials.
  4. 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.

Where the $1.2 million went, by pipeline stageExploit developmentExploit development: $775,929$775,929Analyst agentsAnalyst agents: $316,549$316,549ValidationValidation: $73,330$73,330Exploit screeningExploit screening: $44,194$44,194Scout agentsScout agents: $3,426$3,426Scout agents cost $3,426 and cut the audit to about 7% of thekernel.
CHARTWhere the $1.2 million went, by pipeline stage. Source: OpenAI, A thousand fewer paths to root; chart by OpenNash.

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 kernel privilege escalation in 2026May 1 2026May 1 2026: CISA lists Copy Fail as actively exploitedCISA lists Copy Fail as activelyexploitedMay 7 2026May 7 2026: Dirty Frag becomes public after an embargo breakDirty Frag becomes public after anembargo breakMay 13 2026May 13 2026: Fragnesia is disclosed and needs a separate patchFragnesia is disclosed and needs aseparate patchJul 2026Jul 2026: GPT-5.6 Sol exploits 166 distinct flaws for $513,690GPT-5.6 Sol exploits 166 distinct flawsfor $513,690Oct 2026Oct 2026: A newer cyber model exploits 948 distinct flaws for $1,213,430A newer cyber model exploits 948distinct flaws for $1,213,430
CHARTLinux kernel privilege escalation in 2026. Source: Tenable; OpenAI; chart by OpenNash.
  • 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:

  1. Patch shared systems first. Give them a shorter deadline than single-purpose servers.
  2. 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.
  3. 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.
  4. Remove long-lived secrets from shared hosts. Root can read any secret on the machine. Short-lived, scoped credentials limit what an attacker takes.
  5. 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.

  1. Add the scout, analyst, and validation costs: $3,426 + $316,549 + $73,330 = $393,305.
  2. Divide by 2.8 million audited lines. The result is about $140,000 per million lines.
  3. Scope your audit. If 2 million lines of your code are reachable by low-privileged users, the estimate is about $280,000 per scan.
  4. 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.
  5. 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.

How an AI-native security team handles a new kernel flawNew CVE or scan findingfeeds, vendors, and your own scansagents, within hoursMatch to live inventorywhich hosts, who owns themhunter agents, sandboxedReproduce the flawread-only source, no networkseparate verifier agentTry to disprove itfresh agent, then rank by real impactagentsDraft patch and testsecond agent attacks the patchpeopleEngineer approveshigh-impact changes and exceptionsagents, with rollbackRoll out and verifyring by ring, with evidence kept
DIAGRAMHow an AI-native security team handles a new kernel flaw. Source: OpenNash.

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:

  1. Map the estate. We build a live inventory of systems, kernels, dependencies, owners, and exposure, and we mark every shared Linux host.
  2. Automate patching. Agents match new CVEs to that inventory within hours, then open, test, and stage the patch or upgrade.
  3. Isolate shared systems. We move untrusted jobs and AI agents behind stronger boundaries and remove long-lived secrets from those hosts.
  4. Watch the logs 24/7. Agents detect and investigate threats, then escalate to your team with the evidence attached.
  5. 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.
  6. 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.