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:

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)

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)

How 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.

References

• Dirty Frag github

• Alma Linux advisory 

• RedHat advisory

• Cloud Linux advisory

• AWS advisory