The Linux kernel CVE team assigned CVE-2026-64564 on August 4, 2026, to a use-after-free bug in the kernel’s SCTP code. Two days later, Tencent Zhuque Lab published the full technical writeup under the name SCTPhantom. The vulnerable behavior has been sitting in the kernel since December 2007. That is roughly 18 years.
It scores 8.5 (High) on CVSS v4.0, with the vector CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, and it hands a local unprivileged user root on the host. Including from inside a Docker container.
One thing to get out of the way first, because coverage of this kind of Linux kernel vulnerability tends to blur it: SCTPhantom is not remotely exploitable. The vector is local (AV:L). An attacker already needs code execution on the machine, or inside a container running on it. Nobody is reaching your server through your router with this.
What the bug actually is
SCTP is the Stream Control Transmission Protocol, defined in RFC 4960. The flaw sits in its Dynamic Address Reconfiguration extension, ASCONF (RFC 5061), in net/sctp/sm_make_chunk.c.
When the kernel processes an ASCONF chunk, sctp_process_asconf() caches the current transport in asconf->transport. A crafted, ordered sequence of [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0], where L is not the packet’s source address, walks straight past the D8 check, because D8 only guards the source address. The first DEL-IP frees the transport. The wildcard branch right after it reuses that pointer, which is now dangling, and a freed pointer ends up in asoc->peer.primary_path and active_path.
The upstream fix rejects a DEL-IP aimed at the transport whose ASCONF is currently being processed. It landed in mainline as commit 9b2854f86f0b. The vulnerable behavior traces back to commit 42e30bf3463c, which shipped in Linux 2.6.25 in December 2007.
Why this one matters for a homelab
Tencent Zhuque Lab (the TencentOS Security Team) found it with an internal multi-agent pipeline they call Corvus AI, then built a working exploit chain around it. At a high level: the use-after-free, the freed slot reclaimed by pg_vec from a TPACKET V1 ring, a direct-map address disclosure, a repeatable 4-byte kernel read through SCTP_STATUS, KASLR recovery via the IDT, a second use-after-free reclaimed by SCTP authentication keys, a controlled object graph, then a data-oriented call to commit_creds() for global root. A usermode-helper variant using call_usermodehelper_exec() covers the container escape.
Here is the detail that should get your attention if you run containers. The container escape was validated with the default Docker seccomp profile active. No CAP_NET_ADMIN. No CAP_SYS_ADMIN. No changes to the net.sctp.addip_enable or net.sctp.addip_noauth_enable sysctls either, because the per-socket options SCTP_ASCONF_SUPPORTED and SCTP_AUTH_SUPPORTED were enough on their own. Six of eight attempts reached root on the host. The two that failed stopped cleanly, with no kernel panic.
Root was reported on Linux 7.2-rc2 (a research kernel), OpenCloudOS 6.6.119, Debian 13 (6.12.95+deb13-amd64), Rocky Linux 9 and RHEL 9 running the vendor 5.14 kernel with the SCTP module loaded, and Ubuntu 24.04 (6.8.0-134-generic).
Hold that list up against a typical homelab. A Docker host, a Proxmox node, a TrueNAS SCALE box, an OpenMediaVault install, a plain Debian or Ubuntu server: every one of them shares a single kernel with everything running on top of it. Whether you drive your containers from the command line or through a dashboard like Portainer, the isolation boundary is that same kernel. Which is exactly what a kernel bug ignores. One compromised container, or one unprivileged local account, is enough.
Which kernels are fixed
The first clean releases are:
- 6.6.148
- 6.12.101
- 6.18.42
- 7.1.6
- mainline 7.2-rc5
A caveat worth repeating from the source, because people get this wrong every time a kernel CVE lands: distribution kernels routinely backport fixes while keeping an old version number. The number on its own proves nothing, in either direction. Check your vendor’s advisory or the source package instead. Debian 13 has already shipped a kernel security update that fixes SCTPhantom.
What to actually do
Update the kernel and reboot. That is the fix. On most distributions the patched package is already available or arriving shortly.
If a reboot has to wait, there is a reasonable stopgap. SCTP ships as a loadable module on most distributions, and almost no homelab uses it for anything. Blacklisting it stops the module from loading automatically: add a file under /etc/modprobe.d/ containing install sctp /bin/true.
Two things to keep in mind. Check lsmod first, because blacklisting does nothing about a module that is already in memory. And that means the reboot is still coming, one way or another.
Timeline
- July 12, 2026: discovery and private disclosure
- July 24, 2026: fix merged into the networking tree
- July 27, 2026: container escape validated
- August 4, 2026: official CVE announcement by the Linux kernel CVE team
- August 6, 2026: technical writeup published by Tencent Zhuque Lab, plus posts to oss-security
Perspective
SCTPhantom is a real problem, but it is not a reason to unplug anything tonight. There is no remote attack surface. The risk is concentrated in homelabs that run container images they did not build, or that hand shell accounts to people other than the owner. If that describes your setup, this belongs on the next maintenance window rather than the next quarter. It is a different shape of problem from something like the Gitea Docker authentication bypass, which was being exploited from the outside within days.
Sources: the Tencent Zhuque Lab technical writeup and the NVD entry for CVE-2026-64564.