If you were still working through the response to Copy Fail last week, we have difficult news: there's a second one.
A new Linux kernel vulnerability was publicly disclosed on May 7, 2026, just days after Copy Fail (CVE-2026-31431) began seeing active exploitation in the wild. It's called Dirty Frag, it carries its own working public exploit, and it affects most of the same systems. Critically, it works even on systems where the Copy Fail mitigation has already been applied.
For organizations running Linux infrastructure, this week has been a difficult one. This article is meant to help non-technical stakeholders understand what Dirty Frag is, why it matters, and what your team should be doing right now.
A quick note on how this one became public
Most serious vulnerabilities go through a coordinated disclosure process: a researcher finds a flaw, notifies the affected vendors privately, and a patch is developed before anything is published. Copy Fail followed that process.
Dirty Frag did not.
Researcher Hyunwoo Kim discovered and privately reported both component vulnerabilities to the Linux kernel security team on April 29–30, 2026, simultaneously submitting patches to the netdev mailing list. The ESP patch was merged into the kernel tree on May 7. That same day, Kim submitted full details to the linux-distros mailing list with a five-day embargo, which is the standard window that allows distributions to prepare and coordinate patched releases before anything goes public.
That five-day window didn't even last a single day. On May 7, an unrelated third party published the exploit publicly, breaking the embargo entirely. Per Kim's pre-agreed terms with distribution maintainers, the full Dirty Frag disclosure followed immediately.
This is meaningful to know. With Copy Fail, organizations had some lead time. With Dirty Frag, the window between "exploit available" and "patch available" was measured in hours for some distributions, and days for others. It is also worth noting that a patch for the RxRPC component (CVE-2026-43500) still did not exist in any upstream tree at the time the exploit went public.
What is Dirty Frag?
Dirty Frag is a Local Privilege Escalation (LPE) vulnerability, which is the same class as Copy Fail. Like its predecessor, it allows any user already present on a Linux system to silently elevate their access to full root (administrator) privileges. A working exploit is publicly available that accomplishes this in a single command.
It is tracked under two CVEs because it chains two distinct kernel flaws together:
- CVE-2026-43284: a flaw in the IPsec ESP (xfrm) subsystem, present since a code commit in January 2017
- CVE-2026-43500: a flaw in the RxRPC networking module, introduced in June 2023
The two vulnerabilities work together by design. Each one covers the gap left by the other, meaning that on virtually any Linux distribution, at least one of the two attack paths will succeed.
The technical mechanism involves the kernel's in-place decryption path; specifically, the way the esp4, esp6, and rxrpc modules handle memory when processing certain network packets. Under specific conditions, an unprivileged process can retain access to memory that the kernel is in the process of modifying, creating a write primitive into the kernel's page cache. The public exploit turns that primitive into root access.
The name "Dirty Frag" refers to the technical mechanism: the exploit corrupts the frag member of the kernel's socket buffer structure (struct sk_buff), placing it in the same lineage as Dirty Pipe and Copy Fail, prior vulnerabilities in the same page-cache write family.
When you combine the introduction dates of the two component flaws, January 2017 for the ESP bug and June 2023 for the RxRPC bug, the effective combined lifetime of the vulnerability class is approximately nine years before it was found.
The full technical write-up from Hyunwoo Kim is available at the Dirty Frag GitHub repository and is recommended reading for any technically oriented staff.
How does Dirty Frag relate to Copy Fail?
Dirty Frag is best understood as a successor to Copy Fail: a new vulnerability in the same broad family, discovered by a different researcher building on the same line of research. The two vulnerabilities share a class of kernel bug (page-cache write primitives) but exploit different code paths through different kernel modules.
This distinction has an important practical consequence: the Copy Fail mitigation does not protect against Dirty Frag. The Copy Fail mitigation blocks the algif_aead kernel module. Dirty Frag does not require that module. An organization that applied the Copy Fail mitigation last week and has not yet patched their kernel is still fully vulnerable to Dirty Frag.
Researcher Kim stated this explicitly in the original disclosure: even on systems where the publicly known Copy Fail mitigation has been applied, Dirty Frag remains exploitable.
Why the two-vulnerability chain matters
Part of what makes Dirty Frag particularly difficult to defend against without patching is the way its two component exploits complement each other.
The ESP exploit (CVE-2026-43284) requires the attacker to create a user namespace, a kernel feature used in container environments. Ubuntu, as a security measure, restricts unprivileged namespace creation through AppArmor, which would normally block this path.
The RxRPC exploit (CVE-2026-43500) does not require namespace creation, but the rxrpc kernel module isn't included in most distributions by default. On RHEL 10.1, for instance, it's not shipped at all.
Ubuntu, however, ships rxrpc by default but blocks namespace creation. RHEL allows namespace creation but doesn't ship rxrpc. By chaining the two exploits, the vulnerability covers both environments: wherever one path is blocked, the other succeeds.
The result is that Dirty Frag works across Ubuntu 24.04.4, RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44, and openSUSE Tumbleweed, which are essentially every major Linux distribution in active use.
The two exploit paths also differ in what they target on disk. The ESP variant rewrites the in-memory copy of /usr/bin/su, replacing it with a tiny root-shell program while leaving the actual file on disk completely untouched. The RxRPC variant targets /etc/passwd, removing the root account's password requirement so that a subsequent call to su - succeeds silently without any credential prompt. In both cases, the attack leaves no trace on the filesystem — only in memory.
Who is affected?
The short answer: if your organization runs Linux servers, virtual machines, containers, or cloud instances, you are almost certainly affected.
The vulnerability is present in the Linux kernel's networking subsystem. AWS has confirmed that the issues affect systems allowing unprivileged users to create sockets or user namespaces, a very common default configuration on Linux systems running web applications, development tooling, or container workloads.
As with Copy Fail, the same practical risk factors apply:
Web applications and external-facing services. Any system running web software with interactive functionality, such as content management systems, application servers, login portals, or APIs, may already have other vulnerabilities that provide an attacker a foothold. Dirty Frag converts that limited foothold into full root access.
Multi-tenant and container environments. Like Copy Fail, Dirty Frag's page-cache write primitive affects shared kernel memory. Organizations running shared hosting, multi-tenant platforms, or container workloads on shared hosts should treat this as an urgent concern.
Compromised accounts and malicious insiders. Any employee, vendor, or contractor with basic shell access to a Linux system can use this exploit to silently escalate to administrator-level access in a single command.
CI/CD pipelines and build systems. Automated systems that pull and execute external code, build pipelines, dependency installers, test runners, represent an execution surface where Dirty Frag could be used as part of a supply-chain attack.
The same detection blind spot
Like Copy Fail, Dirty Frag operates through the kernel's page cache, modifying in-memory representations of files without touching their on-disk contents. A file integrity monitoring tool watching the filesystem would see nothing. File hashes would remain clean. The on-disk data would be unchanged.
Detection requires monitoring at the syscall level. If your organization applied the detection rules from the Copy Fail detection package, those rules will catch some of Dirty Frag's activity, but the different syscall chains used by the new exploit mean additional tuning may be warranted.
What should you do?
1. Apply the immediate mitigation
The good news is that a one-command mitigation blocks both exploit paths. Until you can patch, run the following as root to prevent the vulnerable modules from loading:
sudo 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"
Important caveat: The esp4 and esp6 modules are used by IPsec tunnels. If your organization relies on IPsec for VPN connectivity or site-to-site tunnels, disabling these modules will break that functionality. You can check whether IPsec is currently in use by running:
lsmod | grep -E 'esp4|esp6'
If the modules are not currently loaded, the mitigation is safe to apply. If they are loaded and IPsec is actively configured, work with your networking team before proceeding, and consider the alternative mitigation of disabling unprivileged user namespaces instead (though this only blocks the ESP variant, not the RxRPC path).
AWS additionally recommends checking for all related modules:
lsmod | grep -E 'esp4|esp6|ipcomp4|ipcomp6|rxrpc'
The rxrpc module is used almost exclusively by AFS clients and is not typical for most web-hosting or application servers.
2. Drop the page cache after mitigating
The Dirty Frag exploit can modify legitimate system binaries in page cache as part of gaining root. Applying the module blocklist alone is not sufficient if your system may have been targeted before the mitigation was in place. After applying the mitigation, also flush the page cache:
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
3. Patch your kernel
Patched kernels are now available from most major distributions. Apply updates and reboot to load the new kernel.
| Distribution | Update command |
|---|---|
| Ubuntu / Debian | sudo apt-get update && sudo apt-get upgrade |
| RHEL / Rocky / AlmaLinux | sudo dnf update kernel |
| Amazon Linux | sudo dnf update kernel |
| SUSE / openSUSE | sudo zypper update kernel-default |
| Arch Linux | sudo pacman -Syu |
For AlmaLinux 9 and 10 users, target kernel versions are kernel-5.14.0-611.54.3.el9_7 and kernel-6.12.0-124.55.2.el10_1 respectively, or newer. CloudLinux customers should consult CloudLinux's advisory for stream-specific instructions, including KernelCare livepatch availability.
After updating, reboot to load the patched kernel, then verify:
uname -r
4. Remove the mitigation file after patching
Once a patched kernel is confirmed to be running, remove the blocklist so that IPsec and other affected modules can be used normally if needed:
sudo rm /etc/modprobe.d/dirtyfrag.conf
5. Review your detection coverage
If your organization deployed detection rules for Copy Fail, review whether they need to be extended to cover the different syscall chain used by Dirty Frag. Detection rules and updated guidance will be published to our GitHub repository as they are developed.
A note on the disclosure circumstances
We want to be straightforward about something unusual here: Dirty Frag is the second significant Linux LPE in two weeks, and its public disclosure was uncoordinated, meaning the exploit was available before patches were ready.
In practical terms, this means the window during which your systems were exposed to a public exploit without a vendor patch was unavoidable, not a failure of planning. The right response is the same regardless: apply the mitigation, patch as soon as possible, and verify your detection coverage.
The original technical research from Hyunwoo Kim is available at github.com/V4bel/dirtyfrag, including the full write-up. Red Hat's security bulletin is published at RHSB-2026-003. The AWS security bulletin is at 2026-027-AWS.
Summary
| CVEs | CVE-2026-43284 (ESP/xfrm), CVE-2026-43500 (RxRPC) |
| Nickname | Dirty Frag |
| Type | Local Privilege Escalation (LPE) |
| Affected | Linux kernels across all major distributions; ESP flaw since January 2017, RxRPC flaw since June 2023 |
| Exploit complexity | Trivial — single command, no race condition, high success rate |
| Bypasses Copy Fail mitigation? | Yes — fully exploitable even with algif_aead blocklist applied |
| Immediate mitigation | Blocklist esp4, esp6, and rxrpc modules (see above) |
| Full fix | Kernel update from your distribution vendor |
| Drop page cache after mitigation? | Yes — recommended |
If you need help assessing whether your systems are affected, applying the mitigation, or extending your detection coverage to include Dirty Frag, get in touch. Two significant Linux LPEs in two weeks is a situation that warrants a careful look at your overall Linux security posture — and that's exactly the kind of review CrowdSOC can help with.