In recent weeks, the Linux world has been shaken by a new vulnerability that, for many administrators, has been the final straw in a string of critical kernel flaws. We're talking about Fragnesia, a local privilege escalation exploit which adds to the family of known failures Copy Fail y Dirty Frag, and that allows any unprivileged user to gain root access with a single command on vulnerable systems.
Following Copy Fail and Dirty Frag, Fragnesia arrives amidst genuine patch fatigue: urgent updates, chained reboots, and emergency mitigations. However, ignoring it is not an option. The vulnerability affects multiple Linux distributions and kernel versionsA fully functional public proof of concept already exists. In this article, we'll break down what Fragnesia is, how the attack works, which distributions are affected, what patches and mitigations exist, and how to check if your system is protected.
What is Fragnesia and why is it related to Dirty Frag and Copy Fail?
Fragnesia is a new local privilege escalation (LPE) exploit in the Linux kernel that falls under the same family of vulnerabilities as Copy Fail (CVE-2026-31431) and Dirty Frag (also known as Copy Fail 2, CVE-2026-43284). It shares with them the basic idea: exploiting logical flaws in the kernel's network stack and memory management to obtain a memory write primitive that allows modifying theoretically read-only files and ultimately executing code as root.
The ruling has been dubbed Fragnesia and tracked as CVE-2026-46300with a CVSS score of 7,8. The vulnerability was discovered by William Bowling of the V12 security team. Shortly after, Sam James announced the issue on the OSS Security mailing list, clarifying that it was not a simple re-analysis of Dirty Frag, but a different bug on the same functional surface of the kernel.
In practical terms, Fragnesia is the third critical failure of this type in just two weeksCopy Fail, Dirty Frag, and now Fragnesia. All three exploit kernel data handling problems to corrupt the page cache of critical files such as /usr/bin/suBut Fragnesia achieves this through another route: the ESP-in-TCP subsystem of XFRM.
Technical details: the XFRM ESP-in-TCP subsystem and the logic failure
The core of Fragnesia resides in a logic failure in the Linux XFRM ESP-in-TCP subsystemSpecifically, in the ULP (Upper Layer Protocol) route called espintcp. XFRM is the kernel framework responsible, among other things, for processing IPsec traffic, and ESP (Encapsulating Security Payload) is the protocol that provides confidentiality and authenticity through encryption (for example, AES-GCM), as occurred with a vulnerability in the CAN BCM network protocol.
The attack is based on a very specific kernel situation: when a TCP socket switches to ESP-in-TCP mode after file pages have been added to its receive queue by calls such as splice(2) o sendfile(2)Instead of treating this data as simple pages from a file, the kernel interprets it as ESP ciphertext and applies "decryption" to it, thus modifying the cache pages in situ.
As a consequence of this error, the kernel injects the AES-GCM keystream onto cache pages corresponding to read-only filesThis results in arbitrary byte writes to the page cache. By controlling the IV (nonce) and other parameters, an unprivileged user can precisely direct these writes. The result is a deterministic write primitive that allows a controlled number of bytes to be altered in any readable file, even if the file system marks it as immutable or read-only.
The public proof of concept focuses on modify the binary /usr/bin/su in the page cacheIt injects a 192-byte (positionally independent) ELF stub into the memory copy of that binary. From that point on, the next time it is executed suThe stub will run with root privileges, providing instant climbing without the need for condition runs or other additional tricks.
Temporary mitigations: how to protect yourself if you can't restart
Although it is recommended Install a patched kernel and reboot as soon as possible.Effective temporary mitigations have been described for those who cannot afford an immediate reboot. The good news is that, since Fragnesia exploits the same base modules (esp4, esp6, and optionally rxrpc) as Dirty Frag, the proposed mitigation for the latter also works for Fragnesia.
The technique consists of block the loading of vulnerable modules by configuring modprobe and, if they are already loaded, unload them from memory. This is done by writing a rule in /etc/modprobe.d/ which replaces the loading of those modules with harmless commands (such as /bin/falseThen one invokes rmmod about them, silently ignoring the errors if they are not present.
In distributions like CloudLinux, the proposed command for Dirty Frag (which works equally well for Fragnesia) generates a file dirtyfrag.conf with rules for esp4, esp6 y rxrpcIt also attempts to unload active modules. If you have already applied this mitigation for Dirty Frag, You don't have to do anything else for Fragenesis until you install the corrected kernel, because the attack surface is also neutralized.
Compatibility is important to consider: esp4 and esp6 are the kernel transforms for IPsecDisabling them breaks IPsec tunnels that depend on the kernel data path (for example, strongSwan or Libreswan). It is recommended not to use this mitigation on hosts that terminate or route critical IPsec traffic. The module rxrpc It is the AF_RXRPC transport, used almost exclusively by AFS clients, and is rarely present on web servers or other general-purpose scenarios.
Restore the page cache after applying mitigation
Another often overlooked point is that the exploit, when working, can leave something in memory modified copies of legitimate binaries in the page cacheThe most typical example is /usr/bin/suHowever, other privileged binaries could be affected if the attacker decides to change targets.
Therefore, some advisories recommend that, after applying module blacklist mitigation, you proceed to clear the system's page cache to force a clean reload from disk. This can be achieved by writing to /proc/sys/vm/drop_caches A value that tells the kernel to release the page cache and dentries/inodes. This operation only removes clean pages, so it is safe in production systems, although it may cause a temporary increase in disk I/O when the binaries and data are read again.
The idea is simple: if an instance of Fragnesia had already been executed before mitigation, The corrupted pages are discarded and the unaltered disk version will be used again.Combined with the module blacklist, this step reduces the risk that a possible residual modification in the cache will still be exploitable or cause erratic behavior in the system.
Patch status and supplier recommendations
Most of the major players in the Linux ecosystem have responded quickly to Fragnesia's discovery. Distributions like AlmaLinux and CloudLinux have published or are finalizing patched kernelsRed Hat has indicated that it is evaluating the extent to which existing mitigations for previous vulnerabilities also cover CVE-2026-46300.
Several security vendors, including companies associated with Google and Microsoft, have published analyses explaining that The vulnerability allows unprivileged local attackers to modify the contents of read-only files in the page cache. and escalate to root via deterministic memory corruption. Wiz, for example, points out that AppArmor and restrictions on unprivileged user namespaces can partially mitigate the impact by requiring additional techniques to successfully exploit the bug in some environments.
Microsoft, for its part, points out that No active exploitation in the wild was observed at the time of their statementHowever, they still urge users to apply the patch as soon as it becomes available, using the usual update tools. When immediate patching is not possible, they recommend applying the same mitigations proposed for Dirty Frag: disabling esp4, esp6, and non-essential IPsec/XFRM-related functionality, hardening interactive local access, and strengthening monitoring for unusual privilege escalation activity.
Threat context: exploit marketplace and patch fatigue
The discovery of Fragnesia occurs in a context in which The exploitation of local escalation vulnerabilities in Linux is gaining value on the black marketRecent reports describe an actor, under the alias “berz0k”, offering a zero-day local escalation vulnerability in Linux for $170.000, supposedly functional on multiple distributions. According to ThreatMon, the seller claims the vulnerability is of the TOCTOU (Time-of-Check Time-of-Use) type, allows stable escalation without causing crashes, and uses a payload in the form of a shared library..so) deployed in /tmp.
All of this fuels the feeling of saturation and fatigue Many administrators are expressing their frustration: “Another vulnerability in the same category as Dirty Frag,” or “Eight more like this and I’m out,” some commenting half-jokingly, half-seriously. The reality is that the succession of Copy Fail, Dirty Frag, and Fragnesia vulnerabilities is forcing systems teams to rethink their kernel update strategy, especially in environments where frequent reboots are very costly.
In this landscape, livepatching solutions like KernelCare or similar mechanisms are gaining prominence as alternative to apply critical fixes without interrupting servicesMeanwhile, distributions are under pressure to shorten the time between discovery, upstream fix release, and the availability of the patched package in stable repositories as much as possible.
Ultimately, Fragenesis has become a case study of how a small piece of logic in a specialized subsystem like XFRM ESP-in-TCP can have devastating consequences when combined with page caching mechanisms and privileged binariesStaying on top of security alerts, mailing lists, distribution blogs, and communication channels like Mattermost or X (formerly Twitter) is key to reacting quickly and minimizing the window of exposure.
The threat posed by Fragnesia lies not only in its ability to grant root access with a single command, but also in the fact that it demonstrates the extent to which modern Linux environments depend on a complex chain of trust that extends from kernel code to update tools and hardening policiesBeing protected involves combining official patches, well-understood mitigations, livepatch solutions where it makes sense, and a clear policy of local access control and monitoring, so that a failure of this type does not become the single point of failure for the entire infrastructure.
