ZDI-CAN-33367: Check and Mitigate the Linux Kernel Root Zero-Day

ZDI-CAN-33367 is a Linux kernel flaw with a public exploit and no CVE yet. It lets any local user change files they can only read, and from there become root. A server is exposed when ordinary users can create user namespaces. Run sysctl user.max_user_namespaces: 0 means closed. Anything else, set it to 0 now, then install the fixed kernel or livepatch.

ZDI-CAN-33367 is the tracking number Trend Micro's Zero Day Initiative (ZDI) gave to a local privilege escalation in skb_zerocopy(), a helper in the kernel's networking code. The bug lets IPsec decryption write into the kernel's cached copy of a file. ZDI scores it 7.8 (High), according to AlmaLinux.

Developing story. Fix status changes daily. This guide reflects 27 October 2026, mainly from the CloudLinux advisory, the CloudLinux status page (27 October, 08:35 UTC), TuxCare's analysis and AlmaLinux.

What is ZDI-CAN-33367, in plain English?

It is a bug that lets an ordinary user write into the page cache, the kernel's in-memory copy of file data, for files that are read-only to them. The chain, without exploit detail:

• skb_zerocopy() moves packet data between network buffers by passing references to memory pages instead of copying. Some pages can belong to a file.
• The fix for Dirty Frag (CVE-2026-43284) tags such shared pages with a marker, SKBFL_SHARED_FRAG. IPsec's ESP code checks it and decrypts into a private copy.
• skb_zerocopy() drops the marker, so ESP decrypts in place, over the cached pages of a file the user can only read.
• If that file is one the system trusts, the system runs the attacker's version, and the user gets root.

Three things follow. The Dirty Frag fix does not help, say CloudLinux and TuxCare. The change lives only in memory: AlmaLinux says the file on disk is untouched, but every reader sees the altered bytes until the pages are evicted or the system reboots. And it is local only: CloudLinux says "Nothing in it can be done to a server from the outside network."

The exploit went public by accident. ZDI sent its reports on 20 and 21 October to the kernel security team and, by mistake, to public mailing lists, as Phoronix reported. AlmaLinux says the ZDI-CAN-33367 report was posted together with the source code of a working proof-of-concept. This guide does not link to it. The upstream fix, "net: skbuff: propagate shared-frag marker in skb_zerocopy()", was posted on 22 October. On 27 October CloudLinux said it was accepted into the networking tree but not yet in mainline, with no CVE and no report of exploitation in the wild.

Which Linux distributions and versions are affected?

Apart from CentOS 6 and 7 era kernels, every kernel tested so far was vulnerable; one setting decides exposure. CloudLinux and TuxCare both got root with the public exploit on AlmaLinux 8, 9 and 10, CloudLinux 9 and 10, Debian 12 and 13, and Ubuntu 24.04 and 26.04.

The AlmaLinux production rows come from kernel changelogs in AlmaLinux's repositories, read on 27 October; AlmaLinux's post still called the kernels testing-only. On CloudLinux, the install date sets the default: CloudLinux says lve-utils applies the 0 only on first install, so updating an older server does not close it.

How do I check if my server is exposed?

Run one read-only command, as any user:

sysctl user.max_user_namespaces

Only zero versus non-zero matters. A 0 means ordinary accounts cannot create user namespaces, so they cannot start the public exploit. Any other number means the path is open, and CloudLinux says to treat an affected server as exposed. The size of the number means nothing: CloudLinux notes it "varies with the machine's memory".

• Ubuntu 24.04 and later. Do not count on kernel.apparmor_restrict_unprivileged_userns. TuxCare says the exploit got past it through a container launcher's AppArmor profile. Ubuntu's own explanation of the feature says it "does not stop kernel exploits directly" and that unconfined profiles allowing user namespaces are a "trivial bypass".
• Containers. CloudLinux says root inside a container that was granted network rights "does not need the namespace step at all". On container hosts, a 0 does not close that route.
• Scanners. With no CVE, tools keyed on CVE IDs may miss it, TuxCare warns. Check by hand.

1. Does user.max_user_namespaces print 0? If yes, the path is closed for ordinary accounts. Patch at a normal pace.
2. Is a fixed kernel or livepatch already running? If yes, you are patched. Keep watching the advisories.
3. Do users need rootless containers, Flatpak or unprivileged LXC? If not, set the sysctl to 0 now, then patch.
4. Is a fixed kernel or livepatch available? If yes, install it today. If not, use the module block below and patch when a fix ships.

How do I mitigate ZDI-CAN-33367 right now?

Set user.max_user_namespaces to 0. CloudLinux and TuxCare give the same commands, run as root, and no reboot is needed:

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

Run the check again; it should print 0. Namespaces that already exist stay put, TuxCare notes.

What it breaks. Rootless Podman and Docker, unprivileged LXC, Flatpak and some browser sandboxes, for ordinary accounts, says CloudLinux. On a classic shared hosting fleet that "usually costs nothing". On CI runners and build hosts that need namespaces, TuxCare points to the module block instead.

How to undo it. Delete the file and run sysctl --system again, once a fix is in place and only if something needs namespaces back.

If you suspect tampering already happened, AlmaLinux suggests dropping the page cache with sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches', but says rebooting into the patched kernel is more reliable.

What if the server needs user namespaces?

Block two kernel modules instead, as a fallback, not a fix. CloudLinux and TuxCare suggest stopping nlmon and act_pedit, which the public exploit needs, from loading. Check first that nobody uses tc pedit or nlmon.

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

The second line must print nothing; if a module is listed, it is already loaded, so reboot. TuxCare adds that modprobe -n -v nlmon and modprobe -n -v act_pedit should both print the install /bin/false line. The caveat, in CloudLinux's words: "We have not run the exploit against either mitigation, and we have not verified that blocking the two modules stops every variant."

AlmaLinux's own temporary mitigation blocks the esp4 and esp6 IPsec modules the exploit writes through, and says a Dirty Frag mitigation still in place covers you. Workloads that use IPsec will break. No output from lsmod means it is active; to revert, remove /etc/modprobe.d/zdi-can-33367.conf.

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/zdi-can-33367.conf; rmmod esp4 esp6 2>/dev/null; true"
lsmod | grep -E '^esp(4|6)'

How do I install the fixed kernel or livepatch?

A mitigation buys time; only a fixed kernel or livepatch closes the bug.

AlmaLinux

On AlmaLinux 8 and 9 the fix is in the normal repositories: update the kernel, reboot, and confirm with uname -r or rpm -q kernel against the versions in the table. On AlmaLinux 10 a plain update installs 211.68.1, which lacks the fix. Use the livepatch, or AlmaLinux's testing commands:

sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot

Then confirm 6.12.0-211.68.2.el10_2 or higher, and disable testing with sudo dnf config-manager --disable almalinux-testing. A kernel update only takes effect after the reboot; if a panel keeps asking for one, see the "reboot to update the kernel" message.

CloudLinux 7 hybrid and 8

CloudLinux's advisory gives these beta commands:

# CloudLinux 8
yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
reboot
# CloudLinux 7 hybrid
yum update 'kernel*' --enablerepo=cl7h_beta
reboot

The status page describes a rollout route instead: update cloudlinux-release first, then use --enablerepo=cloudlinux-rollout-2-bypass. Once the rollout reaches stable, CloudLinux says a plain kernel update and reboot installs the same kernel. Then uname -r should show 4.18.0-553.177.1.lve.1.el7h or .el8, or later, and rpm -q --changelog kernel-core-$(uname -r) | grep CLKRN-2389 should find the fix.

KernelCare livepatch

Per the status page on 27 October: EL10 released for AlmaLinux, CloudLinux, RHEL, Oracle Linux and Rocky Linux 10; EL9 in the production feed since 26 October but not ePortal; EL8 ready, not released; Debian and Ubuntu in progress. Apply and verify:

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

CloudLinux warns to use --patch-info, not --info, which returns nothing for a specific issue even when patched.

Ubuntu, Debian, RHEL and Rocky Linux

As of 27 October 2026 there was no Ubuntu security notice, Debian advisory, or Red Hat or Rocky Linux statement for this issue. A Red Hat Bugzilla search returned nothing for ZDI-CAN-33367; its one skb_zerocopy match, CVE-2026-90049, is a different bug from September. AlmaLinux said on 23 October that no fixed RHEL kernel existed. Watch Ubuntu Security Notices and debian-security-announce, and use the sysctl until a kernel ships.

Why are shared hosting, cPanel and Plesk servers the worst case?

Because the starting point is an ordinary hosting account, which every customer buys. CloudLinux says "one hosting account is enough to reach every tenant on the server."

• Local does not mean insider. CloudLinux names a customer, or an intruder who came in through a vulnerable plugin. A remote bug that runs code as a site user, like PHP2Shell, gives exactly that foothold.
• Removing SSH is not enough. TuxCare notes every shared account "can run PHP or a cron job".
• One kernel, every tenant. Success reaches every site, database, mailbox and credential on the machine.
• CageFS does not protect. CloudLinux tested it: the cage hides the command-line tool, so a shell test seems to fail, but a small compiled program succeeded inside the cage, and LVE limits did not stop it either.
• VPS hosts. On container-based plans, see the container caveat above. On KVM plans each guest runs its own kernel, so customers must patch their own.

The same applies to any panel that gives customers Linux accounts, cPanel and Plesk included. For hosting setups in general, see the web hosting expert page, and see also my server hardening checklist and PHP update guide.

What should hosting companies tell customers?

Tell them it is local, what you changed, what might break and when the reboot comes:

• Name it: ZDI-CAN-33367, a kernel local root flaw with a public exploit.
• Say it is local only, but a hacked site or account can use it.
• Give the date you set the sysctl to 0 or applied the livepatch.
• Warn shell users that rootless containers and Flatpak may stop working.
• Announce the reboot window for the fixed kernel.
• Send VPS and dedicated customers the check command for their own kernels.
• Do not claim CageFS or AppArmor protects them.

What were the other ZDI reports in the same leak?

ZDI sent six reports, and CloudLinux calls ZDI-CAN-33367 "the one with a public exploit that affects hosting servers." Two are in ksmbd, the in-kernel SMB server (ZDI-CAN-33774, ZDI-CAN-33549), scored 9.0, though the public proofs of concept show a memory leak and a crash. ksmbd runs only where an administrator set it up; check with systemctl is-active ksmbd. The vmwgfx and nvmet reports (ZDI-CAN-34068, ZDI-CAN-34076) are titles only, and ZDI-CAN-32005 is in ConnMan, not the kernel.

What else do people ask about ZDI-CAN-33367?

Does ZDI-CAN-33367 have a CVE number?

Not yet. CloudLinux's status page said "No CVE yet" on 27 October, and AlmaLinux will update its post when one is assigned.

Can ZDI-CAN-33367 be exploited remotely?

No, it is local only. But any foothold, such as a hacked plugin or a stolen login, turns it into full control of the server.

Does the Dirty Frag patch protect against ZDI-CAN-33367?

No. TuxCare confirmed that AlmaLinux 8, 9 and 10 ship the Dirty Frag fix and were still rooted. You need the new skb_zerocopy fix.

Will setting user.max_user_namespaces to 0 break Docker?

It breaks rootless Docker and Podman for ordinary accounts, per CloudLinux. Test any other container setup on a staging host first, as TuxCare advises.

Do I need to reboot to fix ZDI-CAN-33367?

Not for the sysctl or a KernelCare livepatch. A fixed kernel needs one, and the module block only if a module is already loaded.

If you run a fleet and want help rolling out the mitigation and kernels, I do this as server security hardening work.

Last reviewed 27 October 2026. This is a developing story and fix status changes daily; check the CloudLinux status page and your distribution's security announcements before acting. Disclosure: I am CTO at ElySpace, a hosting company, a freelance developer for Marmaids LLC, and founder of WHMCSPilot and MagizAI. I sell server hardening work, so I am not neutral. I am not affiliated with CloudLinux, TuxCare, AlmaLinux, Canonical, Debian or Red Hat.