ZDI-CAN-33367: zero-day Linux kernel root in CloudLinux, mitigation
CVE-less flaw in Linux kernel network stack grants local root access. Public exploit exists; livepatch available only for CloudLinux 10.
UptimeMag editorial team · 24 October 2026 · 2 min read
Anyone running shared hosting on CloudLinux faces an open issue since 22 October: a flaw in the Linux kernel, tracked as ZDI-CAN-33367 and lacking a CVE identifier, allows any local user to overwrite files they can only read, potentially escalating to root. CloudLinux's security blog reported this, updated 23 October at 14:59 UTC. A public exploit already exists, and on a shared server, a single customer account is sufficient to reach the kernel serving all machine tenants.
The bug resides in the network function skb_zerocopy. Independent researchers rate it with a CVSS score of 7.8. Kernel developers had reportedly received a separate report about the same issue the previous week, with a patch expected. The kernel patch was posted to the netdev mailing list on 22 October but has not yet been integrated.
Who is affected
CloudLinux clarifies that the decisive factor is not the version, but whether regular users can create their own network namespaces. Those who already applied the Dirty Frag fix (CVE-2026-43284) are not covered: that patch addresses a different issue in the same kernel area.
| Version | Exposure | Kernel patch | Livepatch |
|---|---|---|---|
| CloudLinux 7 (kernel 3.10) | No, unaffected | not required | not required |
| CloudLinux 7 hybrid (kernel 4.18) | Yes, by default | awaiting upstream fix | in preparation |
| CloudLinux 8 (kernel 4.18) | Conditional: exposed if installed before mid-2024 | awaiting | in progress |
| CloudLinux 8 ELS (kernel 5.14) | Conditional, same criteria | awaiting on extended-support channel | no stream available |
| CloudLinux 9 (kernel 5.14) | Conditional, same criteria | no patched kernel | under review |
| CloudLinux 9 ELS | Conditional, same criteria | awaiting | in preparation |
| CloudLinux 10 (kernel 6.12) | Closed by default | no patched kernel | released to production |
| CloudLinux for Ubuntu 22.04 | Closed by default | follows Ubuntu/Canonical channel | not started |
How to check and mitigate
The check is read-only:
sysctl user.max_user_namespaces
A value of 0 means the path is closed. Any other number on an exposed version should be treated as a server at risk today. The mitigation applies without a reboot:
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system
Practical cost: rootless Podman and Docker, unprivileged LXC and Flatpak stop working for regular accounts. On classic shared hosting, the impact is negligible; on servers where customers run their own containers, this needs evaluation.
CageFS, the filesystem isolation for accounts, does not intervene on this path: CloudLinux has verified that the damage occurs inside the kernel's shared memory, not through the filesystem.
Written with the help of artificial intelligence and checked by the editors (EU AI Act, art. 50).