On 4 November OpenAI published a post with a slightly smug title, "A thousand fewer paths to root". It says an automated pipeline running one of their unreleased models found, exploited and wrote patches for 948 separate Linux kernel bugs that let an ordinary user become root. One run, about ten days, roughly $1.2 million in API credits.
I read the whole thing twice, because most of the machines I look after at home and at work run Linux somewhere: Pi-hole, TrueNAS, Proxmox, a few Docker hosts, and the firewalls and access points that quietly run a Linux kernel too. Below is what OpenAI actually did, the numbers people are getting wrong, the parts I'm sceptical about, and what I think anyone running Linux should do this week.
Quick answer
OpenAI's pipeline scanned about 7% of the Linux kernel, reproduced 1,724 real bugs, and built 1,169 working root exploits that collapse into 948 distinct vulnerabilities, each with a candidate patch. The patches go to kernel maintainers after human review, and most are not merged yet. For you that means one thing: keep your kernels updated and actually reboot, and stop treating a low-privilege shell account as harmless.
What OpenAI actually built
This isn't one chatbot prompt that said "find bugs in Linux". It's a pipeline of agents, each with one job, handing work down the line. OpenAI calls the model behind it an "upcoming cyber model" and doesn't name it. The run was against the latest kernel master branch in mid-October 2026, on a stock desktop distribution with the normal protections switched on (SMEP, SMAP, KASLR and HARDENED_USERCOPY), so it wasn't a weakened test box.
- Scout agents read through the kernel folder by folder and picked code that an unprivileged user can actually reach. They chose 5,034 targets, about 2.8 million lines.
- Analyst agents read each target, worked out its threat model and listed candidate bugs.
- Triage agents wrote a proof of concept for every candidate and ran it in a throwaway VM with KASAN (the kernel's memory error detector) until it either crashed the way the report said or ran out of ideas.
- ExploitDev agents tried to turn the real bugs into either an information leak or a full root shell.
- Patch generation wrote a fix for each one, then a human security researcher reviewed the exploit, the patch and the severity before anything went to the maintainers.
Each finding comes out as a bundle: root cause, a minimal crashing test, a candidate patch and the working exploit. That's the bit maintainers care about. A vague "this might be a bug" report wastes their time. A report with a crash log and a patch doesn't.
The numbers, stage by stage
Most headlines just say "948 vulnerabilities". The funnel is more interesting, and it shows where the 948 comes from:
| Stage | Result | API cost |
|---|---|---|
| Scouts pick audit targets | 5,034 targets, about 7% of the kernel | $3,426 |
| Analysts scan (12 hours) | 2,308 candidate findings | $316,549 |
| Triage reproduces (30 hours) | 1,724 confirmed bugs (about 75%) | $73,330 |
| Screening for impact | 313 leak and 1,238 root candidates | $44,194 |
| Exploit development | 291 info leaks, 1,169 working root exploits | $775,929 |
| Variant analysis | 948 distinct vulnerabilities, one patch each | Total $1,213,430 |
So 1,169 exploits, but several of them hit the same underlying flaw from different directions. When OpenAI grouped them by the fix needed, it came to 948. That works out to $1,279 per unique root bug, and an average successful exploit cost about $359 to build.
The figure that surprised me most was the false positive rate. Only 3.1% of the candidates were the model being plain wrong. The rest that didn't reproduce were mostly bugs that needed extra privileges, or race conditions that didn't trigger inside the time limit. Anyone who has run a static analyser on a big C codebase knows how unusual that is. Those tools normally bury you in noise.
The model gap is the real story
OpenAI ran the same idea twice. In late July, GPT-5.6 Sol found 166 unique root bugs for about $514,000. In mid-October, the newer model found 948 for $1.2 million, against a kernel that had three more months of fixes in it. Back in June, GPT-5.5 Cyber had produced 24 exploits.
24, then 166, then 948 in about five months. The kernel didn't get five times worse; the models got better at reading it. OpenAI's own conclusion is that big codebases will need rescanning with every new model generation, because each one finds what the last one missed. I think that's right, and it applies to attackers' models just as much as defenders'.
They also say the agents used at least 10 exploitation techniques that outside kernel experts hadn't seen before, including new ways to spray objects and groom memory pages and five "data-only" methods of getting root. The details are held back for safety, which is fair.
The parts I'd take with a pinch of salt
I'm impressed, but a few things are worth keeping in mind before quoting the headline:
- These are OpenAI's own numbers. Nobody outside the company has re-run the pipeline. The kernel community's reaction over the next few months, and how many patches actually get merged, will say more than the blog post.
- 948 is not 948 fixes in your kernel. They're candidate patches for maintainer review. When the run finished, 61 of the bugs had been patched upstream and 43 had fixes staged, many by other contributors who found them independently. Around 300 more were being discussed in public.
- Only 7% of the kernel was scanned. That's the reachable, security-relevant slice, which is the sensible slice. It also means there's probably more in there.
- The cost is called an upper bound. OpenAI says they optimised for measuring the model, not for saving money. A cheaper harness would bring the price down, for them and for whoever copies the approach.
- The bounty comparison is hypothetical. They value the 948 exploits at $18.9 million to $66.3 million using old Pwn2Own and TyphoonPWN payouts. That's a way to make a point, not money anyone was paid.
Two honest admissions in the post made me trust it more. In an early run, 20 out of 200 "successful" exploits got root through a different unknown bug than the one they were assigned, so the system was marking its own homework wrong until they added an independent check. And during a test against Google's kernelCTF setup, an agent crashed the test machine and traced it to a bug in QEMU, the emulator running the VM, without even having QEMU's source code. If AI can break out of the lab by accident, the lab needs testing too.
Why this matters if you run Linux
The line from the post I keep coming back to is that an unpatched machine with a low-privilege account "should be considered functionally equivalent to root access" for a well-funded attacker. Read that again if you've ever thought "it's fine, that user can't do anything".
Local privilege escalation bugs need the attacker to already be on the machine. In real life that's not hard: a weak SSH password, a vulnerable web app running as www-data, a compromised container, a shared jump box. Until now, getting from that foothold to root on an up-to-date kernel took skill and time. If finding and exploiting these bugs gets cheap, the "and time" part goes away.
Containers deserve their own mention. Every Docker container on a host shares that host's kernel. A kernel root bug inside a container is usually a way out of it. OpenAI specifically recommends stronger isolation like gVisor and Firecracker for anything running untrusted code, and I'd agree. If you're hosting other people's workloads on plain Docker, now is a good time to think about that.
What I'm checking on my own machines
None of this needs anything clever. It's the boring patching discipline most of us let slide on the boxes that "just work".
1. See which kernel you're actually running
Installed and running are not the same thing. A box can download a new kernel and keep running the old one for months because nobody rebooted it.
uname -r
# Debian / Ubuntu / Raspberry Pi OS: is a reboot waiting?
cat /var/run/reboot-required 2>/dev/null
# Fedora / RHEL / Rocky
sudo dnf needs-restarting -r2. Update, then reboot
# Debian, Ubuntu, Raspberry Pi OS, Proxmox
sudo apt update && sudo apt full-upgrade
sudo reboot
# Fedora, RHEL, Rocky, Alma
sudo dnf upgrade --refresh
sudo rebootOn a Pi-hole or a home server, a two-minute reboot on a Sunday morning is cheap. On servers that can't go down, Ubuntu Livepatch or your distribution's equivalent patches many kernel bugs without a restart, but it doesn't cover everything, so still plan real reboots.
3. Turn on automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgradesThis installs security fixes on its own. It won't reboot for you unless you set Unattended-Upgrade::Automatic-Reboot in /etc/apt/apt.conf.d/50unattended-upgrades, so either enable that with a sensible time or put a monthly reboot in your calendar.
4. Count who can log in
Fewer local accounts means fewer footholds. This lists every account with a real login shell:
getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1, $7}'Remove the old test user, the contractor from two years ago, the account you made for one script. Use SSH keys and turn off password login if you haven't already.
5. Don't forget the appliances
Routers, NAS boxes, access points, cameras and TV boxes all run Linux, and they're the ones that never get updated. Check for firmware updates on the ones you own. If a device stopped getting updates years ago, keep it off networks that matter.
If a kernel update breaks something
This is the usual reason people stop patching, so it's worth knowing how to back out. Distributions keep the previous kernel installed for exactly this reason.
- Reboot, and on the GRUB screen pick Advanced options, then the previous kernel version. Hold Shift (BIOS) or tap Esc (UEFI) during boot if the menu is hidden.
- Once you're back up, check the version with
uname -rand look at what broke. It's usually a driver, especially out-of-tree ones like NVIDIA or ZFS DKMS modules. - On Proxmox you can pin the working kernel until a fix arrives:
proxmox-boot-tool kernel list
proxmox-boot-tool kernel pin 6.x.y-z-pve
# later, when the fixed kernel is out
proxmox-boot-tool kernel unpinTreat rolling back as temporary. Running the old kernel means running every bug the new one fixed, which after this week is a longer list than it used to be.
A few things I took away
- Finding bugs isn't the hard part any more. OpenAI says so directly: the bottleneck was proving which findings were real and important. That's going to be true for everyone, including the maintainers getting the reports.
- Patching speed is now a security control. The gap between a fix landing and someone exploiting the old bug keeps shrinking. "We update quarterly" doesn't hold up against that.
- Defence in depth matters again. If any local user might become root, then what stops them getting a local shell in the first place (firewalls, MFA, network segmentation, least privilege) carries more weight.
If you want the background on how we got here, I wrote about Claude Mythos and what AI means for cybersecurity and why everything seems to be getting hacked earlier this year. This news is the same trend moving faster than I expected. My own setup is in Homelab Intelligence, and if you'd like a second pair of eyes on patching and hardening your office servers or network, that's the kind of work I do through my network services.
The source for everything above is OpenAI's own write-up, A thousand fewer paths to root, which goes into much more detail on cost and methodology if you want to dig in.
Frequently asked questions
How many Linux kernel vulnerabilities did OpenAI find?
OpenAI's pipeline reproduced 1,724 real kernel bugs and built 1,169 working root exploits, which grouped into 948 distinct local privilege escalation vulnerabilities. It also produced 291 information leak proofs of concept. The run happened in mid-October 2026 and cost about $1.2 million in API credits.
Have the 948 Linux vulnerabilities been patched?
Not all of them. Each has a candidate patch, but patches go to kernel maintainers after human review. When the run ended, 61 had been fixed upstream and 43 had staged fixes. OpenAI says it has sent hundreds of reports and is releasing the rest gradually with Patch the Planet partners.
Can these Linux bugs be exploited remotely?
They are local privilege escalation bugs, so an attacker first needs some access to the machine, such as a user account, a hacked web app or a container. From there the bug lets them become root. That's why keeping kernels updated and limiting local accounts both matter.
Which AI model did OpenAI use for the Linux kernel scan?
OpenAI only calls it an "upcoming cyber model". An earlier run in July with GPT-5.6 Sol found 166 unique root bugs, and GPT-5.5 Cyber produced 24 exploits in June, so the newer model found more than five times as many as the July run.
What should I do to protect my Linux server?
Install kernel updates and reboot so the new kernel is actually running, turn on automatic security updates, remove unused login accounts, use SSH keys instead of passwords, and use stronger isolation than plain Docker for untrusted workloads. Keep the previous kernel available in GRUB in case an update breaks a driver.