Fragnesia, tracked as CVE-2026-46300, has once again put the spotlight on a particularly sensitive area of the Linux kernel: networking paths related to XFRM, ESP and IPsec. For system administrators, the important point is not just the name of the vulnerability, but its practical impact: an unprivileged local user can obtain root if the system is vulnerable and has not been mitigated or patched.
The flaw was disclosed by William Bowling and the V12 Security team, only days after Dirty Frag and barely three weeks after Copy Fail. It is not a repeat of the same bug, although it belongs to the same technical family. CloudLinux treats it as a separate vulnerability, but recommends the same temporary mitigation already applied for Dirty Frag: block the esp4, esp6 and rxrpc modules if the server does not depend on them.
For those administering hosting servers, multi-user platforms, virtualization nodes, CI/CD runners or systems running untrusted workloads, Fragnesia requires priority review. It is not a remote vulnerability by itself, but once an attacker can execute local code, it can become a direct path to privilege escalation.
What happens in the kernel and why it matters
Fragnesia affects the ESP-in-TCP path in the kernel, specifically the espintcp ULP. The problem appears when a TCP socket switches into espintcp mode after file pages have already been inserted into the receive queue through calls such as splice(2) or sendfile(2). In that scenario, the kernel may treat cached file pages as encrypted ESP traffic and decrypt them in place.
The result is a controlled write into the page cache. The public PoC described by the researchers uses that primitive to alter the cached in-memory copy of /usr/bin/su and execute a small ELF stub with root privileges. The binary on disk is not necessarily modified, which makes superficial checks based only on persistent file checksums less useful.
This detail is key for administrators: if the exploit ran before mitigation was applied, blocking modules is not enough. The page cache must also be invalidated, or the system must be rebooted so legitimate binaries are reloaded from disk.
The sequence recalls Dirty Frag and Copy Fail because the common element is the abuse of paths that allow writes into cached pages that should not be writable by an unprivileged process. Administrators should not expect the exploit to be unreliable because of a race condition or fragile timing: published analyses describe a deterministic logic flaw, which is more dangerous in environments with local users, shells, containers or compromised processes.
Affected distributions and patch status
CloudLinux has confirmed that CloudLinux 7 is not affected, while CloudLinux 7h, 8, 9 and 10 are affected. For CL7h and CL8, CloudLinux kernels are being prepared; for CL9 and CL10, the fix depends on the AlmaLinux kernel. CloudLinux is also working on KernelCare livepatches to avoid reboots where available.
Red Hat has added Fragnesia to its RHSB-2026-003 bulletin alongside Dirty Frag. The company identifies three CVEs in the family: CVE-2026-43284 for the original IPsec ESP/XFRM issue, CVE-2026-43500 for RxRPC and CVE-2026-46300 for Fragnesia in the XFRM ESP-in-TCP subsystem. Red Hat confirms impact on RHEL 8, 9 and 10, as well as OpenShift 4.
Ubuntu already has a specific entry for ubuntu.com/security/CVE-2026-46300, with “High” priority and a description as a local privilege escalation in the kernel. As of 13/05/2026, many kernel variants are still listed as “Needs evaluation”, and Canonical points to the same Dirty Frag mitigation. Its earlier Dirty Frag advisory stated that all supported and extended Ubuntu releases, from 14.04 ESM to 26.04 LTS, were affected by the Dirty Frag CVEs.
For Debian, public information specific to CVE-2026-46300 does not appear as clearly in the tracker at the time of writing. That should not be interpreted as absence of risk. On Debian systems, Proxmox VE, derivatives or custom kernels, administrators should closely follow vendor advisories, check the installed kernel and apply mitigations if the system does not need IPsec/ESP or RxRPC.
| System | Known status as of 13/05/2026 |
|---|---|
| CloudLinux 7 | Not affected according to CloudLinux |
| CloudLinux 7h, 8, 9 and 10 | Affected; kernels and livepatches in preparation |
| RHEL 8, 9 and 10 | Affected according to Red Hat |
| OpenShift 4 | Affected according to Red Hat |
| Ubuntu | CVE published with High priority; multiple kernels under evaluation |
| AlmaLinux 9/10 | Relevant for CL9/CL10 and EL derivatives; follow vendor errata |
| Debian / Proxmox / derivatives | Review official advisories and treat as potentially exposed if running affected kernels |
Immediate mitigation for servers that do not use IPsec
The temporary mitigation is to prevent esp4, esp6 and rxrpc from loading, and to unload those modules if they are already present. On web servers, shared hosting systems or standard nodes that do not terminate IPsec tunnels or use AFS, this is usually a reasonable measure until a fixed kernel is installed.
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"Code language: JavaScript (javascript)On Ubuntu, Canonical also recommends regenerating initramfs to prevent the modules from loading during early boot:
sudo update-initramfs -u -k allTo check whether the modules are still loaded:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules loaded" || echo "Affected modules NOT loaded"Code language: PHP (php)If the modules cannot be unloaded because they are in use, a reboot will be required for the block to take effect. Before applying this mitigation in production, check dependencies: esp4 and esp6 are used by IPsec; blocking them may break strongSwan, Libreswan or site-to-site tunnels. rxrpc is mainly used with AFS, less common on hosting servers, but not impossible.
If exploitation before mitigation is suspected, clear the page cache after mitigating:
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"Code language: JavaScript (javascript)In critical environments, rebooting remains the cleanest option if cached binary manipulation is suspected. A vendor kernel patch or compatible livepatch is the definitive fix; module blocking is only temporary containment.
To remove the mitigation after installing a fixed kernel:
sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo update-initramfs -u -k all # Only on Debian/Ubuntu and derivatives if initramfs was regenerated earlierCode language: PHP (php)After updating, always verify the running kernel:
uname -rOn servers using KernelCare:
kcarectl --update
kcarectl --infoFor Linux administrators, the priority should be clear: identify systems with local users or untrusted workloads, check whether IPsec/ESP or RxRPC are required, apply mitigation where viable, schedule the kernel patch or livepatch and review indicators of compromise. In shared hosting, CI/CD and environments with third-party containers, this vulnerability deserves urgent treatment.
Fragnesia does not affect service availability by itself, but it can turn a limited account, a low-privilege shell or a compromised application into full host control. That is the difference between a contained incident and an intrusion affecting the entire server.
Frequently asked questions
What is Fragnesia?
Fragnesia is a local privilege escalation vulnerability in the Linux kernel, tracked as CVE-2026-46300. It affects the ESP-in-TCP path inside the XFRM subsystem and may allow an unprivileged local user to obtain root.
Is it the same as Dirty Frag?
No. It is a different flaw, although it belongs to the same technical family and shares the same temporary mitigation. Anyone who already blocked esp4, esp6 and rxrpc for Dirty Frag is also protected against Fragnesia until the final patch is applied.
Can the mitigation break services?
Yes. Blocking esp4 and esp6 breaks IPsec tunnels that depend on the kernel, such as strongSwan or Libreswan. Before applying it, check whether the server terminates or transits IPsec VPNs.
Do I need to reboot the server?
If you install a fixed kernel, yes, unless you use a compatible livepatching solution. If you only apply the mitigation and cannot unload the modules, you will also need to reboot. If previous exploitation is suspected, rebooting or clearing the page cache is recommended.