A newly disclosed Linux kernel flaw nicknamed Fragnesia — tracked as CVE-2026-46300 — lets any unprivileged local user gain root on essentially every major Linux distribution shipped before May 13, 2026, and a working public exploit has been sitting on GitHub since the day of disclosure. Today, NSFOCUS CERT issued an emergency advisory on the bug, joining writeups from Microsoft, Wiz, Tenable, AlmaLinux, CloudLinux, and Fedora that all reach the same conclusion: anyone running a Linux server where untrusted users can run code is one short command away from a full host compromise.
The timing is awkward. Today, May 15, is also the CISA Binding Operational Directive 22-01 deadline for U.S. federal civilian agencies to remediate Copy Fail (CVE-2026-31431), the related Linux kernel root bug CISA added to its Known Exploited Vulnerabilities catalog on May 1. Many agencies finishing that patch cycle today will discover they need to repeat the process for Fragnesia — and so will anyone running a multi-tenant Kubernetes cluster, a shared CI runner, a bastion host, or a developer workstation that other people can log into.
The bug lives in the same XFRM ESP-in-TCP code that produced Dirty Frag — and the Dirty Frag fix created it
Fragnesia sits in the Linux kernel's XFRM ESP-in-TCP subsystem, the same broad attack surface as Dirty Frag (CVE-2026-43284 and CVE-2026-43500), disclosed on May 7. According to Tenable's Research Special Operations team, the root cause is a logic error in the core socket-buffer code: skb_try_coalesce() fails to propagate the SKBFL_SHARED_FRAG marker when transferring paged fragments between buffers. The kernel forgets a fragment was backed by external memory — for example, page-cache pages spliced in from a file on disk — and the XFRM ESP-in-TCP receive path then performs in-place AES-GCM decryption directly over those page-cache pages.
By controlling the initialization vector values fed into that decryption, an unprivileged attacker turns the operation into a deterministic one-byte write into the page-cache copy of any file the user can read. The published proof-of-concept, written by researcher William Bowling of Zellic and the V12 security team — with help from Zellic's AI-agentic code-auditing tool — overwrites the cached copy of /usr/bin/su with a small ELF stub. The next time anyone runs su, it executes attacker code as root. The on-disk binary is never touched.
Dirty Frag's discoverer says the patch that fixed his bug accidentally activated this one
The most uncomfortable detail in the disclosure is who is on record about it. Hyunwoo Kim, the researcher who reported the original Dirty Frag vulnerabilities, has publicly acknowledged that Fragnesia "emerged as an unintended side effect" of one of the patches written to fix his own bug — specifically the commit closing CVE-2026-43284. The follow-up Fragnesia patch series submitted by Bowling explicitly cites the Dirty Frag fix as one of the commits it now has to repair.
That is the second time in three weeks the Linux kernel community has shipped a same-area regression. Copy Fail, disclosed April 29, was traced by Theori to a 2017 in-place optimization that had sat in the kernel for nine years before researchers found it with an AI-assisted scanning tool called Xint Code. Fragnesia was found, less than three weeks later, by another security team using another AI-assisted auditing tool, in code that maintainers had just finished patching.
Independent observers have not been gentle about the pattern. The Register summarized the situation as Linux admins "hoping Dirty Frag was a one-off horror from the kernel networking stack" being about to have "a considerably worse week." Phoronix noted that the upstream fix for Fragnesia is a two-line patch to skbuff.c — meaning the underlying mistake was both small and long-lived.
Multi-tenant cloud, CI runners, and bastion hosts turn "local" into effectively remote root
The CVSS score of 7.8 (High) and the "Attack Vector: Local" label can make Fragnesia look like a flaw to schedule for next month's maintenance window. That framing collapses in the environments where modern Linux actually runs. A successful exploit inside an unprivileged container is effectively a container escape to root on the worker node, because page-cache memory is shared between containers and host. Microsoft's threat intelligence team warned of exactly that pattern when Copy Fail was disclosed, calling out cross-container impacts and "millions of Kubernetes clusters" as the affected scope.
Shared CI runners — Jenkins workers, GitHub Actions self-hosted runners, GitLab runners — are equally exposed. Any developer who can land a job description on the runner can land local code execution, and local code execution plus Fragnesia equals root on the runner along with every secret the runner has ever touched. Bastion hosts and jump servers, which exist specifically to host many low-privileged user shells, face the same exposure. Microsoft's Defender team has separately noted that the exploit "is not constrained to use the [/usr/bin/su] binary," and that attackers "can modify any file readable by the user, including [/etc/passwd]."
What separates Fragnesia from a typical kernel local privilege escalation is the absence of a race condition. There is no timing window to lose, no fingerprint of the running kernel to get right, no offset table to maintain. Tenable confirmed the exploit working on Ubuntu 6.8.0-111-generic on a Linode VPS. The exploit, in Tenable's words, "just works" — which is exactly the kind of property that ends up bolted onto an automated exploitation kit within days of a public proof-of-concept dropping.
AlmaLinux, CloudLinux, and Fedora have shipped patches; Red Hat, Ubuntu, Debian, and SUSE have not
Patch availability splits cleanly along community-distribution lines. AlmaLinux published patched kernels in its almalinux-testing repo for AL8, AL9, and AL10 on May 13, then rebuilt them on May 14 to pick up two follow-up upstream patches that landed on netdev. CloudLinux has patches in build and test on top of the AlmaLinux fix, with KernelCare livepatches under validation. Fedora 42 shipped kernel-6.19.14-102.fc42 on May 13 carrying the fix.
Red Hat Enterprise Linux, Ubuntu, Debian, and SUSE advisories remain pending at time of publication. Tenable lists Ubuntu's patch status as "needs evaluation" across all releases. The AlmaLinux team made the unusual public decision, attributed to its ALESCo technical steering committee, to ship patched kernels ahead of any CentOS Stream or RHEL update — citing the trivial exploitability and the fact that this is now the third local-root vulnerability in this code area in under two weeks.
The patch series itself is unusually large for a single CVE. Beyond the core repair to skb_try_coalesce, it includes a propagation fix in pskb_copy(), an XFRM change to avoid in-place decrypt on shared skb fragments, and a cluster of follow-up fixes to rxrpc covering DATA and RESPONSE packet unsharing, re-decryption of RESPONSE packets, rxkad alignment, memory leaks in rxkad_verify_response(), and a potential use-after-free following skb_unshare() failure. In other words: the same shared-fragment mistake had ripples across multiple modules in the same neighborhood of code.
Administrators who cannot wait for vendor packages can unload the affected modules today
For administrators waiting on vendor kernels, the temporary mitigation is identical to the one already deployed for Dirty Frag: unload and blacklist the affected modules. Both Wiz and CloudLinux recommend the same sequence.
Organizations that applied the module-blacklist route for Dirty Frag are already covered. Organizations that applied only the Dirty Frag kernel patch and skipped the blacklist need to act today, because the Dirty Frag kernel patches do not fix Fragnesia; a separate patch is required.
CloudLinux and the Help Net Security writeup both stress one additional step that is easy to skip: because Fragnesia corrupts only the in-memory page cache, mitigation alone leaves any poisoned cached binaries in place. After unloading the modules, drop the page cache to force a reload from disk.
That evicts and reloads cached pages, which is what you want if there is any chance the host was targeted before the mitigation went in. It does not undo persistence an attacker may have already established. Any confirmed exploitation should be treated as a full host compromise — flushing the cache is hygiene, not remediation.
For container and cloud environments, NSFOCUS recommends two additional hardening steps: use Seccomp to prevent unprivileged processes from creating AF_ALG sockets, and intercept unprivileged user-namespace creation, which is the mechanism the exploit uses to obtain CAP_NET_ADMIN inside an unprivileged sandbox. Monitoring /etc/passwd, /etc/sudoers, /etc/shadow, and /usr/bin/su for tampering — and restricting splice, add_key, and unshare for ordinary users — is a reasonable addition on sensitive hosts.
Three high-severity kernel root bugs in the same code area in three weeks suggests a fourth is likely
Fragnesia is not currently in CISA's Known Exploited Vulnerabilities catalog and no in-the-wild exploitation has been confirmed. Microsoft has, however, noted that its existing Trojan:Linux/DirtyFrag detections also cover the public Fragnesia exploit, and Microsoft reported on May 8 that limited in-the-wild activity consistent with either Dirty Frag or Copy Fail had already been observed. Given the trajectory of Copy Fail — disclosed April 29, added to KEV on May 1 once exploitation was observed — a similar progression for Fragnesia is plausible if any signal of weaponization appears.
The underlying problem is structural. Three high-severity local-root vulnerabilities in the same XFRM, ESP, and rxrpc neighborhood in three weeks — one of them caused by the fix for another — is not a great look for an attack surface that lives on essentially every server-class Linux host on the internet. The Fragnesia patch series is large precisely because the underlying mistake had echoes across multiple subsystems. It would be unsurprising to see a fourth advisory in this same area before the month is out.
For anyone running Linux servers that other people can reach a shell on: blacklist the modules, drop the page cache, watch the security mailing list of the distribution being run, and assume that until a patched kernel is installed and rebooted into, any unprivileged user with the ability to run code on the host is one command away from root.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
