Fragnesia Linux Kernel Flaw Lets Local Attackers Gain Root Access

A newly disclosed Linux kernel vulnerability called Fragnesia can let local attackers escalate privileges to root on vulnerable systems. The flaw is tracked as CVE-2026-46300 and affects the kernel’s XFRM ESP-in-TCP subsystem.

The vulnerability was disclosed by William Bowling and the V12 Security team, which also released a public proof of concept. Security teams should treat the issue as urgent because the exploit can turn a low-privileged local account into full root access.

Fragnesia does not allow remote takeover by itself. An attacker first needs local access, such as a shell account, compromised web service user, container escape path, or another foothold on the system. Once that access exists, the bug can help the attacker take over the host.

What Fragnesia does

Fragnesia belongs to the same broad page-cache corruption class as Dirty Pipe, Copy Fail, and Dirty Frag. These flaws matter because they let attackers change cached copies of protected files in memory without directly changing the file stored on disk.

In this case, the bug affects ESP-in-TCP handling in the Linux kernel. The vulnerable path can treat already queued file-backed pages as ESP ciphertext after a TCP socket moves into espintcp mode.

That logic error lets an unprivileged local process create controlled one-byte writes into the page cache of read-only files. Researchers say no race condition is required, which makes the public exploit more reliable than many older kernel privilege escalation bugs.

Item	Details
Name	Fragnesia
CVE	CVE-2026-46300
Severity	High, CVSS 7.8
Component	Linux kernel XFRM ESP-in-TCP subsystem
Attack type	Local privilege escalation
Privileges required	Low local privileges
Public PoC	Available from V12 Security
Main impact	Root access through page-cache corruption

How the root escalation works

The public write-up explains that Fragnesia abuses a logic bug in the ESP/XFRM area of the kernel. When file-backed data is spliced into a receive queue before the socket switches into espintcp mode, the kernel can later process that data incorrectly.

The exploit uses this behavior to modify a cached copy of a read-only binary. The published proof of concept targets the page-cache copy of /usr/bin/su and overwrites part of it with a small payload that opens a root shell.

The important detail is that the on-disk file remains unchanged. A normal file integrity check may still show the original binary on disk, while the cached copy in memory behaves differently until the cache is flushed or the machine reboots.

Why administrators should prioritize patching

Local privilege escalation flaws can be extremely damaging in real attacks. Many intrusions begin with limited access, such as a compromised application account or a low-privileged shell. A bug like Fragnesia can turn that foothold into root access.

This is especially serious on multi-tenant systems, shared hosting servers, CI runners, container build machines, developer workstations, and systems where untrusted users can execute local code.

Linux distributions and vendors have started publishing advisories and patches. Administrators should follow their own vendor guidance because affected kernel versions and patch availability vary by distribution and kernel branch.

• Multi-tenant Linux servers face higher risk.
• CI runners and build farms should receive urgent review.
• Shared hosting platforms should prioritize kernel updates.
• Container hosts need extra attention if untrusted workloads can run locally.
• Systems with local shell access for many users need rapid mitigation.

Fragnesia is separate from Dirty Frag

Fragnesia is related to Dirty Frag by vulnerability class and mitigation surface, but it is not the same bug. V12 Security says Fragnesia is a separate issue in ESP/XFRM and has its own patch path.

CloudLinux also warned that customers who already applied the Dirty Frag mitigation need no additional temporary action before patched kernels arrive. The same module-level mitigation blocks the affected surface used by both issues.

This matters for administrators who already responded to Dirty Frag. If the same mitigation remains in place, Fragnesia exposure should be reduced while teams wait for vendor kernels. However, mitigation should not replace patching.

Affected distributions and patch status

Public advisories have appeared across major Linux ecosystems, including AlmaLinux, CloudLinux, Red Hat, Ubuntu, Debian, Gentoo, SUSE, and Amazon Linux. Some vendors have patches available, while others may still list certain kernels as under evaluation or testing.

AlmaLinux said every supported AlmaLinux release is affected and advised administrators to update quickly. CloudLinux said affected CloudLinux versions include several current streams and published mitigation guidance while kernel builds and live patches move through testing and release channels.

Ubuntu’s tracker shows mixed status across kernel packages, with many entries marked as needs evaluation or not in release. This reinforces why administrators should check their distribution’s security tracker rather than assuming every Linux system has the same status.

Environment	Risk level	Recommended action
Shared hosting servers	High	Patch quickly or apply temporary mitigation if compatible.
CI runners and build systems	High	Update kernels and restrict untrusted job execution.
Container hosts	High	Patch host kernels and review workload isolation.
Single-user desktops	Lower	Apply normal security updates, especially if untrusted apps run locally.
IPsec VPN servers	Special case	Test mitigation carefully because disabling ESP modules can break service.

Temporary mitigation before patched kernels

The primary fix is a patched kernel from the Linux vendor. Until that update is available and installed, administrators can reduce exposure by unloading and blocking the esp4, esp6, and rxrpc modules where operationally safe.

This mitigation can break systems that rely on kernel ESP handling, including some IPsec VPN deployments using strongSwan or Libreswan. Teams should test before applying it on VPN gateways or hosts that depend on IPsec.

For systems where mitigation is safe, administrators can block the modules until a patched kernel is installed. The following commands reflect the temporary mitigation approach published by CloudLinux.

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"

After installing a patched kernel and rebooting, administrators can remove the temporary block if the modules are needed.

sudo rm /etc/modprobe.d/dirtyfrag.conf

Flush page cache if exploitation is suspected

Fragnesia can modify cached copies of legitimate binaries. That means a successful exploit may leave a poisoned page-cache copy of /usr/bin/su or another targeted file in memory.

If administrators suspect exploitation before mitigation or patching, they should flush the page cache after applying protections. CloudLinux recommends dropping caches so the system reloads clean copies from disk.

sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

A reboot can also clear the affected cache state. However, a reboot alone does not fix the underlying vulnerability unless the system starts with a patched kernel or the temporary mitigation blocks the vulnerable modules.

Detection and response steps

There are no simple network indicators for Fragnesia because the attack happens locally inside the kernel. Detection should focus on suspicious local privilege changes, unexpected root shells, unusual su execution, and activity from low-privileged accounts.

Security teams should also review systems where untrusted users had shell access before patching. If attackers gained root, they may have added persistence, changed SSH keys, installed cron jobs, modified systemd units, or altered logs.

Teams should treat any confirmed exploitation as a full host compromise. A kernel privilege escalation gives attackers the authority needed to hide tools, create users, extract secrets, and move laterally.

1. Check the running kernel version against vendor advisories.
2. Install the patched kernel as soon as your vendor ships it.
3. Reboot into the patched kernel or apply a trusted live patch if available.
4. Apply the temporary module mitigation if patching is delayed and service impact is acceptable.
5. Flush page cache or reboot if exploitation may have occurred.
6. Review local account activity, su usage, sudo logs, SSH keys, cron jobs, and systemd units.
7. Rebuild high-risk systems if compromise cannot be ruled out.

Why Fragnesia matters now

Fragnesia continues a difficult run of Linux kernel privilege escalation disclosures linked to page-cache handling. The concern is not only the technical novelty, but also the public proof of concept and the reliability of the attack path.

Attackers often combine bugs. A web application flaw, stolen SSH credential, exposed CI runner, or compromised container can provide the first step. Fragnesia can then provide the second step by turning that limited access into root.

Linux administrators should avoid waiting for signs of exploitation. With public exploit code available and vendor patches moving out, the safest path is to patch quickly, apply temporary mitigations where needed, and review exposed systems for signs of post-exploitation activity.

FAQ