Dirty Frag CVE-2026-43284 CVE-2026-43500

Last updated: 2026-05-08
Status: mitigation available now — patched kernels are landing per-stream; KernelCare livepatches are in build/test.

Disclaimer: This page is provided for informational purposes only. We make no guarantees as to the accuracy, completeness, or applicability of the information to your specific environment, and the situation described here can change at any moment. Always verify with the official channels of your distribution before applying any changes to production systems. You apply any commands or instructions on this page at your own risk; Yourwebhoster.eu accepts no liability for damage, downtime, or data loss resulting from following them, in particular on systems we do not manage.

To avoid unrecoverable situations, always make a back-up and/or snapshot of your system so you can easily roll back if any issues occur.

CRITICAL: Do NOT apply the mitigation below on hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels. The mitigation disables the kernel-side ESP transforms and will break those tunnels. Use a patched kernel or KernelCare livepatch on those hosts instead.

Page changelog

2026-05-08 — Page published. Initial publication with overview of affected systems, mitigation, and patch availability.

What is Dirty Frag?
Dirty Frag is a critical local privilege escalation in the Linux kernel disclosed on 2026-05-07 by researcher Hyunwoo Kim — one week after Copy Fail (CVE-2026-31431) by the same researcher. The flaw lives in the in-place decryption path of the esp4, esp6, and rxrpc kernel modules. Any unprivileged local user can use the publicly available exploit to gain root in a single command.

The vulnerability is split across two CVEs: CVE-2026-43284 covers the IPsec ESP path (esp4 / esp6) and is the relevant one for typical hosting servers. CVE-2026-43500 covers the rxrpc half, which is only loaded on AFS clients and is not shipped at all on AlmaLinux 8 or CloudLinux 8 — for the average web-hosting box you can effectively treat this as a single vulnerability.

An early proof-of-concept repository named “Copy Fail 2: Electric Boogaloo” circulating on GitHub refers to this same vulnerability under that alias. There is no separate “Copy Fail 2” CVE.

For shared hosting environments with multiple tenants this is a serious risk: any user with shell access can become root on the host node in a single command. The exploit modifies binaries in the page cache as part of gaining root, so even after applying the mitigation the page cache must be flushed (see below). For KVM virtual machines, this is not a VM escape — but every guest is independently vulnerable inside its own kernel.

The responsible-disclosure embargo was broken before distributions could coordinate, so a working public exploit was available from day one. Treat this as urgent.

Status of our infrastructure
We have applied the temporary mitigation across our affected infrastructure and are validating impact on hosts that use IPsec for site-to-site connectivity. As patched kernels land in stable channels for each distribution — or as KernelCare livepatches become available — we will roll out the definitive fix.

Patch availability per distribution

The situation differs per distribution. Always verify the current status with the official channels — the table below is a snapshot from 2026-05-08.

Mitigation if the patched kernel is not yet available

Unlike Copy Fail, the affected modules (esp4, esp6, rxrpc) are loadable kernel modules on every major distribution — including the RHEL family. The same modprobe-blacklist mitigation works everywhere; no boot-parameter approach or reboot is required.

DO NOT run this on hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels. esp4 and esp6 are the kernel-side ESP transforms used by IPsec — disabling them will break those tunnels. On IPsec hosts, wait for the patched kernel or use a KernelCare livepatch instead.

rxrpc is the AF_RXRPC transport used almost exclusively by AFS clients and is not present on typical web-hosting servers — it is safe to disable in the vast majority of cases.

Apply the mitigation:

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"

Verify the modules are gone:

lsmod | grep -E '^(esp4|esp6|rxrpc)\s'

If the output is empty, the mitigation is in place.

Required follow-up: drop the page cache
The exploit can modify legitimate system binaries in the page cache as part of gaining root. Applying the mitigation alone is not enough on systems that may have been targeted before it was in place. After mitigating, drop the page cache so that any modified binaries are re-read from disk on the next access:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Note that sudo echo 3 > /proc/sys/vm/drop_caches does not work because shell redirection happens in the user's shell, not under sudo. Use the sh -c form above.

Revert after the patched kernel is installed:

sudo rm /etc/modprobe.d/dirtyfrag.conf

Compatibility: SSH, dm-crypt / LUKS, kTLS, and standard OpenSSL / GnuTLS builds do not depend on these modules and continue to work after applying the mitigation. IPsec / strongSwan / Libreswan tunnels will stop working as long as esp4 / esp6 are blocked — see the warning above. AFS clients depending on rxrpc will lose connectivity (very rare on hosting servers).

Recommendations

1. Apply the temporary mitigation now. The public exploit is available and trivial to use; every hour without mitigation is exposure. Use the modprobe-blacklist command above, then drop the page cache. Skip this step only on hosts that actively use IPsec.

2. Update the kernel as soon as possible. For CloudLinux 9 / 10 and AlmaLinux 8 / 9 / 10 a patched kernel is already available in the testing repository. CloudLinux 7h and 8 rebuilds are pending release. Schedule a reboot and install the update once the kernel reaches the stable channel for your distribution.

3. Consider KernelCare for future kernel CVEs. KernelCare applies kernel patches without rebooting. KernelCare livepatches for Dirty Frag are in active build/test and are expected to land in the main feed shortly. For this CVE we are offering one month of KernelCare free of charge for all servers you have with us — shared hosting, VPS, dedicated, managed or unmanaged, any product type. Send an email to support@yourwebhoster.eu mentioning the server(s) you'd like to activate it for. To confirm coverage for your specific kernel, see the KernelCare patch tracker for CVE-2026-43284.

4. Always check the official status page of your distribution for the latest updates, since the situation can change hour by hour.

External status pages

CloudLinux Status Page — Dirty Frag incident
status.cloudlinux.com
KernelCare patch tracker — CVE-2026-43284
AlmaLinux — Dirty Frag advisory
Debian Security Tracker — CVE-2026-43284
Ubuntu Security — CVE-2026-43284
Red Hat Security — CVE-2026-43284

Sources & further reading

dirtyfrag.io — researcher write-up
GitHub — canonical PoC (V4bel)
CloudLinux Blog — Dirty Frag advisory
oss-security — original disclosure (Hyunwoo Kim, 2026-05-07)
NVD — CVE-2026-43284
CloudLinux KB — Dirty Frag
Upstream kernel fix (commit f4c50a4034e6)
lore.kernel.org — netdev thread

Related

Copy Fail (CVE-2026-31431) — status & updates — the previous related CVE from one week earlier.

Questions? Send an email to support@yourwebhoster.eu or open a ticket. This page will be updated as new information or progress becomes available.