· via dev.to (home feed)
Public root exploit surfaces for one of six Linux kernel flaws still without CVEs
Six Zero Day Initiative reports on Linux components remain without CVE identifiers, and one local privilege escalation already has a working public root exploit.

What happened
The Zero Day Initiative (ZDI) sent six vulnerability reports touching the Linux kernel and adjacent components to maintainers and public mailing lists on October 20 and 21, 2026. When Sysdig's Threat Research Team examined them on October 24, one of the six already had a working public proof of concept, several had no fix in any released kernel, and none had been assigned a CVE identifier, according to a write-up published on dev.to. Infosecurity Magazine also reported on the disclosures on October 26.
That combination frustrates routine patch management. A CVE identifier is what ties together scanner signatures, vendor advisory pages and fixed package versions. Without one, the information exists only as mailing-list threads and ZDI candidate numbers, with no feed entry to key on.
The flaw with a working exploit
ZDI-CAN-33367 is a local privilege escalation in the Linux networking stack, rated 7.8 by ZDI. It allows an unprivileged user to modify the in-memory contents of files they can only read. The affected code path was not covered by the earlier fix for the Dirty Frag page-cache flaws, so a distribution that backported that fix is not automatically protected against this one.
TuxCare used the public proof of concept to obtain a root shell on AlmaLinux 8 through 10, CloudLinux 9 and 10, Debian 12 and 13, and Ubuntu 24.04 and 26.04. That list frames the exposed population in terms of distributions a fleet owner can actually check, rather than upstream kernel versions.
Sysdig suggested that disabling unprivileged user namespaces should block the public exploit, while noting that TuxCare had not validated the mitigation. The same control also underpins rootless containers, so applying it breaks a deployment pattern many teams have standardised on.
Two 9.0 findings in ksmbd
The highest-rated reports, ZDI-CAN-33774 and ZDI-CAN-33549, both score 9.0 and both affect ksmbd, the in-kernel SMB server. The first can be triggered remotely before authentication and can leak kernel memory and crash systems. The second requires SMB Direct, an RDMA interface and a writable share, a considerably narrower set of preconditions. Because the reachable surface is port 445, Sysdig recommends unloading ksmbd where it is not needed and limiting port 445 to trusted networks where it must stay.
The remaining three
ZDI-CAN-34068 is a local privilege escalation rated 8.8 in the kernel's VMware graphics driver. At the time of the analysis it had no patch and only the report title was public, leaving defenders nothing concrete to test against. ZDI-CAN-34076 is an information leak in the NVMe target, and ZDI-CAN-32005 is a userspace stack overflow in the ConnMan network manager. Those two sit outside the kernel proper, which shifts responsibility for the fix to different maintainers.
Ranking exposure without identifiers
Sysdig's guidance is to prioritise by the components a fleet actually runs rather than by CVSS score, since that produces a different order than a numeric sort. A fleet that never loads ksmbd has no exposure to the two 9.0 findings, while a container fleet with unprivileged user namespaces enabled is exposed to the 7.8 finding that carries the public exploit. Component inventory ends up doing the ranking work the missing CVEs would normally do.
Patch availability adds a second dimension. As of October 23, AlmaLinux had patched kernels in testing but not in production, so fleets on that distribution sit in the gap between disclosure and a shipped package, and a scanner keyed to fixed versions would read them as unaffected until the package lands. The dev.to write-up recommends recording ZDI candidate numbers, affected components, distribution test results and chosen mitigations in tickets, so those records can be matched to CVEs once they are assigned retroactively.
Why it matters
This cluster shows what happens when disclosure outruns the tracking machinery. A public exploit, confirmed root shells across major distributions and absent patches are each manageable on their own; combined with missing CVE identifiers, they leave scanners silent and advisory feeds empty. Operators running the affected distributions cannot wait for identifiers to appear. The ZDI candidate numbers and their own component inventories are the workable handles today, and ZDI-CAN-33367 can be tested directly against the listed distributions right now.
- #linux-kernel
- #security
- #vulnerability-disclosure
- #privilege-escalation
- #sysdig