What SCTPhantom actually breaks
CVE-2026-64564 - nicknamed SCTPhantom by some of the researchers covering it - is a use-after-free vulnerability inside the Linux kernel's implementation of SCTP, the Stream Control Transmission Protocol used mainly in telecom signaling, some financial messaging systems, and a handful of container and cluster networking stacks. The flaw sits specifically in ASCONF, the code that handles Dynamic Address Reconfiguration, letting an active SCTP association add or remove IP addresses without tearing down the connection. The CVE was formally announced on August 4, 2026, after a private disclosure process that began on July 12, 2026.
The root cause is an identity mismatch: when the kernel processes a DEL-IP request to remove an address from an association, it validates that request using the source address on the incoming packet, while a separate cached pointer inside the kernel still keys off the address named in the request's own parameter. An attacker who crafts a deliberately ordered sequence of ASCONF chunks can exploit the gap between those two checks to free a piece of kernel memory while a live pointer still points at it - the textbook definition of a use-after-free, and one of the more reliable primitives for turning a kernel bug into working code execution.
Eighteen years is the headline, not the lesson
The code responsible traces back to Linux 2.6.25, released in December 2007, which puts the bug at roughly 18 years old at the point Tencent's Zhuque Lab found it. The researchers credit the discovery to Corvus AI, an autonomous multi-agent vulnerability-research pipeline the team runs internally, which flagged the ASCONF code path as worth deeper manual review. That detail matters as much as the bug itself: this is not a case of a known-risky area of the kernel finally getting audited, it is a case of a genuinely obscure corner going unexamined for nearly two decades because almost nobody was looking at it.
Stable fixes landed on August 3, 2026, in kernel branches 6.6.148, 6.12.101, 6.18.42 and 7.1.6, and distribution maintainers have started rolling those into their own package trees. That is the part of the story every outlet is reporting, and it is the part that matters least for most readers. An 18-year gap between the bug shipping and the bug being found is proof that a policy of waiting for the fix to arrive already failed silently for eighteen years on this exact code path - there is no reason to assume the next unexamined corner of the kernel will be found any faster, which is why reducing what is actually reachable on a given machine matters independently of any single patch date.
Root access and container escape, demonstrated
Tencent's Zhuque Lab demonstrated the exploit end to end, not just a crash. On systems running Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 and OpenCloudOS, the team turned the use-after-free into full root privilege escalation from an unprivileged local account, then used the same technique to break out of a container into the host in six of eight attempts, without needing CAP_NET_ADMIN or CAP_SYS_ADMIN, the elevated capabilities most container-hardening guides assume an attacker would need first.
The exploit chain defeated kernel address space layout randomization, chained a second use-after-free using attacker-controlled SCTP authentication keys, and built a forged kernel object graph to reach root, all without shellcode or a return-oriented-programming chain, the techniques most kernel exploit mitigations are built to catch. Testing spanned kernel versions from 5.14 through the 7.2 release candidate, and the upstream fix landed as commit 9b2854f86f0b before being backported to the four stable branches named above.
The one-line fix most teams are skipping
The patch is real and worth applying, but it treats a symptom. Almost none of the organizations running these five distributions chose to enable SCTP - it ships compiled into the mainline kernel by default, and most operators have no idea it is there, let alone that a local process can reach it. That is the actual lesson buried in the researchers' own oss-security disclosure thread: one contributor to the thread pointed out that RHEL-family systems keep SCTP out by default, shipped as a separate kernel-modules-extra package with its auto-load blacklisted, while Debian- and Ubuntu-family kernels build SCTP straight in and let it load the moment any process asks for it. Two systems can carry the identical CVE and sit at very different real risk, and the difference has nothing to do with which patch is installed.
The action worth taking this week is not waiting for the distribution update, it is checking whether SCTP is doing anything useful on a given fleet at all. Running lsmod | grep sctp shows whether the module is currently loaded; checking /etc/modprobe.d/ for an existing blacklist entry shows whether auto-load is already blocked. Where nothing legitimately depends on SCTP, and on most general-purpose servers nothing does, blacklisting the module closes the door regardless of which kernel version eventually lands - a habit that lines up with what the UK's National Cyber Security Centre and most national baseline-hardening guides already recommend for any unused kernel module, not just this one.
Read next: Your MSP's RMM Tool Has a Second Bypass Flaw | The Phone Call That Beats Your Company's MFA
