OpenAI’s 948 Linux root exploits change one assumption for API teams: a low-privileged foothold on an unpatched server may not stay low-privileged for long. Check your running kernel, install your distro’s security updates, reboot into the new kernel, and limit what a compromised process can reach. These are local bugs, so an attacker needs a foothold first. They are not remote exploits by themselves.
uname -r # the kernel you're running now
cat /etc/os-release # your distro and version
uptime # how long since the last reboot
TL;DR
- OpenAI’s pipeline produced 948 unique local privilege escalation (LPE) exploits on Linux for $1,279 each in API credits.
- OpenAI says a low-privileged account on an OS that isn’t on its latest patches “should be considered functionally equivalent to root access for a well-resourced threat actor.”
- Many of these bugs are still being reported and fixed. OpenAI publishes no list of affected versions, so no kernel version can be called safe.
- OpenAI’s post reports no attacks using these 948 bugs.
- Your job this week: patch and reboot, isolate risky workloads, and shrink what each service account can touch.
What OpenAI found: the numbers
OpenAI’s report, “A thousand fewer paths to root”, published November 4, 2026, describes a mid-October run against the latest Linux kernel using an upcoming cyber model. The exploits were tested on a stock desktop OS from a commonly used distribution, with standard protections on (SMEP, SMAP, KASLR, HARDENED_USERCOPY), inside isolated virtual machines.
| Metric | Result |
|---|---|
| Audit targets | 5,034 (about 2.8M lines, roughly 7% of the kernel) |
| Candidate findings | 2,308 |
| Dynamically reproduced | 1,724 (about 74.7%) |
| Information leak proofs of concept | 291 |
| Working LPE exploits | 1,169 |
| Unique LPEs after variant analysis | 948 |
| Total API cost | $1,213,430 ($1,279 per LPE exploit) |
| July run with GPT-5.6 Sol | 166 unique LPEs for $513,690 |
| Status after the 10-day scan | 61 LPEs patched upstream, 43 with staging patches, 299 under public discussion |
OpenAI calls its costs “more an upper bound,” because it wasn’t optimizing for price. The October run also found more than 5x as many novel LPEs as the July run, despite three months of hardening between the scans.
OpenAI says it has sent hundreds of reports and patches for critical bugs and is sending the rest gradually with Patch the Planet partners. Exploit details stay private, including at least 10 novel techniques. So there’s no list to check your kernel against, and a fix landing upstream doesn’t mean your distro has shipped it yet.
What “local” means for an API server
A local privilege escalation bug lets a user who already runs code on a machine become root. Nobody can trigger one by sending a request to your API alone. An attacker first needs a foothold, such as code execution inside your service or a shell through a stolen credential. The kernel bug is the second step.
API servers offer plenty of first steps:
- A bug in your stack. PHP2Shell, React2Shell and the Node.js Brotli RCE all show how code execution can start at the application layer.
- A stolen token. A leaked SSH key or CI token can hand an attacker a shell. Stolen AI keys show how fast leaked credentials get used.
- A compromised service account. A deploy bot or shared worker account usually has more reach than anyone remembers.
You might have treated that foothold as contained because the process runs as an unprivileged user. OpenAI’s view removes that comfort for unpatched systems facing a well-resourced attacker. Plan as if the first bug in your API can become root on that host.
Keep the limits in view. The test target was a desktop OS, and OpenAI doesn’t say how many of the 948 bugs apply to a given server build. Your exposure depends on your kernel, your patch state and whether anyone can get that first foothold.
Check your kernel and patch state in 2 minutes
uname -r tells you what’s running, not what’s installed. A server can have a new kernel on disk and still run the old one until it reboots. That gap is the first thing to check.
| Distro | List pending updates | Apply updates | Reboot needed? | Live patches loaded |
|---|---|---|---|---|
| Ubuntu | apt list --upgradeable |
sudo apt update && sudo apt upgrade |
ls /var/run/reboot-required |
canonical-livepatch status --verbose |
| Debian | apt list --upgradeable |
sudo apt update && sudo apt upgrade |
sudo needrestart -k |
Not covered here |
| RHEL 9 | dnf updateinfo list updates security |
sudo dnf upgrade --security |
dnf needs-restarting -r |
sudo kpatch list |
| Amazon Linux 2023 | sudo dnf updateinfo list |
sudo dnf upgrade --security |
Compare uname -r with sudo dnf list kernel |
sudo kpatch list |
On RHEL, needs-restarting -r exits with 1 when a reboot is required and 0 when it isn’t, so you can script it across a fleet. On Debian, needrestart -k checks for an obsolete kernel.
Live patching helps, with limits:
- It doesn’t cover everything. AWS provides live patches on a best-effort basis and says some fixes ship only in the full kernel package.
uname -rwon’t change. The version only moves after a reboot, so check live patch status directly.- Ubuntu’s reboot marker can disappear. Livepatch can remove the reboot notice when it covers the CVEs fixed by the next-boot kernel.
canonical-livepatch status --verboseshows the applied CVEs.
Treat live patches as a bridge to the next reboot, and shorten your reboot cycle.
Containers share the host kernel
A container is not a separate kernel. Run uname -r inside your API container and you’ll see the host’s version. Updating your base image doesn’t touch it, so a kernel bug reachable from inside the container is a route to the host.
For a Kubernetes fleet, one command shows every node’s kernel in the KERNEL-VERSION column:
kubectl get nodes -o wide
This path has been walked before. In a separate incident, SecurityWeek reported that OpenAI agents exploited a known kernel flaw, CVE-2026-53362, and reached root on an underlying worker node from inside a container, within OpenAI’s own environment. That bug is not one of the 948.
OpenAI names two isolation options for limiting the blast radius:
| Option | How it isolates | Good fit |
|---|---|---|
| gVisor | A userspace application kernel handles the container’s system calls instead of passing them to the host kernel | Containers that run untrusted code or parse risky input |
| Firecracker | Runs workloads in lightweight microVMs on KVM, with hardware-level isolation | Multi-tenant services and per-customer workloads |
In Kubernetes, you select a sandboxed runtime per pod with RuntimeClass. Set runtimeClassName on your riskiest workloads first, such as anything that runs customer code.
Patch these layers too. OpenAI says its own infrastructure testing led it to disclose and patch vulnerabilities in Kata, Moby/Docker, gVisor and other projects. A sandbox limits the damage, but it’s still software.
Reduce what a foothold reaches
Assume root on one host is possible. Then decide what root on that host can reach.
- Split shared service accounts. Give each service its own identity, so one stolen credential doesn’t open every system. Our guide to least-privilege API keys for agents applies to services too.
- Remove tokens a workload doesn’t need. In Kubernetes, set
automountServiceAccountToken: falseon pods that never call the Kubernetes API. - Keep long-lived secrets off the node. Root can read environment variables and mounted files, so favor short-lived credentials.
- Rotate after any foothold. If you find code execution on a host, treat every secret on that host as exposed. A clean-looking account doesn’t prove the machine wasn’t rooted.
Then audit the rest with an API security testing checklist, because every bug you close there is one less foothold.
Let your coding agent check the API after you patch
The real blocker to frequent kernel updates is fear of the reboot. A regression test run before and after takes that fear away. Have your coding agent run the same Apidog CLI test suite on both sides of the update, then compare the results.
Set it up once:
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
Then give your agent one prompt:
Find my API regression suite in Apidog project <id> and run it against the
staging environment. Save the reports to reports/before. Stop and wait while
I update the kernel and reboot. When I say done, run the same suite to
reports/after, compare both reports, and list every request whose status or
assertion result changed.
The agent runs these commands:
apidog test-suite list --project <id>
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/before
# you update the kernel and reboot
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/after
Start with staging, then repeat on one production node before you roll across the fleet. A changed request tells you where to look before more nodes go down.
The agent’s report needs the same care as OpenAI’s pipeline. In an early run, 20 of 200 reported exploits got root through a different 0-day than the one assigned, so OpenAI added an independent check. Verify the path to a result, not only the result: confirm with uname -r or your live patch tool that the update landed before you trust the “after” report.
The same -r junit run fits in CI. See the Apidog CLI CI/CD guide, the apidog run reference and our primer on API regression testing. Apidog’s Free plan covers up to 4 users.
What to watch next
- Your distro’s security advisories. More fixes will arrive as OpenAI and its partners send reports, so expect a steady stream, not a single release.
- Faster exploit development. OpenAI believes that within a few years, even less capable models may develop exploits once bugs are disclosed.
FAQ
Are the 948 Linux exploits remote? No. They are local privilege escalation exploits, so an attacker must already run code as a low-privileged user. A remote bug in your application can supply that foothold, which is why API teams should care.
Is my kernel version affected? OpenAI publishes no affected-version list, so nobody can give you a safe version number. Install your distro’s latest security updates and reboot into that kernel.
Are these bugs being exploited in the wild? OpenAI’s post doesn’t report attacks using these 948 bugs. Many are still moving through disclosure and patching. Patch now anyway, because public fixes can tell attackers where to look.
Does live patching replace rebooting? No. Live patches cover selected fixes, and vendors state that some fixes ship only in the full kernel package. Use them to buy time until your next reboot.
Does updating my container image fix a kernel bug? No. Containers use the host kernel, so you need to update and reboot the host or node. Update your images too, because they carry your application’s dependencies.
