THREATNOIR
Subscribe
Rapid alert3 min read

OpenAI's AI pipeline built 948 working Linux kernel root exploits in one run: what admins should do now

OpenAI says an autonomous pipeline on an unreleased cyber model produced 1,169 working local root exploits for 948 unique Linux kernel flaws in a mid-October run. Patches are landing upstream in stages. Treat any unpatched box as root-exposed and update now.

Marcus Lenngren
Marcus Lenngren
Founder, ThreatNoir
Share this alert LinkedIn X Bluesky Reddit Email

Linux Kernel LPEs rapid alert: Running an unpatched Linux box? A normal user account is now root.
The rapid alert card: save it and share it with your team

What happened

OpenAI's Cyber team ran an autonomous pipeline, powered by an unreleased cyber model, against the latest Linux kernel in mid-October 2026. In a single run it produced 1,169 working local privilege escalation (LPE) exploits and 291 proofs of concept for information leaks. After grouping exploits that traced back to the same flaw, OpenAI counted 948 unique vulnerabilities and wrote a patch for each. The run cost $1,213,430 in API credits, about $1,279 per exploit.

The target machines ran a stock desktop Linux from a commonly used distribution, with normal protections turned on: KASLR, SMEP, SMAP and HARDENED_USERCOPY. These are not exotic lab bugs. They are flaws reachable by an ordinary low-privileged user that let that user become root.

OpenAI says the agents used at least 10 exploitation techniques that were new to the researchers and to outside kernel exploitation experts. The full technical details are being withheld for safety reasons.

The blunt takeaway, in OpenAI's own words: for the near and medium term, a low-privileged account on a system that is not up to date on its patches should be treated as functionally equivalent to root for a well-resourced attacker.

Timeline

  • Late July 2026: an earlier run (GPT-5.6 Sol) found 166 unique LPEs for $513,690.
  • Mid-October 2026: the new pipeline scans the kernel master branch.
  • Within 12 hours: analyst agents produce 2,308 candidate bugs from about 7% of the code base.
  • Within 30 hours: triage agents reproduce 1,724 of them (about 74.7%) in isolated VMs.
  • Exploit agents produce 291 info-leak PoCs and 1,169 working root exploits.
  • Within 10 days: 61 bugs patched upstream, 43 with staging patches, 299 being discussed publicly.
  • 5 November 2026: research published.

Am I affected?

If you run Linux and allow any local or interactive access by non-root users, assume yes until patched. This covers:

  • Multi-user servers and shared hosts.
  • Containers and build runners where a process can reach kernel syscalls.
  • Cloud instances, developer workstations and anything running an unmodified distribution kernel.

The exploits worked against a kernel with standard hardening enabled, so KASLR and SMEP alone do not protect you. A hardened kernelCTF setup still yielded 21 LPE exploits over 112 hours.

What to do now

  1. Inventory kernel versions across your fleet. Run uname -r and compare against your distribution's current security update.
  2. Apply the latest kernel and distribution security updates tonight. Patches for the most serious flaws are already landing upstream; your distro will pick them up in stages.
  3. Reboot into the new kernel. A patched package on disk does not protect a running old kernel. Use live patching only as a stopgap.
  4. Restrict unprivileged user namespaces where your workload allows it (for example by setting kernel.unprivileged_userns_clone=0 on distributions that support it). This cuts common LPE attack surface.
  5. Put strong isolation around untrusted or multi-tenant workloads. OpenAI points to sandboxing such as Firecracker and gVisor to limit blast radius when a flaw is exploited.
  6. Tighten local access: remove unused local accounts, review who can run code on shared hosts, and prioritise patching on boxes where low-privileged users exist.

How to hunt

  • Confirm the running kernel matches the patched package: compare uname -r with the installed kernel package version.
  • On Debian and Ubuntu, use needrestart -k or checkrestart to find hosts running an old kernel after an update.
  • Audit for untrusted local access: list interactive accounts and review sudo and namespace configuration.
  • Watch for unexpected privilege changes, new root processes spawned from low-privileged sessions, and crashes consistent with kernel exploitation attempts.

What does not help

  • Relying on KASLR, SMEP, SMAP or HARDENED_USERCOPY alone: the exploits were built with these enabled.
  • Assuming a non-root account is safe: on an unpatched kernel it is now a path to root.
  • Treating a downloaded patch as protection without rebooting into the new kernel.

Sources

Pass this alert on LinkedIn X Bluesky Reddit Email

Drafted with the help of AI, then checked, edited and approved by Marcus Lenngren, who takes editorial responsibility for it.

More from us