Vulnerabilities & Alerts

Dirty Frag (CVE-2026-43284 and CVE-2026-43500)

by  • 

Universal Local Privilege Escalation in the Linux Kernel

Executive summary

On May 7, 2026, researcher Hyunwoo Kim (alias @v4bel) publicly disclosed a new class of Linux kernel vulnerabilities named Dirty Frag (1) (2). This disclosure, brought forward as a result of an embargo break by an unrelated third party, exposes an exploitation chain combining two page-cache write primitives: xfrm-ESP Page-Cache Write (CVE-2026-43284) and RxRPC Page-Cache Write (CVE-2026-43500) (3) (4).

Exploitation enables any unprivileged local user to obtain root on the vast majority of maintained Linux distributions, with no race condition required and a very high success rate (5). A working proof-of-concept has been public since May 7, 2026 and predates the release of patches across most distributions (1). Severity is rated CVSS 3.1 = 7.8 (HIGH) by Canonical and Red Hat (6) (3).

This publication targets a CERT and SOC audience. It covers scope, technical chain, exploitation conditions, immediately applicable mitigations, and detection avenues.

1. Identification

CVE identifiers

  • CVE-2026-43284: xfrm-ESP Page-Cache Write (esp4, esp6 modules)
  • CVE-2026-43500: RxRPC Page-Cache Write (rxrpc module)

Public name: Dirty Frag (also known as Copy Fail 2, Copy Fail 2: Electric Boogaloo) (4) (7).

Discovery and reporting: Hyunwoo Kim (@v4bel), private report to Linux kernel maintainers on April 29 and 30, 2026, patch submission to the netdev mailing list, transmission to linux-distros@vs.openwall.org on May 7, 2026 (8).

Public disclosure: May 7, 2026, following the unilateral publication of technical details by an unrelated third party, forcing the researcher to release the write-up and PoC ahead of distribution patches (9) (8).

CVSS score: 7.8 (HIGH) according to Canonical and Red Hat assessments. No official score is yet available on NVD at the time of writing (6) (3).

Comparisons: Dirty Frag extends the bug class represented by Dirty Pipe (CVE-2022-0847) and Copy Fail (CVE-2026-31431). Unlike Dirty Cow (CVE-2016-5195), it is a deterministic logic flaw with no race window to win (5) (10).

2. Affected components

Both vulnerabilities reside in the in-place decryption path of Linux kernel networking modules:

  • esp4.ko and esp6.ko: support for the ESP (Encapsulating Security Protocol) protocol used by IPsec.
  • rxrpc.ko: RxRPC protocol, primarily used by AFS (Andrew File System).

The shared root cause lies in the handling of skb (socket buffers) whose fragments point to page-cache pages that are not exclusively owned by the kernel, typically when an attacker has injected those pages via splice(2) or sendfile(2) (11) (12).

3. Technical description

3.1. General principle

When a userspace process inserts a reference to a page-cache page into an skb transmitted to a socket via splice(2), the kernel receive-side code performs a cryptographic operation directly on that page, in-place, without any prior privative copy (skb_cow_data is bypassed in the fast path). The modified page belongs to the cache of files that the attacker normally only has read access to, for instance /etc/passwd or /usr/bin/su. Any subsequent read of that file then returns the altered version held in memory (12).

This alteration persists in RAM until the page is evicted from the cache, which is sufficient to modify sensitive files used in the authentication chain or the privilege escalation path (5).

3.2. CVE-2026-43284: xfrm-ESP Page-Cache Write

The flaw was introduced in commit cac2661c53f3 on January 17, 2017, which moved IPsec ESP receive into a fast in-place decryption path (5). In esp_input, the crypto_authenc_esn_decrypt function is called directly on the fragment, with no preliminary call to skb_cow_data. The result provides the attacker with a 4-byte store primitive into the page cache, equivalent to the one exposed by Copy Fail (4).

Triggering requires the creation of a user namespace and network namespace, a capability that is generally blocked by default on Ubuntu through AppArmor (10).

Note: the same 2017 commit was also the root cause of a separate buffer overflow, CVE-2022-27666 (10).

3.3. CVE-2026-43500: RxRPC Page-Cache Write

The flaw was introduced in June 2023 by commit 2dc334f1a63a, which applied the same fast-path pattern to RxRPC (8). In rxkad_verify_packet_1, an in-place single-block decryption with pcbc(fcrypt) is performed on the fragment (12).

This variant does not require the creation of namespaces. It does, however, require the availability of the rxrpc.ko module, which is rarely loaded by default on servers without an AFS deployment, but remains autoloadable through the creation of an AF_RXRPC socket and the registration of an rxkad key via add_key() (11).

The PoC compiles in a single command:

git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && \
gcc -O0 -Wall -o exp exp.c -lutil && ./exp

After execution, the page cache remains contaminated. The researcher recommends running echo 3 > /proc/sys/vm/drop_caches to flush the altered pages and ensure system stability (8).

3.4. Chaining the two primitives

According to the official write-up, neither xfrm-ESP Page-Cache Write nor RxRPC Page-Cache Write alone provides a sufficiently reliable primitive for full root escalation across all distributions (9). Chaining the two mechanisms bypasses their respective limitations:

  • On systems where unprivileged namespace creation is blocked (Ubuntu via AppArmor), xfrm-ESP alone does not trigger. The RxRPC variant takes over (10).
  • On systems where rxrpc.ko is not available by default, xfrm-ESP covers the need (10).

According to Sysdig, the exploit relies only on standard system calls (socket, setsockopt, bind, vmsplice, splice, sendmsg) and modules present in the default kernel packages of every major enterprise distribution (11).

4. Impact scope

4.1. Affected distributions

Any Linux distribution shipping a kernel that includes the offending commits is affected, which means all branches released since 2017 for the ESP variant and since 2023 for the RxRPC variant.

Official confirmations:

  • Ubuntu: all supported releases (14.04 LTS Trusty, 16.04 LTS Xenial, 18.04 LTS Bionic, 20.04 LTS Focal, 22.04 LTS Jammy, 24.04 LTS Noble, 25.10 Questing, 26.04 LTS Resolute) (6).
  • Red Hat Enterprise Linux: RHEL 9 and 10 confirmed affected. On RHEL 9 and 10, the workaround based on disabling unprivileged user namespaces only covers the ESP variant. The RxRPC variant remains exploitable until rxrpc is also explicitly blacklisted (3).
  • AlmaLinux, CloudLinux 7h, 8, 9, 10, CentOS Stream, Fedora, openSUSE, OpenShift: confirmed affected (4) (7).

4.2. Containers and orchestrators

Impact is amplified in containerized environments running third-party workloads (1):

  • Privilege escalation on the host from a container without proper isolation.
  • Potential container escape (no public PoC specific to that scenario at the time of writing).

According to Sysdig, any container able to create AF_KEY, netlink XFRM, or AF_RXRPC* sockets, which is the default behavior of Docker, containerd, and most unconstrained Kubernetes pods, directly inherits the exposure of the host kernel (11). Tests published on EKS and GKE confirm that pods without an explicitseccomp` profile remain vulnerable, at the very least through the RxRPC path (13).

5. Exploitation conditions

Conditionxfrm-ESP (CVE-2026-43284)RxRPC (CVE-2026-43500)
Local access requiredYesYes
Initial privilegesUnprivileged userUnprivileged user
User namespace creationRequiredNot required
Required kernel moduleesp4 or esp6 (loadable by default)rxrpc (autoloadable)
Required capabilityCAP_NET_ADMIN within the namespaceNo specific capability
Remote network vectorNoneNone

Typical initial access vectors observed: SSH with low-privilege account, web shell, post-compromise execution via a vulnerable application, prior container escape, or compromised application account (14).

6. Detection

6.1. Behavioral indicators

The following elements are relevant early-stage signals for EDR or runtime-security monitoring:

  • Creation of an AF_RXRPC socket (domain=33) by an unusual process. RxRPC has no legitimate consumer outside AFS daemons (11).
  • Call to add_key("rxrpc", ...) registering an rxkad key, a prerequisite for the RxRPC path.
  • Unsolicited creation of a user namespace followed by a network namespace by an unlisted binary, followed by XFRM operations via netlink.
  • Combination of socket(AF_KEY) or XFRM netlink + vmsplice + splice + sendmsg in a chronology consistent with the public PoC.
  • Abnormal modification, in page cache, of SUID binaries (/usr/bin/su, /usr/bin/sudo, /usr/bin/passwd) or sensitive files (/etc/passwd, /etc/shadow).

6.2. Available rules

  • Sysdig / Falco: existing Copy Fail rules (AF_ALG Page Cache Poisoning Leading to Privilege Escalation, AF_ALG Page Cache Poisoning Targeting Sensitive File) partially cover Dirty Frag. Two new rules dedicated to the ESP and RxRPC paths have been added to the Sysdig Runtime Behavioral Analytics policy (11).
  • Imunify360 / CloudLinux: the bash chain of the public PoC is integrated into behavioral blocklists, complementing the kernel patch (7).
  • Microsoft Defender: active monitoring and publication of a post-compromise attack analysis combining Dirty Frag, modification of GLPI/LDAP authentication files, and PHP session cleanup (14).

6.3. Public IOCs

The exploitation binary observed in post-compromise activity is notably referenced as ./update (ELF binary dropped after initial SSH access), followed by an immediate escalation via su (14). The original PoC is publicly hosted on github.com/V4bel/dirtyfrag; any file originating from that repository found on a production system should be treated as suspicious.

7. Mitigations

7.1. Kernel patch deployment (priority target)

  • Mainline: CVE-2026-43284 fixed by commit f4c50a4034e6 (8). As of May 8, 2026, the Linux Kernel Organization has published patches related to CVE-2026-43284 on NVD (14).
  • CVE-2026-43500: no public upstream patch at the time of writing. Actively monitor distribution announcements and apply kernel updates as soon as they become available (15).
  • Distributions: track Ubuntu (USN), Red Hat (RHSA), AlmaLinux, CloudLinux, SUSE, and Debian advisories. CloudLinux also provides a KernelCare livepatch (7).

7.2. Immediate mitigation through module blocking

This mitigation applies while waiting for the kernel patch. It is effective against both variants simultaneously (6) (4).

# 1. Permanent module blocking
sudo tee /etc/modprobe.d/dirty-frag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

# 2. Initramfs regeneration (all installed kernel versions)
sudo update-initramfs -u -k all   # Debian / Ubuntu
# or
sudo dracut --force               # RHEL / Alma / CloudLinux / Fedora

# 3. Immediate unloading if already loaded
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

# 4. Verification
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
    && echo "Modules STILL loaded -- reboot required" \
    || echo "Modules NOT loaded -- mitigation effective"

# 5. Optional: page cache flush
echo 3 | sudo tee /proc/sys/vm/drop_caches

If the modules are actively in use (IPsec, AFS), unloading will fail and a planned reboot will be required to make the mitigation effective.

7.3. Partial mitigation: blocking user namespaces

This option is documented by Red Hat. It only covers the ESP variant and is sufficient only if rxrpc is also blacklisted (3).

echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Side effect: impact on rootless containers, browser sandboxes, and Flatpak.

7.4. Functional regressions to anticipate

  • IPsec / VPN (StrongSwan, Libreswan, etc.): unavailable when esp4 and esp6 are blocked.
  • AFS or any application relying on RxRPC: unavailable when rxrpc is blocked.
  • Rootless containers and Flatpak: impacted by the disabling of user namespaces.

Before deploying the mitigation at scale, an inventory of hosts using IPsec or AFS is necessary (search via lsmod | grep -E 'esp4|esp6|rxrpc', audit of strongSwan / ip xfrm configurations, audit of afs mounts).

7.5. Lifting the mitigation after patching

sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all   # or dracut --force depending on distribution
sudo modprobe esp4 esp6 rxrpc     # reload as needed

8. Comparison with prior vulnerabilities

VulnerabilityCVETypeDeterministicWrite granularity
Dirty CowCVE-2016-5195Race conditionNoFull page, unstable
Dirty PipeCVE-2022-0847LogicYesLimited (offset, flags)
Copy FailCVE-2026-31431LogicYes4 bytes
Dirty Frag (ESP)CVE-2026-43284LogicYes4 bytes
Dirty Frag (RxRPC)CVE-2026-43500LogicYesAttacker-chosen plaintext at chosen offset

According to Sysdig, Dirty Frag replaces the 4-byte primitive of Copy Fail with a fully attacker-controlled plaintext, at an arbitrary offset, in a single shot (11). This characteristic makes it a substantially more powerful primitive.

The hypothesis put forward by Sysdig is that the time elapsed between the introduction of the flaws (2017 and 2023) and their discovery suggests support from AI-assisted analysis tools in the research effort (11).

9. CERT / SOC recommendations

Short term (immediate)

  1. Inventory all Linux hosts within scope, including containers and Kubernetes nodes.
  2. Identify hosts using IPsec and AFS to qualify the regression risk of the mitigation.
  3. Deploy the module-blacklist mitigation for esp4, esp6, and rxrpc on hosts that do not consume IPsec or AFS.
  4. For IPsec hosts in production with no immediate alternative, consider the Red Hat workaround (user.max_user_namespaces=0) in conjunction with blocking rxrpc only, while measuring the impact on rootless workloads.
  5. Enable or strengthen EDR detection rules targeting the creation of AF_RXRPC sockets and the vmsplice + splice + XFRM operation sequences.

Short to medium term

  1. Monitor the publication of kernel updates on official distribution advisories (USN, RHSA, ALSA, CLSA, SUSE-SU, DSA).
  2. Plan the reboots required to apply kernel patches, or activate KernelCare / livepatch where available.
  3. Audit Kubernetes containers to ensure that a restrictive seccomp profile is applied by default, and consider RuntimeDefault at minimum on pods exposed to third-party workloads (13).
  4. For multi-tenant environments or those running untrusted code, treat the risk as active until the full kernel patch deployment is confirmed.

Medium term

  1. Reassess the loading posture of exotic networking kernel modules, in particular rxrpc and any unused AF_* family, with a view to reducing the attack surface.
  2. Industrialize the continuous verification of the presence of the /etc/modprobe.d/dirty-frag.conf file or equivalent across the entire estate, until the end of the update cycle.
  3. Integrate Dirty Frag into threat-hunting scenarios focused on post-initial compromises with local privilege escalation.

10. Disclosure timeline

  • April 29 and 30, 2026: private report to Linux kernel maintainers by Hyunwoo Kim, patch submission to the netdev mailing list (9).
  • May 7, 2026: transmission to linux-distros@vs.openwall.org; embargo break by an unrelated third party and forced publication of the write-up and PoC on the same day (1) (8).
  • May 8, 2026: assignment of identifiers CVE-2026-43284 and CVE-2026-43500; publication by Canonical, Red Hat, AlmaLinux, CloudLinux, and other vendors; upstream patch released by the Linux Kernel Organization for CVE-2026-43284 (14) (6).

Sources

  • (1) Wiz Research, Dirty Frag (CVE-2026-43284) Linux Privilege Escalation: https://www.wiz.io/blog/dirty-frag-linux-kernel-local-privilege-escalation-via-esp-and-rxrpc
  • (2) GitHub V4bel/dirtyfrag, Official repository of the Dirty Frag PoC and write-up: https://github.com/V4bel/dirtyfrag
  • (3) Red Hat Security Bulletin, RHSB-2026-003 Networking subsystem Privilege Escalation – Linux Kernel (Dirty Frag): https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
  • (4) CloudLinux Blog, Dirty Frag (CVE-2026-43284, CVE-2026-43500): Mitigation and Kernel Update on CloudLinux: https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
  • (5) Mondoo Blog, Dirty Frag: Universal Linux LPE via Page Cache Writes: https://mondoo.com/blog/dirty-frag-universal-linux-lpe-via-page-cache-writes
  • (6) Canonical Ubuntu Blog, Dirty Frag Linux kernel local privilege escalation vulnerability mitigations: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available
  • (7) Tenable Blog, Dirty Frag (CVE-2026-43284, CVE-2026-43500): Frequently Asked Questions about this Linux kernel privilege escalation vulnerability chain: https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe
  • (8) GitHub V4bel/dirtyfrag, README and detailed technical write-up: https://github.com/V4bel/dirtyfrag/blob/master/README.md
  • (9) Help Net Security, Dirty Frag: Unpatched Linux vulnerability delivers root access: https://www.helpnetsecurity.com/2026/05/08/dirty-frag-linux-vulnerability-cve-2026-43284-cve-2026-43500/
  • (10) The Hacker News, Linux Kernel Dirty Frag LPE Exploit Enables Root Access Across Major Distributions: https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html
  • (11) Sysdig, Dirty Frag (CVE-2026-43284 and CVE-2026-43500): Detecting unpatched local privilege escalation via Linux Kernel ESP and RxRPC: https://www.sysdig.com/blog/dirty-frag-cve-2026-43284-and-cve-2026-43500-detecting-unpatched-local-privilege-escalation-via-linux-kernel-esp-and-rxrpc
  • (12) GitHub V4bel/dirtyfrag, Detailed technical write-up: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md
  • (13) Juliet Security, Dirty Frag in Kubernetes: EKS and GKE Exposed With Unset Seccomp: https://juliet.sh/blog/we-tested-dirty-frag-in-kubernetes-eks-gke-talos-seccomp
  • (14) Microsoft Security Blog, Active attack: Dirty Frag Linux vulnerability expands post-compromise risk: https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/
  • (15) Security Boulevard, Dirty Frag (CVE-2026-43284, CVE-2026-43500): Frequently asked questions about this Linux kernel privilege escalation vulnerability chain: https://securityboulevard.com/2026/05/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-about-this-linux-kernel-privilege-escalation-vulnerability-chain/