Last updated: 9 May 2026
Summary
A Linux kernel local privilege escalation vulnerability known as Dirty Frag has been disclosed. It is tracked mainly as:
- CVE-2026-43284 — IPsec ESP /
esp4/esp6 - CVE-2026-43500 — RxRPC /
rxrpc
Dirty Frag may allow a local unprivileged user to gain root privileges. It is not a direct remote network exploit, but it is serious for hosting servers because an attacker may first gain limited access through a compromised website, SSH/SFTP account, container workload, or local user account. cPanel confirms that the issue affects the Linux kernel itself and is present across multiple Linux distributions. (cPanel Support)
Affected systems
Dirty Frag affects multiple Linux distributions and kernel streams. Confirmed affected platforms include:
- AlmaLinux 8, 9, 10
- Rocky Linux 8, 9, 10
- CloudLinux 7 Hybrid, 8, 9, 10
- Red Hat Enterprise Linux 8, 9, 10
- Ubuntu 20.04, 22.04, 24.04 and other supported Ubuntu releases
- Oracle Linux systems using affected RHCK or UEK kernels
- Other Linux distributions using affected kernel versions
CloudLinux confirms that CloudLinux 7 standard is not affected, while CloudLinux 7 Hybrid, 8, 9 and 10 are affected. CloudLinux 9 and 10 use the AlmaLinux kernel stream. (CloudLinux Blog)
Required action
The recommended fix is to install the vendor-patched kernel and reboot the server.
Check the current kernel:
uname -r
After updating and rebooting, verify again:
uname -r
Installing the kernel package alone is not enough. The server must boot into the patched kernel.
OS-specific update instructions
AlmaLinux 8 / 9 / 10
Update the kernel:
dnf clean metadata
dnf update 'kernel*' -y
reboot
Verify:
uname -r
rpm -q kernel
Expected patched versions:
AlmaLinux 8: kernel-4.18.0-553.123.2.el8_10 or newer
AlmaLinux 9: kernel-5.14.0-611.54.3.el9_7 or newer
AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer
AlmaLinux confirms these patched kernel versions in its Dirty Frag advisory. (AlmaLinux OS)
CloudLinux
CloudLinux 7 Hybrid / 8
If the patched kernel is available in stable repositories:
yum update 'kernel*' -y
reboot
uname -r
If the patched kernel is only available in the testing/beta repository:
For CloudLinux 8:
yum --enablerepo=cloudlinux-updates-testing update 'kernel*' -y
reboot
uname -r
For CloudLinux 7 Hybrid:
yum --enablerepo=cl7h_beta update 'kernel*' -y
reboot
uname -r
Expected patched versions:
CloudLinux 7 Hybrid: kernel-4.18.0-553.123.2.lve.el7h or newer
CloudLinux 8: kernel-4.18.0-553.123.2.lve.el8 or newer
CloudLinux lists these target versions for the CL7h and CL8 patched kernel streams. (CloudLinux Blog)
CloudLinux 9 / 10
CloudLinux 9 and 10 use the AlmaLinux kernel stream. If the patched kernel is available from stable repositories:
dnf update 'kernel*' -y
reboot
uname -r
Expected patched versions:
CloudLinux 9: kernel-5.14.0-611.54.3.el9_7 or newer
CloudLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer
If the patched kernel is not yet visible from stable repositories or local mirrors, use the AlmaLinux testing repository temporarily.
For CloudLinux 10:
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*' -y
reboot
After reboot:
uname -r
dnf config-manager --disable almalinux-testing
For CloudLinux 9:
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*' -y
reboot
After reboot:
uname -r
dnf config-manager --disable almalinux-testing
Only use the testing repository to update the kernel packages, then disable it immediately after verification. CloudLinux documents this temporary testing-repository flow for CL9 and CL10. (CloudLinux Blog)
RHEL / Rocky Linux / Oracle Linux
For RHEL-family systems:
dnf clean all
dnf update 'kernel*' -y
reboot
For Oracle Linux systems using UEK, also update UEK packages:
dnf update 'kernel*' 'kernel-uek*' -y
reboot
Verify:
uname -r
rpm -q kernel kernel-core kernel-uek 2>/dev/null
Red Hat confirms Dirty Frag affects RHEL 8, 9, 10 and OpenShift 4, and recommends kernel updates or mitigation depending on patch availability. (Red Hat Customer Portal)
Ubuntu / Debian
Update the system kernel:
apt update
apt full-upgrade -y
reboot
Verify:
uname -r
dpkg -l | grep linux-image
Ubuntu confirms the fix is delivered through Linux kernel image packages and recommends rebooting into the updated kernel. (Ubuntu)
SUSE / openSUSE
Update the kernel:
zypper refresh
zypper update kernel-default
reboot
Verify:
uname -r
rpm -qa | grep kernel
Temporary mitigation
If a patched kernel or livepatch is not yet available, block the affected modules:
cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF
rmmod esp4 esp6 rxrpc 2>/dev/null || true
Verify:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"
This mitigation blocks esp4, esp6, and rxrpc, which are the affected kernel module paths. CloudLinux, Ubuntu, and Red Hat all document this module-blocking approach as temporary mitigation. (CloudLinux Blog)
Important warning
Do not apply this mitigation without review on systems using:
- IPsec
- StrongSwan
- Libreswan
- VPN gateways
- AFS / RxRPC workloads
Blocking esp4 and esp6 can break IPsec traffic, and blocking rxrpc can affect AFS/RxRPC workloads. Ubuntu and Red Hat both note this operational impact. (Ubuntu)
Ubuntu / Debian additional step
On Ubuntu and Debian systems, regenerate initramfs after applying the mitigation:
update-initramfs -u -k all
Then verify again:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"
Ubuntu recommends regenerating initramfs so the affected modules remain blocked during boot. (Ubuntu)
Drop page cache after mitigation
After applying mitigation, drop page cache:
sync
echo 3 > /proc/sys/vm/drop_caches
This does not replace patching. It only clears cached pages after mitigation. CloudLinux notes that the exploit can modify legitimate system binaries in page cache, so dropping page cache is recommended after mitigation on potentially targeted systems. (CloudLinux Blog)
Remove mitigation after patching
After the patched kernel is installed and the server has rebooted into it:
rm -f /etc/modprobe.d/dirtyfrag.conf
For Ubuntu / Debian:
update-initramfs -u -k all
Reboot if required:
reboot
KernelCare
If KernelCare is installed:
kcarectl --update
Verify coverage:
kcarectl --patch-info | grep -E 'CVE-2026-43284|CVE-2026-43500|Dirty Frag'
If the CVE does not appear in the output, KernelCare may not yet cover the running kernel. In that case, apply the vendor kernel update or temporary mitigation. cPanel and CloudLinux both reference KernelCare as an available livepatch path where coverage exists. (cPanel Support)
Verification checklist
Run the following after patching or mitigation:
cat /etc/os-release
uname -r
For RHEL-family systems:
rpm -q kernel kernel-core kernel-uek 2>/dev/null
For Ubuntu / Debian:
dpkg -l | grep linux-image
Check affected modules:
lsmod | grep -E 'esp4|esp6|rxrpc'
Confirm mitigation status:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"
EuroVPS recommendation
EuroVPS recommends the following actions:
- Check the server operating system and running kernel.
- Apply the vendor-patched kernel as soon as available.
- Reboot into the patched kernel.
- Verify the active kernel with
uname -r. - If no patched kernel or livepatch is available, apply the temporary mitigation.
- Drop page cache after applying mitigation.
- Restrict unnecessary SSH, SFTP, shell, and panel access.
- Review compromised websites, suspicious local users, and unexpected privilege escalation activity.
- Migrate unsupported or end-of-life operating systems to a supported OS.
Need assistance?
EuroVPS customers who require assistance can open a support ticket from the EuroVPS Client Area.
Our team can help with:
- checking whether your server is affected
- reviewing the running kernel
- applying vendor kernel updates
- applying temporary mitigation where appropriate
- rebooting the server into the patched kernel
- verifying the fix after reboot
- advising on unsupported or end-of-life operating systems
For managed servers where EuroVPS has root access, we can assist with applying the required updates or mitigation.