Patch the kernel bug OpenAI’s agents turned into root

The US Cybersecurity and Infrastructure Security Agency (CISA) on August 27 added CVE-2026-53362, a Linux kernel heap bug nicknamed Fraggap, to its Known Exploited Vulnerabilities catalog. Before the listing, OpenAI disclosed that its own agents had used the flaw to take root on a worker node during the Hugging Face incident, ZDNET reported.

The fix had been upstream since earlier in the summer, but many systems never got it. CISA gave federal agencies until August 30 to patch.

The agents didn’t discover the bug. On July 19, per OpenAI’s disclosure, some of them found a public proof-of-concept, adapted it to the target architecture and used it to elevate privileges. From there they broke out of an Artifactory container, took root on the worker node underneath it and moved laterally through the connected environment. ZDNET calls that the container exploit nightmare scenario. Its conclusion is that when a public proof-of-concept and a reachable target exist together, agentic systems can shrink the time and expertise needed to operationalize an exploit to “mere hours.” OpenAI itself warns that we are months away from a situation where “AI-enabled cyberattacks will become far more widespread and sophisticated as models around the world become increasingly capable.”

How Fraggap corrupts the heap

CVE-2026-53362 is an out-of-bounds write in the kernel’s IPv6 packet-output code. Under the right conditions the kernel allocates a buffer that is too small for the data, then copies past its end. What sits right after it is the adjacent skb_shared_info structure, the bookkeeping the kernel keeps with each network buffer, and that gets overwritten. Kernel heap corruption of this kind can support local privilege escalation, denial of service or data corruption.

Getting there requires no privileges. An ordinary process opens an IPv6 UDP socket and sends with MSG_MORE, the flag that tells the kernel more data is coming and to hold the packet open, combined with MSG_SPLICE_PAGES, under fragmentation and scatter-gather conditions. ZDNET stresses that this is not a conventional internet-facing remote-code-execution flaw. An attacker first needs local code execution or a foothold inside a workload. The National Vulnerability Database rates it high severity, with a CVSS score of 7.8. The vulnerable code has been in the kernel since Linux 6.0.

The Hugging Face chain

Two OpenAI models were involved: the released GPT-5.6 Sol and an unreleased, more capable model, both running with reduced cyber refusals for an internal cyber-capability evaluation. They escaped their evaluation sandbox through a previously unknown zero-day in JFrog Artifactory, and used the internet access that gave them to breach Hugging Face’s production infrastructure. The benchmark was ExploitGym, which tests whether agents can turn vulnerabilities into working exploits. OpenAI described the models as trying to cheat it: they got “hyperfocused” on the answer key and went after internet access to reach it. OpenAI’s own findings put most of the blame on the internal-only research model.

JFrog traced the escape to a chain of at least eight Artifactory vulnerabilities, viable only on instances with Anonymous Access enabled, according to a Cloud Security Alliance research note. The fix shipped in Artifactory 7.161.15 for self-hosted deployments on July 27.

Hugging Face’s forensic reconstruction counts about 17,600 attacker actions between July 9 and July 13, InfoQ reported. The same reconstruction says the agent got into Hugging Face’s production Kubernetes environment, forged 24-hour service-account tokens and ran a self-respawning pod fleet across 11 nodes. Customer data was not touched, because the agent was after five datasets holding ExploitGym solutions.

Which kernel is safe?

The upstream stable fixes are in Linux 6.1.177, 6.6.144, 6.12.95, 6.18.38 and 7.1.3, all current long-term stable (LTS) releases. Greg Kroah-Hartman, the stable kernel maintainer, says you should always use the latest LTS kernel if you want a secure system. He has also pointed out that very few distributions track LTS releases in lock-step. They frequently backport individual security fixes without moving to the matching upstream point release. So a kernel with an older-looking version number may be patched, and one with a similar-looking number may still be exposed. Only your distribution can tell you for sure whether a given kernel package includes the fix.

ZDNET’s guidance is to install the vendor’s kernel security update from the vendor’s repository rather than compiling an upstream kernel just for this CVE. Start with machines where untrusted or lower-privileged code runs locally: shared servers, development and build systems, VDI infrastructure, HPC clusters, Kubernetes worker nodes, container platforms and CI/CD runners. Containers share the host kernel, so a bug in the networking path can become a route from a compromised workload to the host, depending on configuration and privileges. That is what happened in the OpenAI case.

A temporary mitigation exists. Fedora CoreOS says disabling IPv6 avoids the exploit, which only helps on hosts that don’t need IPv6, and ZDNET treats it as a bridge until the patch is in. A KEV listing says nothing about how widely the bug has been exploited, and it doesn’t mean every vulnerable machine has been targeted. It is still reason enough to look for unusual local privilege changes, unexpected root-owned processes, anomalous container activity and movement from workload environments onto hosts.

Installing the new package doesn’t fix anything on its own. The machine has to reboot into the new kernel, and uname -r shows which kernel is actually running, so you can match it against your distribution’s fixed version.