A newly disclosed Linux kernel local privilege escalation vulnerability chain, dubbed “Dirty Frag” and assigned CVE-2026-43284 and CVE-2026-43500, enables attackers with local access to obtain root privileges by exploiting flaws in the ESP (IPsec) and RxRPC subsystems. While no official patches are currently available, a public proof-of-concept exists. Organizations should assume the vulnerability is valid and exploitable under certain conditions. This vulnerability is a successor to Copy Fail (CVE-2026-31431), and was discovered by Hyunwoo Kim (@v4bel). "CopyFail2" is another name for the same vulnerability, and is based on an exploit reversed from the fix commit.
What is Dirty Frag?
Dirty Frag is a vulnerability chain combining two page-cache write primitives in the Linux kernel: one in the xfrm-ESP (IPsec) subsystem and another in RxRPC. 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.
To pull off this exploit, an attacker needs two things: access to specific vulnerable kernel interfaces and the ability to manipulate page-backed buffers (e.g., via splice()-related paths).
However, there is a significant hurdle: the exploit usually requires high-level system permissions, such as CAP_NET_ADMIN. This means exploitation is less likely in hardened containerized environments (e.g., Kubernetes with default seccomp profiles). However, the risk remains significant for virtual machines or less restricted environments. The affected code paths date back to approximately 2017 (ESP) and 2023 (RxRPC), meaning a wide range of kernel versions may be impacted.
Affected Products
The full scope is still under investigation, but the following are known or likely affected:
| Product / Distribution | Status |
|---|---|
| Linux Kernel (ESP subsystem) | Affected (since ~2017) |
| Linux Kernel (RxRPC subsystem) | Affected (since ~2023) |
| Ubuntu (multiple versions) | Affected (tested) |
| RHEL 8 / 9 / 10 | Affected |
| CentOS Stream 10 | Affected |
| AlmaLinux 8 / 9 / 10 | Affected |
| Fedora (recent versions) | Affected |
| openSUSE Tumbleweed | Affected |
| OpenShift 4 | Potentially affected |
Note: No complete version matrix is available at this time. The vulnerability was disclosed prior to embargo expiration after details became public due to reverse engineering of the fix.
What steps should security teams take?
Until official patches are released, the following mitigations are recommended:
1. Disable vulnerable kernel modules (temporary mitigation)
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"2. Assess operational impact before applying mitigation
Disabling esp4 / esp6 may break IPsec functionality
Disabling rxrpc may impact AFS-based environments
3. Prioritize patching when available
Monitor vendor advisories and apply kernel updates as soon as released
Some distributions (e.g., AlmaLinux testing repos) have early patched kernels available
4. Harden local access paths
Restrict shell access and enforce least privilege
Ensure SELinux/AppArmor is enforced
Avoid granting unnecessary capabilities (e.g.,
CAP_NET_ADMIN)
5. Monitor for suspicious activity
Detect abnormal privilege escalations
Track execution of compilation tools and exploit-like behavior
Inspect integrity of critical system binaries
6. Post-mitigation cleanup (if compromise suspected)
echo 3 > /proc/sys/vm/drop_cachesHow Can Wiz Help?
Wiz customers can use the pre-built queries and advisory in the Wiz Threat Intel Center to search for relevant instances in their environment. Wiz Research will continue to update that advisory as the situation develops.