Dirty Frag CVE-2026-43284: Linux Kernel Local Privilege Escalation via ESP and RxRPC

CVE-2026-43284 and CVE-2026-43500, collectively named Dirty Frag, are a chained local privilege escalation vulnerability in the Linux kernel disclosed publicly in early May 2026 and actively exploited in limited in-the-wild campaigns confirmed by Microsoft Defender. A third variant, Fragnesia (CVE-2026-46300), surfaced on May 14, 2026, bringing the total count of related page-cache LPE flaws to three within a two-week window.

Dirty Frag is the second major page-cache manipulation vulnerability to hit Linux in 2026, following Copy Fail (CVE-2026-31431). Unlike Copy Fail, Dirty Frag does not depend on the algif_aead module — a working exploit will succeed even on systems where the Copy Fail mitigation has already been applied. SUSE refers to the vulnerability as "Copy Fail 2" in its advisory.

The vulnerability was discovered and analyzed by Wiz researchers Merav Bar and Rami McCarthy, who described it as a deterministic, race-condition-free privilege escalation — similar in class to Copy Fail and Dirty Pipe. A working single-command PoC is publicly available.

Vulnerability Chain Overview

Dirty Frag combines two page-cache write primitives in the Linux kernel:

| CVE | Subsystem | Mainline Fix Commit | |-----|-----------|---------------------| | CVE-2026-43284 | xfrm-ESP (IPsec — esp4, esp6) | f4c50a4034e6 | | CVE-2026-43500 | RxRPC | aa54b1d27fe0 |

CVE-2026-46300 (Fragnesia) — a separate but related flaw in the XFRM ESP-in-TCP subsystem — was discovered by William Bowling (Zellic) and the V12 security team and patched on May 14, 2026. Fragnesia leverages only the esp/xfrm attack path and does not include the RxRPC vector.

Both Dirty Frag CVEs allow modification of page-cache-backed memory not exclusively owned by the kernel. Once a page-cache page is corrupted, the attacker can overwrite a setuid binary to execute arbitrary code as root.

"Both flaws allow modification of page-cache-backed memory that is not exclusively owned by the kernel, enabling corruption of sensitive files and ultimately privilege escalation. Unlike race-condition-based exploits, this bug class is deterministic and highly reliable, similar to previous vulnerabilities like Copy Fail and Dirty Pipe." — Merav Bar and Rami McCarthy, Wiz

CVSS Scores

CVE-2026-43284: CVSS 7.8 HIGH — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2026-43500: CVSS 7.8 HIGH — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2026-46300 (Fragnesia): CVSS 7.8 HIGH — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Technical Overview

Dirty Frag abuses how the Linux kernel handles memory fragment reassembly in the xfrm-ESP (IPsec) and RxRPC networking subsystems. The exploit chain uses the splice() system call to chain a page-cache-backed page into a writable kernel buffer — the same class of bug exploited by Copy Fail. The key difference is that the attack surface here is the networking stack, not the crypto API.

Because splice() can bridge kernel page-cache pages into the IPsec and RxRPC fragment reassembly paths without forcing a copy, an unprivileged local attacker can write to a read-only page-cache page. The result is a controlled corruption primitive applied to any page-cache-backed file — including setuid binaries like /usr/bin/su.

Critical nuance for Copy Fail adopters: Dirty Frag is triggered through esp4, esp6, or rxrpc — not through algif_aead. Organizations that applied only the Copy Fail workaround (blacklisting algif_aead) remain fully vulnerable to Dirty Frag and must apply separate mitigations.

To exploit Dirty Frag in a hardened containerized environment, the attacker generally requires CAP_NET_ADMIN. Kubernetes deployments using default seccomp profiles and without elevated capabilities are therefore significantly harder to exploit from within a container — though host-level access from SSH, a web shell, or a container escape path bypasses this requirement.

In-the-Wild Exploitation

Microsoft Defender has detected limited active in-the-wild exploitation involving either Dirty Frag or Copy Fail techniques. The observed campaign follows this pattern:

1. External actor gains SSH access and spawns an interactive shell
2. Stages and executes an ELF binary (./update) that triggers privilege escalation via su
3. Modifies a GLPI LDAP authentication configuration file (.swp artefact visible from vim)
4. Performs reconnaissance of the GLPI directory and system configuration
5. Accesses and deletes PHP session files to disrupt active sessions
6. Reads remaining session data to harvest credentials

The attack leverages initial SSH foothold to reach the LPE primitive, then moves laterally via IT management tooling. This pattern is consistent with post-compromise opportunistic exploitation rather than a targeted zero-day campaign.

Microsoft Defender Antivirus signatures covering Dirty Frag exploitation:

• Exploit:Linux/DirtyFrag.A
• Exploit:Linux/DirtyFrag.B
• Trojan:Linux/DirtyFrag.Z!MTB
• Trojan:Linux/DirtyFrag.ZA!MTB
• Trojan:Linux/DirtyFrag.ZC!MTB
• Trojan:Linux/DirtyFrag.DA!MTB

The Fragnesia signatures Trojan:Linux/DirtyFrag.Z!MTB and Trojan:Linux/DirtyFrag.DA!MTB also cover known public Fragnesia exploit artifacts.

Affected Systems and Vendor Advisories

Dirty Frag affects a wide range of Linux distributions shipping the vulnerable kernel versions. The following distributions have released security advisories:

| Distribution | Advisory / Status | |---|---| | Ubuntu | ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available | | Red Hat Enterprise Linux | RHSB-2026-003 | | Debian | security-tracker CVE-2026-43284 | | Amazon Linux | AWS Security Bulletin 2026-027 | | SUSE | addressing-copy-fail2-aka-dirtyfrag | | Fedora | FEDORA-2026-8cffa03dad | | Rocky Linux | forums.rockylinux.org discussion | | Gentoo | bugs.gentoo.org/974307 | | AlmaLinux | Advisory published | | CloudLinux | Advisory published |

Priority systems for immediate action:

• Kubernetes nodes and container hosts
• Self-hosted GitHub Actions, GitLab Runner, Jenkins agents
• Multi-tenant Linux servers and build farms
• Systems executing user-supplied code (notebooks, sandboxes)
• GLPI, Zabbix, Nagios, or other IT management systems reachable via SSH from external networks

Quick Inventory Commands

# Check kernel version
uname -r
uname -a

# Check if affected modules are loaded
lsmod | grep -E "^(esp4|esp6|rxrpc)" || true

# Check for active connections using these modules
ss -ntp | grep -v LISTEN || true

# Verify if patch commit is present (CVE-2026-43284)
grep -r "f4c50a4034e6" /proc/cmdline 2>/dev/null || true

For Kubernetes and container hosts:

# List all pods and their security contexts
kubectl get pods -A -o wide

# Check for pods running without seccomp profile
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.securityContext.seccompProfile.type}{"\n"}{end}'

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

Temporary Mitigation

Until the vendor kernel patch is applied, blocklist the affected modules to prevent them from loading:

# Block esp4, esp6, and rxrpc modules from loading
cat > /etc/modprobe.d/disable-dirtyfrag.conf << 'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

# Unload currently active modules where safe
rmmod rxrpc 2>/dev/null || true
rmmod esp6 2>/dev/null || true
rmmod esp4 2>/dev/null || true

Before applying this workaround, verify which systems depend on these modules:

# Check if IPsec/VPN tunnels are using esp4/esp6
ip xfrm state list
ip xfrm policy list

# Check if RxRPC is in use (AFS filesystem users)
lsmod | grep -E "rxrpc|kafs" || true

This mitigation will break IPsec VPN tunnels that use the ESP transport. If your systems depend on IPsec, evaluate a phased approach: patch dev/test environments immediately and apply the module blocklist only on hosts where IPsec is confirmed unused, prioritizing the kernel patch elsewhere.

Post-Exploitation Cache Clearing

If exploitation occurred before mitigation, malicious modifications may persist in the page cache even after the modules are disabled. To flush cached content:

# Synchronize filesystems before dropping caches
sync

# Drop all page caches (warning: temporary I/O performance impact)
echo 3 | sudo tee /proc/sys/vm/drop_caches

Evaluate cache clearing carefully in production environments — it can cause a temporary spike in disk I/O as cold pages are re-read from storage.

Container and Kubernetes Hardening

Dirty Frag requires CAP_NET_ADMIN to exploit from within a default-seccomp Kubernetes pod. However, this is not a reliable protection boundary on its own because:

• Many deployments grant NET_ADMIN for legitimate networking features
• Host-level access (compromised SSH, web shell, container escape) bypasses container capability restrictions entirely
• CAP_NET_ADMIN may be granted implicitly through misconfigured admission policies

Recommended container hardening actions:

• Audit pods for NET_ADMIN capability and remove where not required
• Enforce a restrictive seccomp profile that blocks socket() calls for AF_INET6 raw sockets
• Use PodSecurity restricted enforcement level on sensitive namespaces
• Isolate untrusted workloads (PR jobs, user notebooks) from production credential namespaces

# PodSecurity admission example - namespace-level restriction
apiVersion: v1
kind: Namespace
metadata:
  name: untrusted-workloads
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Fragnesia (CVE-2026-46300) — Third Variant

On May 14, 2026, a new variant named Fragnesia was published, tracked as CVE-2026-46300 (CVSS 7.8). Fragnesia exploits only the esp/xfrm module path (XFRM ESP-in-TCP subsystem), not the RxRPC path. It was discovered by William Bowling of Zellic and the V12 security team.

"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)

Key differences from Dirty Frag:

• Fragnesia does not use the RxRPC attack path
• The patch for Fragnesia is separate from the Dirty Frag patches
• Microsoft Defender signatures Trojan:Linux/DirtyFrag.Z!MTB and Trojan:Linux/DirtyFrag.DA!MTB already cover Fragnesia public exploit artifacts
• Advisories published: AlmaLinux, Amazon Linux, CloudLinux, Debian, Gentoo, RHEL, SUSE, Ubuntu

Applying the Dirty Frag workaround (blocklisting esp4, esp6, rxrpc) also blocks the Fragnesia attack path since both rely on the esp/xfrm subsystem.

Disclosure Timeline

| Date | Event | |------|-------| | 2026-05-08 | Linux Kernel Organization releases patch for CVE-2026-43284 (f4c50a4034e6) | | 2026-05-08 | Microsoft Security Blog publishes Dirty Frag analysis; limited in-the-wild exploitation confirmed | | 2026-05-08 | NVD publishes CVE-2026-43284; CVE-2026-43500 reserved but not yet published | | 2026-05-08 | CVE-2026-43500 (RxRPC) patched in mainline at aa54b1d27fe0 | | 2026-05-08 | Wiz advisory published with full technical analysis | | 2026-05-14 | Fragnesia (CVE-2026-46300) discovered by William Bowling (Zellic) / V12 team | | 2026-05-14 | Microsoft updates blog post to cover Fragnesia variant | | 2026-05-14 | New Fragnesia patch released; distro advisories updated |

Patch Strategy

Once your distribution releases the updated kernel package:

1. Confirm the vendor advisory covers both CVE-2026-43284 and CVE-2026-43500 (and CVE-2026-46300 for Fragnesia)
2. Install the kernel update in a test environment first
3. Verify IPsec and RxRPC-dependent workloads still function after patching
4. Plan the reboot window — kernel updates require a restart
5. Roll out Kubernetes node pools and CI runners in waves
6. Remove the module blocklist only after patching is confirmed
7. Re-evaluate whether NET_ADMIN capability grants remain necessary

Eresus Perspective

Dirty Frag is the third deterministic page-cache LPE in the Linux kernel within a two-week window. The pattern — Copy Fail, Dirty Frag, Fragnesia — indicates that this class of vulnerability (splice-based page-cache write primitives through kernel networking and crypto subsystems) is receiving sustained research attention.

For defenders, the key questions are not just "is the CVE patched?":

• Which hosts have esp4, esp6, or rxrpc modules loaded right now?
• Which systems received the Copy Fail mitigation but not the Dirty Frag mitigation?
• Which Kubernetes pods have NET_ADMIN capability and share a node with lower-trust workloads?
• Which IT management systems (GLPI, Zabbix, Nagios) are reachable from external SSH?
• What is the patch window for production nodes, and what compensating controls apply during that window?

These are operational questions. Without answers to them, tracking CVE scores is not risk management.

FAQ

Is Dirty Frag remotely exploitable?

The disclosed scenario is local privilege escalation. Initial access via SSH, a web shell, or a container escape is required before the LPE primitive is reachable. The in-the-wild campaign observed by Microsoft followed exactly this pattern: SSH foothold → LPE via su → lateral movement.

Does applying the Copy Fail mitigation protect against Dirty Frag?

No. Copy Fail is blocked by disabling algif_aead. Dirty Frag uses the esp4, esp6, and rxrpc modules — a completely separate attack surface. Both mitigations need to be applied independently.

Does Dirty Frag affect containerized environments?

In default Kubernetes configurations with standard seccomp profiles and without NET_ADMIN, the barrier is higher. But it is not a reliable protection boundary — misconfigured pods, host-level access, or a container escape can bypass it.

What is Fragnesia and is it different from Dirty Frag?

Fragnesia (CVE-2026-46300) is a third, independent flaw in the XFRM ESP-in-TCP subsystem. It shares the same exploitation class (deterministic page-cache corruption) but uses a different code path. Blocking esp4 and esp6 also mitigates Fragnesia.

Checklist

• [ ] Kernel version and distribution advisory checked for CVE-2026-43284, CVE-2026-43500, and CVE-2026-46300
• [ ] esp4, esp6, rxrpc module load status verified per host
• [ ] IPsec/VPN workloads inventoried before applying module blocklist
• [ ] Module blocklist applied on hosts where IPsec is unused
• [ ] Kubernetes pod NET_ADMIN grants audited
• [ ] Container seccomp profiles reviewed
• [ ] Untrusted workloads isolated from production credential namespaces
• [ ] GLPI, Zabbix, and other IT management systems hardened against external SSH
• [ ] Vendor kernel patch tracking opened with reboot planning
• [ ] Page-cache integrity assessment run on hosts with possible prior exploitation
• [ ] Post-patch verification completed and module blocklist removed