OpenAI's 948 Linux Root Exploits: What Admins Should Do Now

Official facts

OpenAI published "A thousand fewer paths to root" on 4 November 2026. These are the facts as reported, with each source named.

Item	Reported figure	Where we read it
Distinct LPE bugs	948	iTnews
Working exploits before grouping	1,169	Hardware Busters
Total API cost	$1,213,430	Hardware Busters
Reproduced vulnerabilities	1,724 of 2,308 candidates	Hardware Busters
Protections on in the exploit stage	SMEP, SMAP, KASLR, hardened usercopy	Hardware Busters
Model	an unreleased cyber model	iTnews, Hardware Busters

One outlet, Cybersecurity News, connects the story to a limited-access GPT-6 Cyber model. Other coverage we read leaves the model unnamed, so treat that link as unconfirmed.

What counts as one bug

The 948 figure is smaller than the 1,169 exploits because variants were grouped. A DEV Community analysis defines the unit as "the distinct patch that closes each one". That definition matters when you compare this count with a bug tracker, where one report does not always equal one fix.

Are the 948 bugs patched?

Not all of them. A passage from the post quoted on Hacker News reads: "When the autonomous scan and manual analysis finished after 10 days, 61 LPEs had already been patched upstream, 43 had staging patches, and 299 were being reported and discussed publicly."

The status figures need careful reading. Clauding says the patched group came from other contributors, not from OpenAI's reports. Separately, iTnews says OpenAI "submitted hundreds of reports and candidate patches", and Hardware Busters calls them machine-generated candidates that "passed human review". Candidate patches are not merged fixes.

OpenAI's warning to operators

The most quoted line is the practical one. Per iTnews, OpenAI says a low-privileged account on an unpatched system "should be considered functionally equivalent to root access for a well-resourced threat actor". The same article notes that "Parts of OpenAI's research cannot yet be independently verified."

What do the numbers actually prove?

Three calculations tell you more than the headline does.

The price is falling fast. $1,213,430 divided by 948 is about $1,280 per distinct bug. DEV Community reports an earlier July run of 166 LPEs for $513,690, which is about $3,095 each. On those two reported runs, the cost per bug fell by about 59% in roughly three months. iTnews says OpenAI calls the October figure an upper bound.

Most of the money went on exploits. DEV Community lists $775,929 for the exploit stage out of the total. Finding candidates was far cheaper: $3,426 to pick targets and $316,549 to analyse them. Turning a bug into a reliable exploit is still the expensive step.

A large share has no public status yet. Adding 61, 43 and 299 gives 403 of 948, or 42.5%. The other 545 bugs (57.5%) are not in the figures we could read. This is our subtraction, and the figures come from the end of the run, so the picture has moved since then. It does suggest that fixes will keep arriving for months.

How does this compare with earlier LPE waves?

This is not the first time in 2026 that administrators have had to rush kernel updates. InfoQ covered Copy Fail and Dirty Frag in May, both local privilege escalation bugs that hit major distributions. Those were single bugs with names and public exploits, so everyone knew what to patch.

The difference here is volume with no names attached. You will not get one advisory to act on. You will get a longer stream of ordinary kernel updates, and the safe response is a routine rather than an event. Treat the numbers as a vendor claim until maintainers report what they accepted. Some commenters below say earlier AI bug reports shrank after maintainer review.

What users report

These are Hacker News comments from the thread on OpenAI's post, between 4 and 5 November 2026. We did not verify any of them.

• Scepticism about counts. User wslh cited a Greg Kroah-Hartman talk and asked how many of the 948 had been independently confirmed upstream. User krona repeated a claim attributed to Kroah-Hartman that about half of such reports are wrong or do not matter. We did not confirm that figure.
• Maintainer load. User saagarjha expected the bottleneck to be people who can review the patches.
• Delivery to real systems. User dada216 said distributions such as Red Hat need to be involved, because a fix also has to reach installed systems.
• Withheld details. User evan_a_a called the decision to hold back new exploitation techniques convenient and asked for a full writeup.
• Containers. User dbdr asked whether containers and VMs are in the same position, and user cowlevel answered bluntly that "Containers are dead, user accounts are dead", which is opinion and not a finding.
• A team member replied. User dangelosaurus, who said it was their team's work, offered to take questions in the thread.

Are containers affected?

The reports we read do not say containers were tested. The reasoning is still simple, and it is ours: a container on a normal Docker or Kubernetes host uses the host's kernel, so a kernel LPE reached from inside a container is a route out of it. Docker's security documentation warns that default capabilities and mounts "may provide incomplete isolation, either independently, or when used in combination with kernel vulnerabilities".

Coverage of OpenAI's advice points to sandboxes such as gVisor or Firecracker instead of relying on the kernel boundary alone. Hardware Busters and GBHackers both mention them. Virtual machines put a separate kernel between workloads, so they raise the cost of this kind of attack, although they are not immune to other bugs.

Our take

Our view: the 948 is not your number. Your number is the days between a kernel fix being available and your server running it. Everything useful follows from that.

A bug that needs a local foothold does not change much for a single-purpose server with one trusted administrator and no untrusted code. It changes a lot for shared hosting, CI runners, multi-user machines and any host where containers run code you did not write. On those systems, a web app bug or a poisoned build step already gives an attacker the foothold, and LPE supplies the rest.

What we would do, in order:

1. Reboot after kernel updates. Installing a kernel does not protect you until the machine runs it. On Ubuntu, check for /var/run/reboot-required. In a cheap check of ubuntu:26.04, unattended-upgrades 2.12ubuntu9 shipped with Automatic-Reboot commented out at "false", so a server can install updates and stay on the old kernel for weeks. Set a reboot window that you can live with.
2. Consider Livepatch for the machines you cannot reboot often. Canonical says it is free "for up to 5 machines, for personal use, or evaluation purposes", and it targets critical and high severity kernel issues. It reduces the gap, but it does not replace reboots.
3. Move untrusted code out of shared kernels. CI jobs from outside contributors belong in a throwaway VM or a stronger sandbox. This is the change with the biggest effect, and it is also the most work.
4. Treat every low-privileged account as a possible root account. Remove accounts you do not need, and keep SSH access tight. Our SSH port guide for Ubuntu 26.04 and SSH key exchange guide are a starting point.
5. Do not wait for a CVE list. With this many fixes, you will rarely get a clear headline for the one that matters.

We would not panic, and we would not ignore this either. A $1,280 figure for one distinct LPE is an upper bound from one vendor's run, but even a rough number like that says this work is no longer rare. Assume attackers will get similar tools. The patch routine you can keep up is worth more than the emergency you cannot.

What we did not test

• We did not read OpenAI's post directly. Our fetch got HTTP 403, so we relied on quoted passages and press reports.
• We ran no exploit and tested no kernel. We have no access to OpenAI's model or pipeline.
• We do not know which kernel versions, architectures or distributions were in the run. The reports we read do not name them.
• We could not confirm how many candidate patches maintainers accepted, or how many CVEs exist. We found no statement from a kernel maintainer about this specific run.
• The Livepatch and Docker statements come from vendor pages. The only local check was reading the default unattended-upgrades file in a tiny ubuntu:26.04 container.

FAQ

Can these bugs be used to hack my server from the internet?

Not on their own. They are local privilege escalation bugs, so an attacker needs to run code on the machine first. A remote bug in a web app can provide that first step, which is why the two are often chained.

What should a server admin do if they are the only user?

Keep installing kernel updates and rebooting. The risk is lower with one trusted user, but any service you expose can become the local foothold if it has a bug of its own.

Can I update the Ubuntu kernel without a reboot?

Partly. Livepatch applies fixes for selected critical and high severity issues to a running kernel, and it is free for up to 5 machines for personal use. Normal kernel packages still need a reboot before they take effect.

Is Livepatch free on Ubuntu?

Canonical says it is free for up to 5 machines for personal use or evaluation. Larger or commercial use needs a paid plan, so check the current terms on Canonical's page before relying on it.

gVisor or Firecracker for untrusted code?

Both are named in coverage as ways to avoid relying on the kernel boundary alone. gVisor is a sandbox layer between apps and the host, and Firecracker runs small virtual machines. Your choice depends on your stack, and we have not compared them.

Does this make Linux less secure than other systems?

The reports do not show that. They show what one team found when it spent over a million dollars on one kernel, and nobody has published the same comparison for other systems. Hacker News users asked about OpenBSD and FreeBSD, with no results to compare.

Related guides

• Claude Code Extension Backdoor: Are You Affected?: another case of a foothold through developer tools.
• Pin GitHub Actions to a Commit SHA: reduce the code that runs in your pipelines.
• Upgrade Ubuntu 24.04 to 26.04 LTS on a Server: move to a release with current kernel updates.

Sources

• OpenAI: A thousand fewer paths to root, 4 November 2026 (primary source, not readable by our tools; returned HTTP 403).
• iTnews: Low-privileged accounts on unpatched systems as good as root: OpenAI, 6 November 2026.
• Hardware Busters: OpenAI's Agents Found 948 Linux Kernel Privilege Escalation Bugs in One Run, 5 November 2026.
• DEV Community: 948 Linux Root Exploits in One Run: What OpenAI's Kernel Pipeline Actually Proves, 5 November 2026.
• Clauding: A Thousand Fewer Paths to Root, 5 November 2026.
• GBHackers: OpenAI's New Cyber AI Model Finds 948 Linux Privilege Escalation Vulnerabilities, 5 November 2026.
• Cybersecurity News: OpenAI Launches GPT-6 Cyber, 6 November 2026.
• InfoQ: Copy Fail and Dirty Frag, May 2026.
• Canonical: Ubuntu Livepatch. Docker: Docker Engine security. gVisor: documentation.
• Hacker News: thread on OpenAI's post, 486 points when checked.

Update log

• 7 November 2026: first version.

Last verified: November 2026 (7 November 2026). Patch status figures date from the end of OpenAI's mid-October run and will have changed; check your distribution's security tracker for current fixes.

Header image: Image: DevOpsCompass.