ZDI-CAN-33367: Linux Kernel Local Root Zero-Day, Mitigation for CloudLinux

📋 TL;DR: last updated 5 November 2026, 10:40 UTC

ZDI-CAN-33367 (no CVE assigned) is a flaw in the Linux kernel networking stack that lets any local user rewrite files they can only read, which leads to root. A public exploit exists. Fixed kernels are released to production for CloudLinux 7 hybrid, 8, 9, 10, 8 ELS, and 9 ELS. KernelCare livepatches are released for CloudLinux 7 hybrid, 8, 9, and 10, and for CloudLinux for Ubuntu 22.04.

• Affected: a server is exposed when ordinary users can create their own namespaces. CloudLinux 7 hybrid is exposed as shipped. CloudLinux 8, 8 ELS, 9, and 9 ELS are closed by default on servers installed since mid-2024 and exposed on older ones. CloudLinux 10 and CloudLinux for Ubuntu 22.04 are closed by default. CloudLinux 7 is not affected. (affected versions)
• Already applied the Dirty Frag fix (CVE-2026-43284)? It does not protect you from this one.
• Mitigation: set user.max_user_namespaces to 0. It applies without a reboot and stops rootless containers for ordinary accounts. (mitigation)
• Fix status: every affected CloudLinux line has a fixed kernel or a livepatch released. (update instructions)
• — Stream 1, CloudLinux kernel (CL7h, CL8): fixed kernels released to production.
• — Stream 2, AlmaLinux kernel (CL9, CL10): fixed kernels released to production.
• — Stream 3, TuxCare ELS kernel (CL8 ELS, CL9 ELS): fixed kernels released to production.
• — Stream 4, KernelCare livepatch: released for CloudLinux 7 hybrid, 8, 9, 10, and CloudLinux for Ubuntu 22.04. In preparation for CloudLinux 9 ELS.
• Verify: sysctl user.max_user_namespaces prints 0 when the path is shut. (how to verify)
• Why it matters: one hosting account is enough to reach every tenant on the server. (why this matters)
• How the bug works: a marker that protects shared memory pages is dropped. (technical details)

Live updates are on the CloudLinux status page.

Update: 5 November 2026, 10:40 UTC

KernelCare livepatches are released in the production feed for CloudLinux 9 (since 26 October), CloudLinux 7 hybrid and 8 (since 29 October), and CloudLinux for Ubuntu 22.04 (since 2 November). Fixed TuxCare ELS kernels are released to production for CloudLinux 8 ELS and 9 ELS. Every affected CloudLinux line now has a fixed kernel or a livepatch released. The CloudLinux 9 ELS livepatch is still in preparation.

Update: 30 October 2026

Fixed kernels for CloudLinux 7 hybrid and 8 are released to production: kernel-4.18.0-553.177.1.lve.1.el7h for CloudLinux 7 hybrid and kernel-4.18.0-553.177.1.lve.1.el8 for CloudLinux 8. All four CloudLinux kernel lines now have a fixed kernel in production.

Update: 28 October 2026

Fixed kernels for CloudLinux 9 and 10 are released to production, through the AlmaLinux kernel updates: kernel-5.14.0-687.60.1.el9_8 for CloudLinux 9 and kernel-6.12.0-211.69.1.el10_2 for CloudLinux 10, or a later build. A full update and a reboot install them.

Update: 26 October 2026

AlmaLinux published fixed kernels for AlmaLinux 8, 9, and 10 to its testing repository on 23 October: kernel-4.18.0-553.177.2.el8_10, kernel-5.14.0-687.59.2.el9_8, and kernel-6.12.0-211.68.2.el10_2. CloudLinux 9 and 10 use the same kernels as AlmaLinux, and the CloudLinux builds follow. AlmaLinux backported the netdev fix without waiting for an upstream CentOS Stream or RHEL update. No CVE has been assigned yet.

Update: 26 October 2026

Fixed CloudLinux kernels are released to beta and rolling out for CloudLinux 7 hybrid (kernel-4.18.0-553.177.1.lve.1.el7h) and CloudLinux 8 (kernel-4.18.0-553.177.1.lve.1.el8). The fix for CloudLinux 9 and 10 is on the way from AlmaLinux.

Update: 23 October 2026, 14:59 UTC

A KernelCare livepatch is released in the production feed for CloudLinux 10 and AlmaLinux 10. The CloudLinux 9 livepatch is in review and the CloudLinux 8 livepatch is in progress, with no date for either. The livepatch is built from the upstream fix candidate, and we verified that it stops the public exploit. The upstream fix has been reviewed by the netdev maintainer and is not merged yet.

Update: 22 October 2026, 18:44 UTC

Our kernel team confirmed root with the public exploit on AlmaLinux 8, 9, and 10, CloudLinux 9 and 10 (same kernels as AlmaLinux), Debian 12 and 13, and Ubuntu 24.04 and 26.04. CentOS 6 and CentOS 7 kernels are not affected. The kernel for CloudLinux 8 has every module the exploit needs and has not been tested yet. An upstream fix was posted for review and is not merged. KernelCare livepatch work has started, enterprise Linux first.

Status: 22 October 2026, 13:30 UTC

ZDI sent six kernel vulnerability reports on 20 and 21 October, and one of them, ZDI-CAN-33367, has a working public exploit. This post covers that one. We had not reproduced it yet. No CVE and no vendor advisory existed at that point.

ZDI-CAN-33367 is a local privilege escalation in the Linux kernel networking stack, reported through Trend Micro’s Zero Day Initiative (ZDI). It has no CVE assigned and has a working exploit in public. An ordinary user with a shell on the machine can change the contents of any file they can read, including files they have no permission to write, and from there take control of the server.

We are calling it a zero-day: it became public with a working exploit, no CVE, and no fix. ZDI sent its reports to the kernel security team on 20 and 21 October and, by mistake, to public mailing lists as well (Phoronix covered it). We are not aware of any report of the flaw being used in the wild. It is the same class of flaw as Dirty Pipe, with one vector, and that vector is local. Nothing in it can be done to a server from the outside network.

If you installed the Dirty Frag fix, you are not covered.

A flaw in the same area was fixed earlier this year as CVE-2026-43284 (see our Dirty Frag advisory). That repair taught one part of the kernel to respect a safety marker on data that must not be modified in place. This bug loses the marker before that check runs, so a server with the earlier fix is still exposed. The fix that shipped for the earlier issue does not help here.

“Local” does not mean an insider. On a shared server the attacker is a customer who bought an account, or an intruder who got into one site through a vulnerable plugin, and either one already stands where the exploit begins. The damage lands in the shared kernel, so success reaches every other tenant on the machine.

Affected CloudLinux versions

Version alone does not decide exposure. The exploit needs a set of networking kernel modules, and every affected kernel ships them. In practice one condition decides it: whether ordinary users on the server can create their own private namespaces, in which the user is treated as administrator of their own network. Where they can, treat the server as exposed today. Where they cannot, an ordinary account cannot start the sequence.

The check is read-only and takes a few seconds:

sysctl user.max_user_namespaces

A value of 0 means the path is shut for ordinary accounts. Any other number means it is open, and on an affected version the server should be treated as exposed. The number carries no meaning beyond being non-zero: it varies with the machine’s memory.

Am I at risk? Only if ordinary users on the server can create their own private namespaces.

On CloudLinux 7 hybrid they can, as shipped. On CloudLinux 8, 8 ELS, 9, and 9 ELS it depends on when the server was installed: since mid-2024 they cannot by default, and before that they can. On CloudLinux 10 they cannot by default. Whatever the version, the one-line check above answers for the server in front of you.

† The kernel on this line comes from Canonical through apt, so there is no CloudLinux stream. It follows the Ubuntu security stream.

KernelCare livepatches apply without a reboot. They are released for CloudLinux 7 hybrid, 8, 9, and 10, and for CloudLinux for Ubuntu 22.04. The CloudLinux 9 ELS livepatch is in preparation, and CloudLinux 8 ELS has no live-patching stream.

What we tested. Our kernel team ran the published exploit to completion, obtaining root, on AlmaLinux 8, 9, and 10, on CloudLinux 9 and 10 (same kernels as AlmaLinux), on Debian 12 and 13, and on Ubuntu 24.04 and 26.04. On the older CentOS 6 and CentOS 7 kernels the chain does not work at all.

On CloudLinux 7 hybrid, 8, and 8 ELS, which run our own kernels, we have not run the exploit yet. On freshly installed machines of each line, on 22 and 23 October, we checked whether an ordinary account can take the first and decisive step: creating a private namespace in which the user is treated as administrator of their own network. On all three it could. Everything after that step is the code that gave root elsewhere, so we treat these lines as exposed. CloudLinux 7 and CloudLinux for Ubuntu 22.04 were measured the same way. CloudLinux 9 ELS was not tested separately and follows CloudLinux 9.

Install date, not updates, sets the default. On CloudLinux 8, 9, and 10 the value 0 is set by lve-utils only when it is first installed, on servers installed since mid-2024. Updating an older server, even to the latest lve-utils, does not apply it.

The version does not settle it, the command does. A server on a line listed as closed can still have had this setting changed locally, by an administrator or by container software. A process that already holds elevated network rights, such as the root user inside a container that was granted them, does not need the namespace step at all.

Is there a mitigation?

Yes, on servers that do not have a fixed kernel or livepatch yet. Disabling unprivileged user namespaces closes the path for ordinary accounts today, and it applies without a reboot. On CloudLinux 10, and on CloudLinux 8 and 9 servers installed since mid-2024, it is already the default.

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

What it costs. It stops ordinary users from creating their own namespaces, which is what the attack needs and also what rootless containers need. Rootless Podman and Docker, unprivileged LXC, Flatpak, and some browser sandboxes stop working for ordinary accounts. On a classic shared-hosting fleet that usually costs nothing. On a server where customers run their own containers it is disruptive, and those operators need to weigh it against leaving the path open until a fixed kernel or livepatch arrives.

To undo it later, delete the file and run sysctl --system again.

A second, narrower option. Blocking two less common kernel modules the exploit needs, nlmon and act_pedit, has low impact on most servers. Check first that nobody uses tc pedit or nlmon. It may not cover every path, so treat it as a fallback where namespaces cannot be disabled, not as a replacement.

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '   # must print nothing, else reboot

We have not run the exploit against either mitigation, and we have not verified that blocking the two modules stops every variant.

Does CageFS protect against this?

No, and we measured it. CageFS, the virtualized filesystem that gives each account its own restricted view of the server, does not sit in this path. The flaw does not travel through the filesystem: the damage is done inside the shared kernel’s own memory.

We tested it on an exposed line. Running the first step from a caged account through the shell appears to fail, but for a shallow reason: the small command-line tool that creates a namespace is not part of the cage’s file set, so the shell cannot find it. We then ran a small compiled program that asks the kernel for the same thing directly, which is how real exploit code works. Inside the cage it succeeded. With CageFS switched off and only LVE (Lightweight Virtualized Environment) limits left in place, it succeeded as well.

So the cage removed a convenience tool and nothing more. A report that a caged account “could not do it” from a shell test has measured the missing tool, not protection.

Update instructions

Fixed kernels are released to production for CloudLinux 7 hybrid, 8, 9, 10, 8 ELS, and 9 ELS. The KernelCare livepatches are built from the upstream fix that was posted for review on 22 October, and we verified on CloudLinux 10 that the livepatch stops the public exploit. On lines without a fixed kernel or livepatch yet, the mitigation above is the answer.

Stream 1: CloudLinux kernel (CL7h, CL8)

Update: 30 October 2026

Fixed kernels are released to production: kernel-4.18.0-553.177.1.lve.1.el7h for CloudLinux 7 hybrid and kernel-4.18.0-553.177.1.lve.1.el8 for CloudLinux 8.

Update: 26 October 2026

Fixed kernels are released to beta and rolling out: kernel-4.18.0-553.177.1.lve.1.el7h for CloudLinux 7 hybrid and kernel-4.18.0-553.177.1.lve.1.el8 for CloudLinux 8.

Status: 23 October 2026, 14:59 UTC

No fixed kernel yet. Once the upstream fix is merged, we rebuild the CloudLinux 7 hybrid and CloudLinux 8 kernels ourselves.

To install the kernel, update the server and reboot:

yum clean metadata
yum update
reboot

Stream 2: AlmaLinux kernel (CL9, CL10)

Update: 28 October 2026

Fixed kernels are released to production: kernel-5.14.0-687.60.1.el9_8 for CloudLinux 9 and kernel-6.12.0-211.69.1.el10_2 for CloudLinux 10.

Update: 26 October 2026

AlmaLinux published fixed kernels to its testing repository on 23 October: kernel-5.14.0-687.59.2.el9_8 for the CloudLinux 9 line and kernel-6.12.0-211.68.2.el10_2 for the CloudLinux 10 line. They move to AlmaLinux production after community testing, with no date given. The CloudLinux builds follow, and no fixed kernel is released for CloudLinux 9 or 10 yet. AlmaLinux Kitten 10 gets the fix in its next regular kernel update.

Status: 23 October 2026, 14:59 UTC

No fixed kernel yet. CloudLinux 9 and 10 follow the AlmaLinux kernel, which follows the upstream fix.

To install it, update the server and reboot:

yum clean metadata
yum update
reboot

Stream 3: TuxCare ELS kernel (CL8 ELS, CL9 ELS)

Update: 5 November 2026, 10:40 UTC

Fixed kernels are released to production: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els17 for CloudLinux 8 ELS and kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els17 for CloudLinux 9 ELS, or a later build. A regular kernel update installs them, and a reboot starts the fixed kernel. On CloudLinux 8 ELS this is the only route to the fix.

Status: 23 October 2026, 14:59 UTC

Pending on the extended-support channel. CloudLinux 8 ELS has no live-patching stream, so for that line a kernel upgrade with a reboot is the only route.

Stream 4: KernelCare livepatch (all affected versions)

Update: 5 November 2026, 10:40 UTC

Released in the production feed for CloudLinux 9 (K20261023_0016, since 26 October), CloudLinux 7 hybrid and 8 (K20261028_0018 and K20261028_0017, since 29 October), and CloudLinux for Ubuntu 22.04 (K20261101_0004, since 2 November). The CloudLinux 10 livepatch has been released since 23 October. The CloudLinux 9 ELS livepatch is in preparation, and CloudLinux 8 ELS has no live-patching stream.

Update: 23 October 2026, 14:59 UTC

Released in the production feed for CloudLinux 10 and AlmaLinux 10. The CloudLinux 9 livepatch is in review, the CloudLinux 8 livepatch is in progress, and Debian and Ubuntu have not started. No dates yet.

Status: 22 October 2026, 18:44 UTC

Livepatch work has started, enterprise Linux first. No ETA yet.

Apply the livepatch from the production feed:

kcarectl --update

How to verify

Check exposure now. sysctl user.max_user_namespaces prints 0 when ordinary accounts cannot create their own namespaces.

After applying a KernelCare livepatch, confirm it landed with:

kcarectl --patch-info | grep -i 33367

Use --patch-info, not --info. The latter prints a summary and returns nothing for a specific issue even on a fully patched server, which is the usual reason someone concludes a server is unpatched when it is not.

After installing a fixed kernel, run uname -r after the reboot. It should show 4.18.0-553.177.1.lve.1.el7h on CloudLinux 7 hybrid, 4.18.0-553.177.1.lve.1.el8 on CloudLinux 8, 5.14.0-687.60.1.el9_8 on CloudLinux 9, 6.12.0-211.69.1.el10_2 on CloudLinux 10, or 5.14.0-284.1101.el8.tuxcare.11.els17 and 5.14.0-284.1101.el9.tuxcare.11.els17 on CloudLinux 8 ELS and 9 ELS, or a later build.

Why this matters on a shared host

Shared hosting is close to the worst shape this flaw can take. The attacker’s starting position is an ordinary hosting account, which is exactly what every customer buys. No compromise of the provider’s own systems is needed, and no unusual server configuration. A tenant with a shell, or an intruder who got into one site through a vulnerable plugin, is already where the exploit begins.

From there the path is short: rewrite a file the system trusts, and the system runs the attacker’s version of it. Because the damage lands in the shared kernel rather than inside one account’s boundary, the result is the whole machine, with every other tenant’s files, databases, mail, and credentials on that server. For a hosting provider the question is not whether one customer loses a site. It is whether one account can take the entire box.

Closing the namespace path keeps a web-tier compromise where it started, as one site to clean up instead of a whole server to rebuild.

The other reports in the same leak

ZDI sent six reports in total. ZDI-CAN-33367 is the one with a public exploit that affects hosting servers. The others:

• ksmbd (ZDI-CAN-33774 and ZDI-CAN-33549). ZDI scores both 9.0 and calls them remote code execution. The public proofs of concept show a kernel memory leak and a crash, not code execution. ksmbd, the in-kernel SMB file server, is not built in the AlmaLinux and CloudLinux 9 and 10 kernels. Debian and Ubuntu build it, but it runs only after an administrator installs ksmbd-tools and starts the service. Servers that share files with Samba are not affected.
• vmwgfx and nvmet (ZDI-CAN-34068 and ZDI-CAN-34076). Only the titles are public. There is no technical detail to act on yet.
• ConnMan (ZDI-CAN-32005). A userspace network manager, not the kernel.

On a server that does run ksmbd, treat ZDI-CAN-33774 as a remote memory leak and crash before login, and stop the service if it is not needed. To check:

systemctl is-active ksmbd

Technical details of the bug

The flaw sits in skb_zerocopy(), a networking function that moves references to existing memory pages from one network buffer to another instead of copying the data. When those pages belong to a file, a local user can end up changing the file’s contents in the page cache, the kernel’s in-memory copy of file data. The earlier fix for CVE-2026-43284 added a marker, SKBFL_SHARED_FRAG, that tags pages shared with a file, and the IPsec ESP code checks it before decrypting: with the marker present, ESP works on a private copy. skb_zerocopy() passes the pages along without carrying the marker over, so ESP decrypts in place on pages that are still shared. The upstream fix, titled “net: skbuff: propagate shared-frag marker in skb_zerocopy()”, copies the marker across.

The exploit needs two things. The first is a private namespace in which the user is treated as administrator of their own network, which is what user.max_user_namespaces controls. The second is a set of kernel modules: nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred, esp4, and xfrm_user. Every affected kernel ships them. With both in place, the published code runs to root, as our kernel team confirmed on the lines listed above.

References

• Phoronix: new Trend Micro kernel vulnerabilities posted to public lists
• ZDI-CAN-33367 original report on the kernel mailing list
• Upstream fix posted for review: net: skbuff: propagate shared-frag marker in skb_zerocopy()
• TuxCare: skb_zerocopy zero day analysis
• CloudLinux advisory for Dirty Frag, CVE-2026-43284
• CloudLinux status page