Vulnerability CVE-2026-43284: Dirty Frag

Gilson Siqueira

Updated May 11, 2026 14:05

Plesk for Linux kb: technical kb: security

Situation

Vulnerability CVE-2026-43284, known as "Dirty Frag", has been discovered in the Linux Kernel.

The flaw is in the in-place decryption path of the esp4, esp6, and rxrpc modules. When the receive path decrypts over paged buffers not privately owned by the kernel, unprivileged processes can retain references to the resulting plaintext, yielding a write primitive into the page cache. A public proof-of-concept exists that turns this into a root escalation in a single command.

Linux kernels since approximately 2017 (starting around version 4.14) are affected.

Impact

All servers running a kernel version after 2017 (starting around Linux version 4.14) are potentially vulnerable.

Operating systems potentially affected:

Ubuntu 24.04, Ubuntu 22.04, Ubuntu 20.04, Ubuntu 18.04
AlmaLinux 10.x, AlmaLinux 9.x, AlmaLinux 8.x — AlmaLinux advisory
Debian 13, Debian 12, Debian 11, Debian 10
CloudLinux 10.x, CloudLinux 9.x, CloudLinux 8.x (CL7h) — CloudLinux advisory
Red Hat Enterprise Linux 9.x, Red Hat Enterprise Linux 8.x
Rocky Linux 8.x

Note: CloudLinux 7 (CL7) is not affected.

Call to Action

KernelCare

If KernelCare is installed, the running kernel can be patched without a reboot.

el8 family (CL7h, CL8, AlmaLinux 8) — patches available in the testing feed now:

# kcarectl --update --prefix test

Verify coverage:

# kcarectl --patch-info | grep CVE-2026-43284

If CVE-2026-43284 appears in the output, the patch is applied. These patches will be promoted to the main feed later today (2026-05-08). Once available in the main feed, a standard update is sufficient:

# kcarectl --update

el9 family (CL9, AlmaLinux 9) — livepatch in progress. Check the CloudLinux status page for release timing.

If patching is not available, either of the following indicates that KernelCare does not currently cover CVE-2026-43284 for the running kernel:

kcarectl --update returns: There are no updates for this kernel yet
kcarectl --patch-info | grep CVE-2026-43284 produces no output

In this case, proceed to the relevant OS tab and apply the temporary mitigation at the bottom of this article while waiting for a patched kernel.

CloudLinux

CL7 is not affected. For all other affected versions, patched kernels are being built. Refer to the CloudLinux advisory for current per-stream status and update timing.

CL7h and CL8 — rebuilds based on the AlmaLinux 8 fix (kernel-4.18.0-553.123.2.el8_10). Once available in the beta channel:

CL8:

# yum --enablerepo=cloudlinux-updates-testing update 'kernel*'

# reboot

# uname -r

CL7h:

# yum --enablerepo=cl7h_beta update 'kernel*'

# reboot

# uname -r

Once promoted to the stable channel, no extra repo flag is needed:

# yum update 'kernel*'

# reboot

# uname -r

CL9 and CL10 use the AlmaLinux kernel directly — see the AlmaLinux tab.

Until a patched kernel is available, apply the temporary mitigation at the bottom of this article.

AlmaLinux

Patched kernels are available in the AlmaLinux testing repository. Refer to the AlmaLinux advisory for details.

Patched versions:

AlmaLinux 8: kernel-4.18.0-553.123.2.el8_10 and above
AlmaLinux 9 / CL9: kernel-5.14.0-611.54.3.el9_7 and above
AlmaLinux 10 / CL10: kernel-6.12.0-124.55.2.el10_1 and above

To install from the testing repository, enable it first:

AlmaLinux 10 / CL10:

# dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm

# dnf update 'kernel*'

# reboot

# uname -r

# dnf config-manager --disable almalinux-testing

AlmaLinux 9 / CL9:

# dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm

# dnf update 'kernel*'

# reboot

# uname -r

# dnf config-manager --disable almalinux-testing

Once promoted to production repositories, a plain update is sufficient:

# dnf update 'kernel*'

# reboot

# uname -r

Red Hat / Rocky Linux

Red Hat Enterprise Linux / Rocky Linux

CVSS v3.1: 7.8 (Important). Patches are not yet available. Apply the temporary mitigation at the bottom of this article while waiting.

For the ESP/XFRM variant specifically, an alternative mitigation for systems that cannot disable the esp4/esp6 modules (e.g. servers running IPsec) is to disable unprivileged user namespaces, since exploitation relies on creating user and network namespaces:

# echo 0 /proc/sys/user/max_user_namespaces

Note: This may affect containers and other workloads that depend on unprivileged user namespaces. Test before applying in production.

Refer to the Red Hat Security Bulletin for current patch status and further guidance:
https://access.redhat.com/security/vulnerabilities/RHSB-2026-003

To apply updates once available:

# dnf update 'kernel*'

# reboot

# uname -r

Ubuntu

No patched kernels are available yet; all supported releases (18.04 through 24.04) are currently under evaluation. Apply the temporary mitigation at the bottom of this article while waiting.

Refer to the Ubuntu blog for mitigation details:
https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available

Check the Ubuntu security tracker for patch availability:
https://ubuntu.com/security/CVE-2026-43284

To apply updates once available:

# apt update

# apt upgrade

# reboot

# uname -r

Debian

A fix is currently available only in sid (unstable): linux 7.0.4-1 and above. All stable releases (bullseye, bookworm, trixie, and forky) remain vulnerable.

Note: No patched kernel is available yet for any Debian stable release. Proceed with the temporary mitigation at the bottom of this article.

Check the Debian security tracker for patch availability:
https://security-tracker.debian.org/tracker/CVE-2026-43284

To apply updates once patches reach your branch:

# apt update

# apt upgrade

# reboot

# uname -r

Temporary mitigation

Until a patched kernel or KernelCare livepatch is installed, blacklist the esp4, esp6, and rxrpc modules to prevent them from loading, and unload them if already present:

# 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"

What these modules are and how disabling them affects the server:

esp4 / esp6 — Kernel-side ESP transforms used by IPsec. On a typical hosting server these are not used, so disabling them has no practical impact. Warning: Do not apply this mitigation on hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels, as it will interrupt that VPN connectivity.
rxrpc — The AF_RXRPC transport used almost exclusively by AFS (Andrew File System) clients. Not present on typical hosting servers; disabling it has no impact on standard hosting workloads.

This mitigation does not require a reboot and can be reversed at any time after a patched kernel is installed:

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

Drop page cache after mitigating

The exploit can modify legitimate system binaries in the page cache before gaining root. If the server was potentially targeted before the mitigation was applied, drop the page cache after mitigating:

# echo 3 /proc/sys/vm/drop_caches

Imunify360 users

IOCs associated with this exploit have been identified and the related script has been blacklisted in Imunify360. This is an additional layer of defense — it does not replace the kernel update.