Mitigating Copy Fail, Dirty Frag and the DirectAdmin 1.711 TLS privilege escalation

Shared hosting servers give untrusted code a local shell, in effect, through PHP, cron and SSH. A local privilege escalation in the kernel or in the panel is therefore a full compromise, not a theoretical one. 2026 has produced three kernel LPEs that matter on every DirectAdmin host, plus a privilege escalation in DirectAdmin’s own new TLS system that 1.711 fixed on 2026-09-22. This guide applies all four mitigations and shows how to confirm each one.

Short answer: Update DirectAdmin to 1.711 or later with da update, block the algif_aead, esp4, esp6 and rxrpc modules with install ... /bin/false lines under /etc/modprobe.d/, and apply the fixed distribution kernel or a KernelCare patch. Then confirm with lsmod, modprobe -n -v and da version after a reboot that none of the modules load and the panel is on the fixed release.

Update DirectAdmin first

The TLS-system flaw allowed a local user to escalate through the certificate provisioning path added in 1.706. The fix is in 1.711 and there is no configuration workaround, so the first step on any server running 1.706 to 1.710 is the update:

da version
da update
systemctl restart directadmin

Servers on the stable channel with automatic updates on will already have it; confirm rather than assume. If da update fails, DirectAdmin license errors and update failures covers the causes.

Copy Fail (CVE-2026-31431)

Disclosed on 2026-04-29, Copy Fail abuses the algif_aead kernel module, part of the userspace crypto API. Nothing on a hosting server uses that interface, so the mitigation is to prevent the module from loading and to remove it if loaded:

echo 'install algif_aead /bin/false' > /etc/modprobe.d/copyfail.conf
rmmod algif_aead 2>/dev/null
lsmod | grep algif

The install line makes any future load attempt run /bin/false instead. Because the module can also be pulled in at boot, add the initcall blacklist to the kernel command line as a second layer:

grubby --update-kernel=ALL --args='initcall_blacklist=algif_aead_init'

On Debian and Ubuntu, add the parameter to GRUB_CMDLINE_LINUX in /etc/default/grub and run update-grub. The parameter takes effect at the next reboot; the modprobe rule takes effect immediately.

Dirty Frag (CVE-2026-43284 and CVE-2026-43500)

Disclosed on 2026-05-07 and exploited in the wild soon after, Dirty Frag involves the xfrm ESP path and the RxRPC socket family. Hosting servers do not need either unless they terminate IPsec tunnels or use AFS. Blacklist all three 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

If the server runs a site-to-site IPsec VPN, this breaks it. In that case the only mitigation is the patched kernel or a live patch; do not blacklist and hope.

Fragnesia (CVE-2026-46300, 2026-05-13) is a bypass of the early Dirty Frag patches via ESP-in-TCP. The module blacklist above covers it because the ESP modules never load; on a server that cannot blacklist them, only a kernel built after mid-May 2026 is safe.

Patch the kernel or live-patch it

The blacklists are stopgaps. Apply the distribution kernel that fixes all three and reboot, or, on servers that cannot reboot on demand, use KernelCare, which patches EL8, EL9, Ubuntu 22.04 and Debian 12 in place:

dnf update kernel -y
kcarectl --update
kcarectl --info

kcarectl --info lists the effective kernel version after patching; compare it with the fixed versions in your distribution’s advisory. After a kernel patch, drop the page cache once so any exploit primitives that relied on cached pages are cleared: echo 3 > /proc/sys/vm/drop_caches. Our KernelCare setup guide covers the install.

Reduce the attack surface generally

Two sysctl settings close the door on most future module-based and namespace-based LPEs at the cost of some flexibility. Locking module loading after boot prevents any new module from being loaded, which also blocks CSF from loading iptables modules if they are not already present, so set it late in boot and test the firewall afterwards. Disabling user namespaces removes a primitive used by many exploits and is safe on a server that does not run rootless containers:

cat > /etc/sysctl.d/99-lpe-hardening.conf <<'EOF'
kernel.modules_disabled = 1
user.max_user_namespaces = 0
EOF
sysctl --system

kernel.modules_disabled is one-way until reboot. Apply it via a systemd unit that runs after CSF has started so the firewall’s modules are already loaded. Check the full list of hardening items in our server security audit.

Common pitfall: the blacklist file that is not read

A modprobe file without the .conf suffix is ignored, and a blacklist line only prevents automatic loading, not an explicit modprobe by a process with the capability. Use install ... /bin/false, which blocks both, and confirm the file name ends in .conf. The other frequent miss is applying the rules on the host but not on a container-based setup that shares the kernel; the kernel is one, so mitigations belong on whatever owns it.

Verify

Run the checks below after a reboot as well as immediately, because the boot-time state is what matters on a long-running server:

da version
lsmod | grep -E 'algif_aead|esp4|esp6|rxrpc' || echo 'modules not loaded'
modprobe -n -v algif_aead
grep -o 'initcall_blacklist=[^ ]*' /proc/cmdline
sysctl kernel.modules_disabled user.max_user_namespaces
uname -r
kcarectl --info 2>/dev/null

modprobe -n -v shows install /bin/false for a blocked module. da version should report 1.711 or later. Record the outputs with the date; the next advisory in this series will arrive, and having a baseline makes the next round a comparison rather than a rediscovery.

DirectAdmin 1.711 TLS privilege escalation at a glance

Official documentation: DirectAdmin documentation, AlmaLinux wiki, Linux man pages.

Related guides: KernelCare on cPanel and DirectAdmin servers: setup, verification and rollback · CSF after ConfigServer: which fork should you run in 2026 (cPanel, DirectAdmin, Aetherinox, Sentinel)? · Installing Sentinel Firewall as a drop-in CSF replacement on Ubuntu 24.04 and Debian 13.

Frequently asked questions