We recognize that if you have been following this week's advisories, you may already be tired of reading about Linux privilege escalation vulnerabilities. We are going to ask you to read one more.
A third Linux kernel local privilege escalation vulnerability was publicly disclosed on May 13, 2026, less than a week after Dirty Frag and less than two weeks after Copy Fail. It is called Fragnesia, tracked as CVE-2026-46300, and it carries a working public proof-of-concept. It is a distinct bug from Dirty Frag; it's a new logic flaw in the same general kernel subsystem, found by a different research team, and it requires its own patch.
The good news, and there is genuine good news here, is that if your team applied the mitigation for Dirty Frag from our article regarding that vulnerability, your systems are already covered against Fragnesia as well. The module blocklist that stops Dirty Frag stops Fragnesia too. You don't need to take emergency action tonight. You do, however, need to patch; this article will walk you through what that looks like and why the pattern of three vulnerabilities in three weeks is worth thinking about carefully.
A quick note on how this one became public
Fragnesia followed a coordinated disclosure process. Researcher William Bowling of the V12 security team discovered the vulnerability and submitted it through proper channels. Unlike Dirty Frag, there was no embargo breach; the disclosure was deliberate, organized, and accompanied by patches submitted to the upstream kernel maintainers on the same day.
A public proof-of-concept was released by the V12 team alongside the disclosure, consistent with responsible full disclosure practice after notification has been completed. Patched kernels were available in testing repositories from most major distributions within hours of the advisory going out.
This matters for your planning because the situation is more orderly than it may appear from the outside; there was a coordinated process, there is a clear patch, and the mitigation that many organizations are already running provides interim protection.
What is Fragnesia?
Fragnesia is a (yet another) Local Privilege Escalation (LPE) vulnerability, the same class as Copy Fail and Dirty Frag before it. Like both of those, it allows any unprivileged user already present on a Linux system to elevate their access to full root in a single command. A working public exploit demonstrates this against all major distributions.
It is tracked as CVE-2026-46300, with a CVSS score of 7.8, and was discovered by researcher William Bowling of the V12 security team. The technical mechanism sits in the kernel's ESP-in-TCP path, specifically in the espintcp ULP (Upper Layer Protocol). When a TCP socket transitions into espintcp ULP mode after data has already been spliced from a file into the receive queue via splice(2) or sendfile(2), the kernel incorrectly treats those queued file pages as ESP ciphertext and decrypts them in place. The AES-GCM keystream is XORed into cached file pages, and by controlling the initialization vector nonce, an unprivileged process can turn this into a one-byte arbitrary write into the kernel page cache of any readable file, but once per trigger invocation. No race condition is required. The write is deterministic.
The public PoC uses this primitive to overwrite the in-memory copy of /usr/bin/su in the page cache, replacing it with a 192-byte root-shell stub, while the file on disk remains completely untouched. The next invocation of su runs the stub as root.
The name Fragnesia places it in the same lineage as Dirty Pipe and its successors: a page-cache write primitive, different mechanism, same devastating result.
How does Fragnesia relate to Copy Fail and Dirty Frag?
This is the question your team will no doubt be asking, and here's the answer.
Fragnesia is a separate bug. It is not a variant or re-announcement of Dirty Frag, and it is not covered by the Dirty Frag kernel patch. It requires its own fix. The V12 team was explicit on this point in their disclosure, stating "This is a separate bug in the ESP/XFRM from Dirty Frag which has received its own patch. However, it is in the same surface and the mitigation is the same."
What Fragnesia shares with its predecessors is the attack class, a page-cache write primitive that operates on in-memory file representations without touching on-disk data, as well as the affected kernel subsystem, the XFRM ESP networking stack. Copy Fail used algif_aead. Dirty Frag used the esp4, esp6, and rxrpc modules. Fragnesia uses the espintcp ULP within the same XFRM stack. Each vulnerability represents a separate logic flaw, found independently, that happens to produce the same type of exploit.
There is an important practical consequence of this shared mitigation surface: the module blocklist applied for Dirty Frag covers Fragnesia as well. Blocking esp4 and esp6 prevents the vulnerable code path from being reachable. Organizations that applied the Dirty Frag mitigation don't need to take additional emergency action for Fragnesia as the existing mitigation holds until patched kernels are deployed.
Three in three weeks: what this pattern means
We want to mention what it means that Copy Fail, Dirty Frag, and Fragnesia have all emerged within the span of three weeks.
This is not a coordinated attack campaign. These are independent researchers, working independently, discovering vulnerabilities in overlapping areas of the Linux kernel's networking subsystem. The proximity in time reflects a confluence of factors: the page-cache write primitive class was established as a research direction by earlier work on Dirty Pipe and multiple research teams have been following that thread simultaneously. When one vulnerability surfaces and demonstrates that a class of attack is feasible, it tends to accelerate discovery of others in the same neighborhood.
What this pattern suggests, practically, is that the XFRM/ESP subsystem of the Linux kernel has been under unusually concentrated scrutiny, and that scrutiny has been productive. It's reasonable to expect additional findings in this area before the research community moves on. The appropriate response is not alarm but preparation: organizations that have patched promptly and applied effective mitigations are well-positioned regardless of what comes next.
It also makes the question of patching cadence worth raising with your team. Fragnesia is the third Linux kernel security update requiring a reboot in three weeks. If that pace is creating operational friction (think maintenance windows, service disruption, coordination overhead) live-patching solutions that apply kernel security fixes to running systems without a reboot are worth evaluating seriously.
Who is affected?
Fragnesia affects Linux kernels across all major distributions. The vulnerable code was introduced with the espintcp ULP feature and is present in kernels that include that subsystem.
Advisories have been issued by AlmaLinux, Amazon Linux, CloudLinux, Debian, Gentoo, Red Hat Enterprise Linux, SUSE, and Ubuntu. Red Hat has confirmed it is assessing whether existing mitigations cover the exposure; Wiz has noted that AppArmor restrictions on unprivileged user namespace creation may serve as a partial mitigating factor, though this does not eliminate the risk on affected systems.
As with Copy Fail and Dirty Frag, the same practical risk profile applies:
Web applications and external-facing services. Any system running web software with interactive functionality may already have other vulnerabilities that provide an attacker a foothold. Fragnesia converts that foothold into full root access.
Multi-tenant and container environments. The page-cache write primitive affects shared kernel memory. Organizations running shared hosting, multi-tenant platforms, or container workloads on shared hosts should treat this as urgent.
Compromised accounts and malicious insiders. Any user with basic shell access to a Linux system can execute this exploit in a single command to gain full administrator access.
CI/CD pipelines and build systems. Automated systems that pull and execute external code represent an execution surface where Fragnesia could be used as part of a supply-chain attack.
Additionally, security researchers have flagged activity from a threat actor advertising a zero-day Linux LPE exploit on cybercrime forums, claiming it works across multiple major distributions. The relationship between that advertised exploit and Fragnesia is unconfirmed, but the timing and the overlap in claimed capability are worth noting.
The same detection blind spot
Like Copy Fail and Dirty Frag, Fragnesia operates through the kernel's page cache, modifying in-memory representations of system binaries without touching their on-disk contents. File integrity monitoring would see nothing. File hashes would remain clean. On-disk data would be unchanged.
Detection requires monitoring at the syscall level. If your organization deployed detection rules for Copy Fail or Dirty Frag, review whether they need to be extended for the different espintcp syscall chain used by Fragnesia. Updated detection guidance will be published to our GitHub repository as it's developed.
What should you do?
1. Check whether the Dirty Frag mitigation is already in place
If your organization applied the Dirty Frag mitigations, the file at /etc/modprobe.d/dirtyfrag.conf should already exist and block esp4, esp6, and rxrpc. You can verify:
cat /etc/modprobe.d/dirtyfrag.conf
If the file exists and contains the three install ... /bin/false lines, your systems are protected against Fragnesia until a patched kernel is deployed. No further emergency action is needed.
If the mitigation has not been applied, apply it now:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
The same IPsec caveat from the Dirty Frag advisory applies: esp4 and esp6 are used by IPsec tunnels. Check whether they are in use before applying on hosts that terminate IPsec tunnels:
lsmod | grep -E 'esp4|esp6'
2. Drop the page cache
If there is any possibility that a system was targeted before the mitigation was in place, flush the page cache after applying the mitigation to force system binaries to reload from disk:
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
3. Patch your kernel
Patched kernels are available from most major distributions. Apply updates and reboot to load the patched kernel.
| Distribution | Update command |
|---|---|
| Ubuntu / Debian | sudo apt-get update && sudo apt-get upgrade |
| RHEL / Rocky / AlmaLinux | sudo dnf update kernel |
| Amazon Linux | sudo dnf update kernel |
| SUSE / openSUSE | sudo zypper update kernel-default |
| Arch Linux | sudo pacman -Syu |
For AlmaLinux 9 and 10 users, the target kernel versions incorporating the Fragnesia fix are kernel-5.14.0-611.54.5.el9_7 and kernel-6.12.0-124.56.3.el10_1 respectively, or newer. Note that earlier test builds (.54.4 and .56.2) were superseded after an additional exploit path was identified; if you installed a test kernel before May 15, update and reboot again to ensure full coverage.
CloudLinux customers should consult CloudLinux's advisory for stream-specific instructions, including KernelCare livepatch availability — livepatches covering the complete fix are available in the main feed as of May 15.
After updating, reboot to load the patched kernel, then verify:
uname -r
4. Remove the mitigation file after patching
Once a patched kernel is confirmed running, remove the module blocklist to restore normal IPsec and related module functionality:
sudo rm /etc/modprobe.d/dirtyfrag.conf
5. Review your detection coverage
Review whether existing detection rules for Copy Fail and Dirty Frag need to be extended to cover the different syscall chain used by Fragnesia. Detection rules and updated guidance will be published to our GitHub repository as they are developed.
A note on patch fatigue
Three significant Linux LPEs in three weeks is an unusual run. The operational reality is that each one requires a kernel update and a reboot, which means maintenance windows, service disruption coordination, and staff time...three times in three weeks. For organizations running large Linux environments, that cadence is genuinely disruptive.
We want to point this out directly because the response to patch fatigue, delaying or deferring updates, is exactly what makes the situation more dangerous, not less. The mitigations buy time. The patch is the resolution. Both things can be true at once: the pace is exhausting and the right answer is still to patch promptly.
For organizations for whom this cadence has become untenable, the right conversation to have is about live-patching infrastructure, not about whether to patch. KernelCare and similar solutions apply kernel security fixes to running servers without a reboot; that is worth evaluating if three emergency maintenance windows in three weeks have strained your operations.
The V12 security team's technical write-up is available at the Fragnesia PoC repository. Red Hat's security advisory is at access.redhat.com/security/cve/cve-2026-46300. The Amazon Linux security bulletin is at AWS Security Bulletin 2026-029.
Summary
| CVE | CVE-2026-46300 |
| Nickname | Fragnesia |
| CVSS Score | 7.8 |
| Type | Local Privilege Escalation (LPE) |
| Researcher | William Bowling, V12 security team |
| Affected | Linux kernels across all major distributions; vulnerable code present in kernels shipping the espintcp ULP |
| Exploit complexity | Trivial — single command, no race condition, deterministic |
| Dirty Frag mitigation covers this? | Yes — the existing esp4/esp6/rxrpc module blocklist also blocks Fragnesia |
| Immediate mitigation | Verify or apply module blocklist (see above); drop page cache |
| Full fix | Kernel update from your distribution vendor |
| Patch available? | Yes — from most major distributions as of May 15 |
If you need help verifying whether the Dirty Frag mitigation is correctly in place across your fleet, assessing your detection coverage for the full LPE trilogy, or thinking through a live-patching strategy for your Linux infrastructure, get in touch. Three Linux LPEs in three weeks is a signal worth taking seriously — and that broader conversation about your Linux security posture is exactly where CrowdSOC can help.