ZDI-CAN-33367: leaked kernel local root zero-day on CloudLinux

ZDI-CAN-33367 is a Linux kernel local privilege escalation in skb_zerocopy(). Zero Day Initiative sent it to the kernel security team on 21 October 2026 and, by mistake, to public mailing lists, along with four other kernel reports. A working exploit is public, there is no CVE ID yet, and the upstream fix had not been merged into mainline at the time of writing.

It matters for hosts because the attacker only needs local code execution: an SSH user, a cron job, or a PHP shell on a compromised WordPress site. TuxCare got root with the public exploit on AlmaLinux 8–10, CloudLinux 9 and 10, Debian 12 and 13, and Ubuntu 24.04 and 26.04. As of 27 October nobody had reported exploitation in the wild.

What the bug does

The bug lets a user write into the page cache of files they can only read, which is a short step to root. It is a gap in the Dirty Frag fix (CVE-2026-43284) from May: that fix marks shared page-cache pages so the IPsec ESP code copies them before decrypting, but skb_zerocopy() drops the marker, so ESP decrypts in place. A kernel with the Dirty Frag fix, or with the fix for CVE-2026-90049 in the same function, is still vulnerable.

The public exploit needs two things:

• Unprivileged user namespaces (user.max_user_namespaces above 0).
• These modules, loadable on demand: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred, esp4, and xfrm_user.

Which CloudLinux versions are exposed

Don't go by install date. Check the box:

sysctl user.max_user_namespaces

0 means ordinary accounts can't create namespaces and the public exploit path is closed. Any other value on an affected kernel means the server is exposed.

Mitigate now without a reboot

Turn off unprivileged user namespaces:

echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

This breaks rootless Podman and Docker, unprivileged LXC, Flatpak, and some browser sandboxes for ordinary accounts. On a typical shared cPanel or Plesk node none of those should be running as customers. To undo it, delete the file and run sysctl --system again. If you applied this for PwnEscape, you're already covered.

Where you can't disable namespaces, blocking two of the modules is a weaker fallback that CloudLinux has not verified against every variant. Check nobody uses tc pedit or nlmon first:

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '

If lsmod prints anything, the module is already loaded and the block only takes effect after a reboot.

Fixed kernels

CloudLinux released beta kernels on 26 October:

• CloudLinux 8: kernel-4.18.0-553.177.1.lve.1.el8
• CloudLinux 7 hybrid: kernel-4.18.0-553.177.1.lve.1.el7h

yum update 'kernel*' --enablerepo=cloudlinux-updates-testing   # CL8
yum update 'kernel*' --enablerepo=cl7h_beta                    # CL7 hybrid
reboot
uname -r

There was no CloudLinux 9 or 10 build at the last advisory update. Plain AlmaLinux 9 cPanel servers have a fix in 5.14.0-687.60.1.el9_8; AlmaLinux 8 and 10 kernels were still in testing.

KernelCare status

Livepatches are the faster route, with no reboot:

• EL10 / CloudLinux 10: released 23 October to production and ePortal feeds.
• EL9 / CloudLinux 9: TuxCare's 27 October update lists it as released to the production feed, not yet ePortal.
• EL8 / CloudLinux 8: ready for release; CloudLinux 7 hybrid in preparation.
• CloudLinux 8 ELS: no live-patching stream. Use the sysctl.
• Debian and Ubuntu: in progress, no date.

kcarectl --update
kcarectl --patch-info | grep -i 33367

Use --patch-info, not --info, which doesn't list this issue even on a patched server. ePortal users should push the feed manually, and Imunify360 servers may already have KernelCare included.

The other leaked reports

Two ksmbd bugs (ZDI-CAN-33774 and ZDI-CAN-33549, both CVSS 9.0) are remote, but ksmbd isn't built on AlmaLinux or CloudLinux 9 and 10. On Debian or Ubuntu boxes, run systemctl disable --now ksmbd if you don't use it. The vmwgfx and nvmet reports have no public detail yet.

Next steps

• Compare reboot windows with livepatching in live patching for hosting fleets, then cover every node with a KernelCare license.
• Last week's kernel bugs need separate fixes: see Infinity Core CVE-2026-98260.
• Still on CloudLinux 7 hybrid or 8? Plan the move to CloudLinux OS 10 on a CloudLinux license.