The Linux kernel has another local privilege escalation issue in the same broad attack surface as Dirty Frag: Fragnesia (CVE-2026-46300).
According to V12 Security, Fragnesia is a Linux local privilege escalation vulnerability. An attacker does not need existing high privileges on the host. If they can execute local code, they may be able to abuse a logic flaw in the kernel’s XFRM ESP-in-TCP subsystem to modify read-only file contents through the page cache and eventually trigger a root shell.
Source:
- V12 Security PoC notes: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md
This post does not cover reproducible exploitation steps. It focuses on the operational risk and response path.
How It Relates to Dirty Frag
V12 Security classifies Fragnesia as part of the Dirty Frag vulnerability class. It is not the same bug as Dirty Frag, but it lives in a related attack surface: Linux kernel XFRM ESP-in-TCP.
XFRM is the Linux kernel framework for IPsec processing. ESP-in-TCP is related to carrying ESP encrypted traffic over TCP. Fragnesia comes from logic around shared page fragments and socket buffer coalescing: in some cases, the kernel can lose track of the fact that a fragment is still shared, leaving room for controlled writes.
This resembles the broader Dirty Pipe / Dirty Frag family of page-cache write issues. The concrete code paths differ, but the effect again lands on the page-cache copy of a read-only file.
Why the Risk Is High
Fragnesia is dangerous for three reasons.
First, it is a local privilege escalation. Once an attacker can run ordinary user-level code on a system, they may be able to become root. That matters especially on multi-user servers, container hosts, CI runners, shared development machines, VPS instances, and systems exposing shell access.
Second, it does not rely on a traditional race condition. V12’s notes describe a path that drives ESP-in-TCP processing over file-backed pages already spliced into a socket buffer, allowing byte-level influence over page-cache contents. That makes the issue more practical than a purely theoretical bug.
Third, it changes the page cache, not the on-disk file. The public notes use /usr/bin/su as an example target. After successful exploitation, the file on disk is not permanently modified; the modified copy lives in memory. Integrity checks that only compare disk hashes may miss this.
That is the awkward part for administrators: the file can look unchanged, but executing the polluted page-cache copy of a target binary may still trigger privilege escalation.
Known Affected Scope
V12 Security states that kernels affected by Dirty Frag and missing the relevant May 13, 2026 patches are also affected by Fragnesia. Publicly tested environments include Ubuntu 22.04, Ubuntu 24.04, and kernels such as 6.8.0-111-generic.
There are two important caveats.
First, do not judge only by the distribution major version. Whether Ubuntu 22.04 or 24.04 is affected depends on the actual kernel patch state, not just the distribution name.
Second, do not rely only on default AppArmor restrictions for unprivileged user namespaces. Ubuntu’s AppArmor restrictions can raise the bar, but the disclosure treats that as an additional bypass problem, not as a fix for the vulnerability itself.
The reliable path is still to check distribution security advisories and kernel package updates.
Temporary Mitigation
If a system cannot be upgraded immediately, first check whether it depends on the relevant protocol modules.
V12 gives the same mitigation direction as Dirty Frag: if the system does not depend on IPsec ESP or RxRPC, administrators can consider disabling modules such as esp4, esp6, and rxrpc. This can affect networking features, so production systems should not do it blindly. Confirm whether the environment uses IPsec, VPNs, tunnels, or related kernel functionality.
A safer response order is:
- Check whether the distribution has published a kernel security update.
- Install the kernel patch and schedule a reboot first.
- If immediate upgrade is impossible, evaluate temporary module disabling.
- Prioritize multi-user systems and CI / build environments.
- Review unnecessary local accounts, shell access, container escape surface, and low-privilege execution entry points.
Disabling modules should not be treated as the final fix. It is only a way to reduce exposure while moving toward a patched kernel.
If Exploitation Is Suspected
One key feature of Fragnesia is page-cache pollution. V12 notes that after exploitation, the target file’s page-cache copy may contain injected content, and later execution can still behave abnormally until the page is evicted or the system is rebooted.
If exploitation is suspected, do at least the following:
- Preserve logs and audit records as soon as possible.
- Check recent abnormal local logins, low-privilege user activity, suspicious processes, and root shell traces.
- Clear the relevant page cache or reboot directly.
- Upgrade to a fixed kernel.
- Verify key binaries, but do not rely only on disk hashes.
- Rotate potentially exposed credentials and keys.
For production servers, it is better to treat this as a potential local privilege escalation incident, not merely as a routine patch event.
Which Machines Should Come First
The highest priority is not every Linux machine equally. Start with systems where attackers are most likely to obtain low-privilege code execution.
High-priority environments include:
- Multi-user login servers
- CI / CD runners
- Build machines
- Shared development machines
- Container hosts
- VPS and cloud servers
- Edge nodes exposing SSH
- Platforms running third-party scripts or plugins
Closed, single-user machines with no external code execution entry point are still affected if vulnerable, but their urgency is lower.
Summary
Fragnesia matters not because it has a new name, but because it again pulls Linux local privilege escalation back into the difficult boundary between the page cache and kernel networking subsystems.
For administrators, the important work is to confirm kernel patch status, understand whether ESP / RxRPC is in use, prioritize highly exposed machines, and remember that “the disk file is unchanged” does not mean “the system was unaffected.”
If a system is affected, the final answer is still to install the distribution’s kernel update as soon as possible. Temporary module disabling is only a bridge, not a replacement for the patch.