Fragnesia Linux Kernel Flaw Gives Local Attackers a Public Path to Root
SH
Samir Haddad Vulnerability analyst · Updated May 17, 2026, 10:15 AM EDT
Fragnesia, tracked as CVE-2026-46300, is a Linux kernel local privilege escalation flaw involving ESP/IPsec page-cache corruption, with public proof-of-concept code increasing patch urgency.
A newly disclosed Linux kernel vulnerability known as Fragnesia and tracked as CVE-2026-46300 can let a local attacker gain root privileges by corrupting page-cache-backed file contents on vulnerable systems. The flaw, publicly disclosed on May 13, 2026, already has proof-of-concept exploit code available, raising urgency for Linux administrators to apply kernel updates or block the affected ESP/IPsec modules.
Fragnesia is a local privilege escalation vulnerability, not a remote-code-execution bug. An attacker must already be able to run code on the target system, such as through a local shell account, compromised service account, CI runner, shared application user or untrusted workload. Once that foothold exists, the vulnerability can allow the attacker to alter what the kernel serves from memory for read-only files and use that condition to obtain root access.
The flaw sits in the Linux kernel’s XFRM ESP-in-TCP and related ESP/IPsec handling paths. ESP, or Encapsulating Security Protocol, is part of IPsec and is commonly used by VPN and tunnel deployments. The vulnerable behavior involves how the kernel handles socket-buffer fragments that are backed by the page cache — the in-memory cache Linux uses to speed access to file contents.
The most alarming detail is reliability. Fragnesia has been described as deterministic and race-free, meaning exploitation does not depend on winning a fragile timing race. That makes it more operationally useful to attackers than many kernel privilege-escalation bugs that work only intermittently.
At a high level, the attack abuses a situation where the kernel loses track of whether packet fragments are shared with page-cache-backed file memory. The ESP path can then perform an in-place operation on memory it should not modify, corrupting the cached version of a file while leaving the file on disk unchanged. Public analysis describes demonstrations against privileged binaries such as /usr/bin/su, where modified cached bytes can cause a later execution to spawn a root shell.
B
Kernel mishandles page-cache-backed fragments
Cached file contents are corrupted
Privileged binary executes modified cached bytes
Root privileges
Local attacker runs code] --> B[Triggers vulnerable ESP/IPsec path
That page-cache distinction matters for defenders. Fragnesia does not necessarily overwrite the file stored on disk. A file-integrity check that reads the persistent file after cache eviction may show the original binary, while the version executed from memory may have been altered. A reboot or cache drop can clear the modified in-memory state, but that does not remove the need to patch or mitigate the vulnerable kernel path.
Fragnesia follows a string of recent Linux kernel page-cache corruption issues, including Copy Fail and Dirty Frag. It is related to the same broad vulnerability class as Dirty Frag, but it should not be treated as the identical bug. Dirty Frag mitigations that block the relevant ESP modules may also reduce Fragnesia exposure, but prior patching for Dirty Frag should not be assumed to fix Fragnesia unless the installed kernel specifically includes the newer fixes.
The disclosure also moved quickly. Public proof-of-concept code appeared around the same time as upstream patch work, giving defenders little lead time. Some vendor material initially said no CVE had yet been published, while later reporting and advisories identified the flaw as CVE-2026-46300. That appears to reflect disclosure-timing lag rather than disagreement over the bug itself.
There is no confirmed evidence, at publication time, that Fragnesia has been exploited in the wild. But public exploit availability changes the risk calculation. Systems that allow local users, run untrusted workloads, host shared build environments or expose containerized workloads should be treated as high priority for mitigation until patched.
Reproducing the Risk Without Publishing an Exploit
Administrators should not validate exposure by running public exploit code on production systems. The safer approach is to confirm whether the vulnerable attack surface is present, whether mitigations are active and whether a patched kernel has been installed.
The exploit prerequisites are broadly understood:
The attacker needs local code execution.
The vulnerable kernel must expose the relevant ESP/IPsec path.
The system must not already have effective mitigations blocking esp4 and esp6.
Some exploit paths rely on namespace capabilities available to unprivileged users.
Public demonstrations show page-cache corruption leading to root escalation.
A practical exposure check starts with the running kernel and module state:
If esp4 or esp6 is loaded and the system has not received a Fragnesia-aware kernel update, the host should be considered exposed if local users or untrusted workloads can execute code.
Administrators can also check whether module-blocking rules already exist:
No output means the common ESP-blocking mitigation is probably not in place.
How to Fix Fragnesia
The preferred fix is straightforward: install the vendor-supplied kernel update that includes the Fragnesia patches, then reboot into the updated kernel. Patch availability varies by distribution, release stream and support tier, so administrators should verify the exact fixed kernel version for their environment rather than assuming that any routine kernel update is sufficient.
Where a fixed kernel is not yet available, the main short-term mitigation is to block the affected ESP modules:
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/fragnesia.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/fragnesia.conf
On systems that use initramfs, administrators should regenerate it so the module block applies early in boot. On Ubuntu-style systems, that typically means:
sudo update-initramfs -u -k all
Then unload the modules if they are already present:
sudo rmmod esp4 esp6 2>/dev/null
Confirm they are not loaded:
grep -qE '^(esp4|esp6) ' /proc/modules \
&& echo "Affected modules are loaded" \
|| echo "Affected modules are NOT loaded"
If the modules cannot be unloaded because they are in use, a reboot is usually required:
sudo reboot
This workaround has a significant trade-off: blocking esp4 and esp6 can break IPsec VPNs and tunnels, including deployments that rely on common IPsec stacks. Production teams should identify VPN gateways, tunnel endpoints and hosts using kernel IPsec before applying the mitigation across a fleet.
For systems that must keep kernel IPsec available, reducing namespace exposure may be an alternative hardening measure. Disabling unprivileged network namespaces can block some exploit paths, but it may also break rootless containers, sandboxed browsers and desktop application isolation.
That setting should be tested carefully before broad deployment.
Incident Response Considerations
If exploitation is suspected, responders should remember that Fragnesia can modify cached file contents without changing the on-disk file. A simple reboot clears the page cache and is often the cleanest immediate containment step, though it does not fix the underlying vulnerability.
Where a reboot is not immediately possible, administrators can compare file hashes before and after dropping caches:
If the hashes differ, the cached version of the binary may have been altered. Responders should preserve evidence before taking destructive actions where forensic requirements apply.
Fragnesia is not a wormable internet bug, but it is a serious post-compromise escalation primitive. In shared Linux environments, CI/CD infrastructure, container hosts and multi-user servers, the difference between a low-privilege foothold and root access can be decisive. Until patched kernels are widely deployed, defenders should treat exposed systems as publicly exploitable and prioritize mitigation wherever untrusted code can run.
