Impact statement: CVE-2026-43284, known as Dirty Frag, is a Linux kernel local privilege-escalation issue affecting the networking stack on many modern Linux servers. A companion issue is being tracked as CVE-2026-43500. This is not unauthenticated internet remote code execution, but it is serious on shared hosting, container hosts, CI runners, Proxmox nodes, and any Linux system where untrusted users or workloads can run code.
The practical risk is simple: if a low-privilege account, compromised website, container workload, developer job, or customer shell already exists on the server, Dirty Frag may help turn that foothold into root. Patch as soon as your Linux vendor ships a fixed kernel. If your vendor has not shipped one yet, use the temporary module mitigation after checking whether the server depends on IPsec or AFS.
Who Needs To Act First
- Shared hosting and reseller hosting servers, including cPanel/WHM, Plesk, DirectAdmin, Webmin, and Virtualmin nodes.
- CloudLinux, AlmaLinux, Rocky Linux, RHEL, Debian, Ubuntu, and other Linux servers running kernels from roughly 4.14 forward.
- Proxmox VE, Proxmox Backup Server, and container-heavy virtualization hosts.
- CI/build servers, shell servers, student lab systems, bastion hosts, and developer workstations where untrusted users or jobs exist.
- Linux machines that already applied Copy Fail guidance. Dirty Frag is a separate issue and needs its own patch or mitigation.
Check The Server Before You Mitigate
Before blocking kernel modules, confirm whether the server depends on IPsec, strongSwan, Libreswan, or AFS. Disabling the affected modules can interrupt IPsec VPN traffic and AFS clients. On a typical web-hosting server they are often unused, but check first.
uname -r
lsmod | egrep '^(esp4|esp6|rxrpc)b' || true
ip xfrm state 2>/dev/null | head
systemctl list-units --type=service --all | egrep -i 'strongswan|libreswan|ipsec|openafs|afs' || true
If this host terminates IPsec VPNs, carries site-to-site tunnels, or depends on AFS, do not blindly apply the module mitigation. Follow your OS vendor’s alternate guidance, test in a maintenance window, and prioritize a patched kernel or livepatch.
Temporary Mitigation When A Fixed Kernel Is Not Ready
If your server does not rely on IPsec or AFS, block the affected modules from loading and unload them if they are already present. This is a bridge until the fixed kernel or KernelCare livepatch is installed, not a replacement for patching.
sudo tee /etc/modprobe.d/dirtyfrag.conf >/dev/null <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF
sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null || true
lsmod | egrep '^(esp4|esp6|rxrpc)b' || true
If you believe the server may have been exposed before mitigation, drop the page cache after blocking the modules. This can cause a temporary performance dip while the system warms the cache again.
sudo sync
echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null
Patch Guidance By Server Type
AlmaLinux, Rocky Linux, RHEL, and CloudLinux: follow the vendor tracker for your exact release. When the fixed kernel reaches your approved repository, update kernel packages, reboot, and confirm the running kernel changed.
sudo dnf clean all
sudo dnf update 'kernel*'
sudo reboot
uname -r
CloudLinux with KernelCare: use KernelCare when coverage is available for your running kernel, then verify the livepatch reports Dirty Frag coverage.
sudo kcarectl --update
sudo kcarectl --patch-info | grep CVE-2026-43284 || true
Ubuntu and Debian: check the Ubuntu or Debian tracker for your release. When packages are available, update, reboot, and confirm the running kernel. If packages are not available yet, keep the temporary mitigation in place unless it breaks required VPN or AFS workloads.
sudo apt update
sudo apt full-upgrade
sudo reboot
uname -r
Proxmox VE and Proxmox Backup Server: treat this as a Debian-kernel maintenance item. Snapshot or verify backups first, migrate or shut down guests safely, drain one node at a time, update the kernel, reboot, and confirm cluster health before moving to the next node.
pveversion -v 2>/dev/null || true
uname -r
apt update
apt full-upgrade
reboot
Revert The Temporary Mitigation After Patching
After the host is running a fixed kernel or verified livepatch, remove the temporary module block if the server needs IPsec or AFS again. If the modules are not needed, leaving the block in place is usually acceptable, but document it so the next admin understands why it exists.
sudo rm -f /etc/modprobe.d/dirtyfrag.conf
sudo depmod -a
Defender Review Checklist
- Confirm every Linux node is either patched, livepatched, or temporarily mitigated.
- Prioritize multi-user hosts, shared hosting, containers, CI, and virtualization nodes before single-purpose internal servers.
- Watch for unexpected root logins, new privileged files, new cron jobs, or unusual service changes after May 7, 2026.
- For hosting providers, review accounts that already showed malware, suspicious PHP, stolen credentials, or repeated abuse reports.
- Tell customers whether you patched, livepatched, or temporarily mitigated, and whether any maintenance reboot is still planned.
last -a | head -20
journalctl --since "2026-05-07" -p warning | tail -200
find / -xdev -perm -4000 -type f -mtime -7 -ls 2>/dev/null
Sources
- Plesk: Vulnerability CVE-2026-43284
- CloudLinux: Dirty Frag local privilege escalation
- Ubuntu: Dirty Frag Linux vulnerability fixes and mitigations
- Ubuntu CVE tracker for CVE-2026-43284
- Red Hat: Dirty Frag security bulletin
- AlmaLinux: Dirty Frag fix readiness
- Debian security tracker for CVE-2026-43284
- NVD: CVE-2026-43284
