EresusSecurity
Back to Research
Vulnerability Analysis

Fragnesia CVE-2026-46300: Linux Kernel XFRM ESP-in-TCP Local Privilege Escalation

Yiğit İbrahim SağlamOffensive Security Specialist
May 17, 2026
6 min read
Advisory AnalysisInfrastructure

CVE-2026-46300, codenamed Fragnesia, is a Linux kernel local privilege escalation vulnerability disclosed on May 14, 2026, and the third page-cache corruption LPE to affect Linux within a two-week window. It follows Copy Fail (CVE-2026-31431) and Dirty Frag (CVE-2026-43284 / CVE-2026-43500).

Fragnesia was discovered by William Bowling of Zellic and the V12 security team. It exploits a bug in the Linux kernel's XFRM ESP-in-TCP subsystem — a different code path from Dirty Frag's main attack vectors, but sharing the same exploitation class: deterministic page-cache corruption leading to root privilege escalation without any race condition.

CVSS v3.1: 7.8 HIGHAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

"The vulnerability allows unprivileged local attackers to modify read-only file contents in the kernel page cache and achieve root privileges through a deterministic page-cache corruption primitive." — Wiz (Google)

What Is Fragnesia?

Fragnesia is rooted in a flaw in the ESP/XFRM module of the Linux kernel — specifically the ESP-in-TCP transport path used by IPsec implementations. Like Dirty Frag, it leverages the kernel's splice()-based page-cache handling to write to read-only pages that should be protected. An unprivileged local attacker can corrupt a page-cache-backed file (such as a setuid binary) and escalate to root.

The name follows the "page cache fragmentation" naming theme established by the preceding vulnerabilities in this family.

How Fragnesia Differs from Dirty Frag

| Property | Dirty Frag | Fragnesia | |----------|-----------|-----------| | CVE | CVE-2026-43284 + CVE-2026-43500 | CVE-2026-46300 | | Attack path | xfrm-ESP (esp4/esp6) + RxRPC | XFRM ESP-in-TCP only | | Discovery | Wiz (Merav Bar, Rami McCarthy) | William Bowling (Zellic) + V12 team | | Disclosed | May 8, 2026 | May 14, 2026 | | Patch commit | f4c50a4034e6 + aa54b1d27fe0 | Separate patch | | In-the-wild | Limited (Microsoft Defender) | None observed at time of disclosure | | CAP_NET_ADMIN required (container) | Yes (default Kubernetes) | Yes (default Kubernetes) |

Critical note: The Dirty Frag workaround (blocklisting esp4, esp6, rxrpc) also mitigates Fragnesia because both vulnerabilities rely on the esp/xfrm subsystem.

Affected Distributions

All major Linux distributions shipping kernels that include the vulnerable XFRM ESP-in-TCP code path are affected. Distribution advisories published at time of Fragnesia disclosure:

| Distribution | Status | |---|---| | Ubuntu | Advisory published | | Red Hat Enterprise Linux | Advisory published | | Debian | Advisory published | | Amazon Linux | Advisory published | | SUSE | Advisory published | | AlmaLinux | Advisory published | | CloudLinux | Advisory published | | Gentoo | Advisory published |

Exploitation Scenario

Like the preceding vulnerabilities in this class, Fragnesia requires local code execution before the privilege escalation primitive is reachable. Typical initial access vectors include:

  • Compromised SSH credentials or keys
  • Web shell on an internet-facing application
  • Container escape to the host environment
  • Low-privileged service account abuse
  • CI/CD job runner (untrusted pull requests, user-supplied code)

Once local execution is available, Fragnesia's deterministic exploitation path — with no race condition — allows a reliable single-run root escalation.

Quick Inventory

# Check if xfrm/esp modules are loaded
lsmod | grep -E "^(esp4|esp6|xfrm)" || true

# Check for active IPsec policies
ip xfrm state list
ip xfrm policy list

# Identify containers with NET_ADMIN capability (Kubernetes)
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.containers[*].securityContext.capabilities.add}{"\n"}{end}' | grep -i net_admin || true

Mitigation

If you already applied the Dirty Frag workaround, Fragnesia is also mitigated — no additional action needed for the module blocklist:

# Verify the Dirty Frag blocklist also covers Fragnesia
cat /etc/modprobe.d/disable-dirtyfrag.conf
# Should contain: install esp4 /bin/false AND install esp6 /bin/false

If you have not yet applied any workaround:

# Block esp4 and esp6 (covers both Dirty Frag and Fragnesia)
cat > /etc/modprobe.d/disable-esp-xfrm.conf << 'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

rmmod esp6 2>/dev/null || true
rmmod esp4 2>/dev/null || true

Before applying: verify whether your systems use IPsec VPN tunnels (ip xfrm state list). The workaround will interrupt active IPsec sessions.

Microsoft Defender Coverage

The existing Dirty Frag signatures cover Fragnesia exploit artifacts:

  • Trojan:Linux/DirtyFrag.Z!MTB
  • Trojan:Linux/DirtyFrag.DA!MTB

No additional signature deployment is required if Dirty Frag signatures are already active.

Patch Strategy

Once your distribution releases a kernel update that explicitly addresses CVE-2026-46300:

  1. Confirm the advisory names CVE-2026-46300 in addition to CVE-2026-43284 and CVE-2026-43500
  2. Test the kernel update before rolling out to production nodes
  3. Schedule the reboot window for Kubernetes nodes and CI runners
  4. Remove the module blocklist after patching is confirmed on each host
  5. Validate IPsec and XFRM-dependent workloads after the kernel update

The Three-CVE Pattern

Copy Fail, Dirty Frag, and Fragnesia represent three vulnerabilities in the same exploitation class — splice()-based page-cache write primitives — disclosed within fifteen days of each other. Each was discovered by different research teams independently, suggesting this class of bug is being actively audited across multiple actors simultaneously.

For defenders, this pattern means:

  • Applying one mitigation does not protect against all three
  • The algif_aead blocklist (Copy Fail) does not protect against Dirty Frag or Fragnesia
  • The esp4/esp6 blocklist (Dirty Frag/Fragnesia) does not protect against Copy Fail
  • All three require separate kernel patches
  • Environments with untrusted local execution (CI/CD, containers, notebooks) remain the highest risk class until all three CVEs are patched

FAQ

Is Fragnesia the same as Dirty Frag?

No. Fragnesia (CVE-2026-46300) is a separate vulnerability in a different code path within the XFRM subsystem. It shares the same exploitation class (page-cache corruption) and similar CVSS score, but requires its own patch. It was discovered independently by a different research team.

Does blocking esp4/esp6 for Dirty Frag also block Fragnesia?

Yes. If you already have the Dirty Frag module blocklist in place (install esp4 /bin/false and install esp6 /bin/false), Fragnesia is also mitigated, since both use the esp/xfrm attack surface.

Is there in-the-wild exploitation of Fragnesia?

At the time of disclosure (May 14, 2026), no in-the-wild exploitation of Fragnesia specifically had been observed. Microsoft Defender had observed limited exploitation activity consistent with Dirty Frag or Copy Fail techniques, but not Fragnesia specifically.

Do I need to patch for all three CVEs separately?

Yes. CVE-2026-31431 (Copy Fail), CVE-2026-43284, CVE-2026-43500 (Dirty Frag), and CVE-2026-46300 (Fragnesia) are four separate vulnerabilities requiring four separate kernel patches. Check your distribution's advisory to confirm which CVEs a given kernel version addresses.

Checklist

  • [ ] Kernel version checked against distro advisory for CVE-2026-46300
  • [ ] esp4 and esp6 module blocklist verified (covers both Dirty Frag and Fragnesia)
  • [ ] IPsec/VPN workloads inventoried before applying or removing blocklist
  • [ ] Kubernetes pods with NET_ADMIN capability audited
  • [ ] Vendor kernel patch tracking opened for CVE-2026-46300
  • [ ] Patch confirmed to address CVE-2026-46300 in addition to Dirty Frag CVEs
  • [ ] Module blocklist removed after successful kernel patch deployment

Security Validation

Have you tested this risk in your own system?

Eresus Security delivers real exploit evidence through penetration testing, AI agent security, and red team operations.

Request a pilot test

Related Research