Threat Intel

SCTPhantom: An 18-Year-Old SCTP Bug That Reaches Root and Escapes Containers

The Linux SCTP module freeing and reusing a transport pointer during address reconfiguration.

The first question with SCTPhantom isn't "should I patch," it's "is SCTP even loaded on this host," because for most servers the answer is no and the whole thing is moot, and for the ones where it's yes, you have a local-root and container-escape problem that's been sitting in the kernel since 2008. CVE-2026-64564, named SCTPhantom by Tencent's Zhuque Lab, is a use-after-free in Linux's SCTP address-reconfiguration code. Fixed kernels (7.1.6, 6.18.42, 6.12.101, 6.6.148) shipped August 3, and public disclosure followed on August 6. This is the triage-first writeup: check your exposure in one command, then patch or, better for most, remove the attack surface entirely.

The One Command That Decides Your Urgency

⚠️ Before anything else: SCTP is a niche transport protocol. The vast majority of servers never use it, and if the module isn't loaded, this CVE can't touch you. Check every host:

lsmod | grep sctp

Empty output means SCTP isn't loaded and you're not exposed through this path (though it can still be autoloaded on demand, see the block below). If it is listed, this host is in scope and you either patch or block. Across a fleet, from a management host:

for h in $(cat hosts.txt); do printf '%s: ' "$h"; ssh -o ConnectTimeout=5 "root@$h" 'lsmod | grep -q sctp && echo "SCTP LOADED - in scope" || echo "not loaded"' 2>/dev/null || echo UNREACHABLE; done

That one loop tells you which of your servers actually need action, which is usually a small subset.

What the Bug Is

SCTP is a transport protocol that runs one logical connection over several network paths at once. A companion feature, dynamic address reconfiguration (ASCONF), lets a peer add or drop those addresses mid-connection. The bug lives there.

It's a confusion over identity. The kernel validates a delete request against the packet's source address, but then acts on a path it selected using a different address carried inside the message. Per the kernel advisory, a single crafted message can carry an address, a delete for that same address, then a wildcard delete. That sequence frees the transport path, then reuses the now-dangling pointer, leaving the connection pointing at memory the kernel already released, a classic use-after-free, and use-after-free in kernel network code is the well-trodden road to arbitrary code execution as root.

The fix refuses a delete aimed at the path the message is currently being processed against. The vulnerable code traces to Linux 2.6.25 in 2008, so every kernel released in the last 18 years carries it until patched. This is the same "one disclosure surfaces a long-dormant bug, and it turns out to have been there for a decade-plus" pattern running through the whole recent kernel-LPE wave, and it's exactly the dynamic the collapsing patch-to-exploit window piece is about: Tencent credits the find to Corvus AI, a multi-agent research pipeline built for kernel work, making SCTPhantom another machine-assisted discovery of an old flaw.

The Container-Escape Claim, Calibrated

⚠️ The headline that'll drive the panic is "container escape," so calibrate it honestly. Tencent's Zhuque Lab reports it used SCTPhantom to escape a container and reach the host, and got root on tested kernel builds for Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9, and OpenCloudOS. It also says its escape test kept the default seccomp profile and granted neither CAP_NET_ADMIN nor CAP_SYS_ADMIN, six of eight attempts reached host root by its count. If accurate, that's serious: it means a fairly ordinary container, not a --privileged one, could be enough.

But hold it at the right confidence level, because the caveats are real:

No one outside Tencent has reproduced it, and the write-up doesn't name the container runtime it tested against.
The lab itself notes that socket access, seccomp profiles, and user-namespace policy all shift exposure, so your configuration may not match its test conditions.
An openKylin advisory for the same bug goes no further than kernel panic and denial of service, not code execution, which is a materially less severe claim from another vendor looking at the same flaw.
The severity is unsettled: Tencent scored it 8.5 (CVSS v4.0); NVD had assigned neither a score nor a weakness classification as of August 7.

The honest read: local root on an unpatched host with SCTP reachable is well-supported; the reliable-container-escape-from-a-default-profile claim is one lab's testing pending independent reproduction. Treat SCTP-reachable multi-tenant container hosts as high priority regardless, because even the conservative reading (kernel panic / DoS from within a container) is a tenant knocking over your host, and the aggressive reading is far worse.

Patch, and Mind the Version-String Trap

Fixed stable kernels shipped August 3: 7.1.6, 6.18.42, 6.12.101, 6.6.148. Update and reboot into a fixed kernel.

⚠️ Do not trust uname -r alone. Distributions backport fixes without bumping to a new upstream version, so a kernel string that looks "old" may already carry the patch, and one that looks current may not. Check your distro's security tracker or the changelog:

zgrep -iE 'CVE-2026-64564|SCTP.*ASCONF|sctp.*transport' /usr/share/doc/*/changelog.Debian.gz 2>/dev/null | head

On RHEL-family:

rpm -q --changelog kernel 2>/dev/null | grep -iE 'CVE-2026-64564|sctp.*ASCONF' | head

⚠️ One more subtlety: a second dangling-transport use-after-free in the same SCTP code was patched on August 6, after the August 3 stable releases. So the four kernels above fix SCTPhantom but not that second bug. If you're hardening SCTP seriously, get a kernel dated after August 6, not just the SCTPhantom-fixed August 3 builds.

The Better Fix for Most: Remove the Attack Surface

⚠️ Here's the move most guides bury: if a host doesn't need SCTP (and most don't), don't just patch the bug, remove the ability to load the module at all, so this CVE and the next SCTP bug both become non-issues. Block it:

echo 'install sctp /bin/true' | sudo tee /etc/modprobe.d/disable-sctp.conf

That prevents the sctp module from being loaded on demand (a socket request for SCTP silently gets nothing instead of autoloading the vulnerable code). ⚠️ If SCTP is already loaded on a running host, the modprobe block only takes effect for future loads, so on a box where lsmod showed it loaded, either unload it (sudo modprobe -r sctp, which fails if it's in use) or reboot after adding the block. And ⚠️ confirm nothing actually needs SCTP first, it's used by some telecom/SS7 signaling stacks, certain clustering software, and specialized applications; blocking it there breaks them. For a normal web/app/database server, blocking SCTP is safe and eliminates a whole class of future SCTP CVEs, not just this one.

A useful hardening note from the older SCTP-container-DoS work (CVE-2019-3874): SELinux in enforcing mode blocks non-root users from binding SCTP sockets, which raises the bar for reaching this code path. If you run SELinux enforcing, that's partial mitigation; if you've set it permissive or disabled, that's one more reason to reconsider on multi-tenant hosts. The module block is the stronger, distro-agnostic control.

For Container Hosts Specifically

If you run containers on a kernel where SCTP is loaded, this is the priority tier. The durable defenses are the ones that don't depend on this specific CVE:

Block the SCTP module on the host (above), the single most effective control, since containers share the host kernel and can't load what the host forbids.
Drop CAP_NET_ADMIN and CAP_SYS_ADMIN from containers that don't need them (most don't), with --cap-drop=ALL and selective add-back. Even though Tencent claims the escape worked without these, least-capability is the correct posture and narrows the broader attack surface.
Keep the default seccomp profile or tighten it, and block CAP_SYS_MODULE so a container can't load modules itself.

This is the same shared-kernel reality I keep returning to in verifying container isolation and locking down the kernel against module-based attacks: the container boundary is namespaces over a shared kernel, so a kernel UAF is a container-escape primitive regardless of how clean your container config is, and host kernel patching plus module-surface reduction is the actual defense. The forensic order if you suspect a host was hit is the same as any kernel compromise, captured in the DirtyClone and pedit COW writeups: preserve volatile state before reboot, assume secrets are burned, rebuild over clean.

Bottom Line

SCTPhantom is a genuine local-root-and-maybe-container-escape bug, but its blast radius is gated by one question most operators can answer in a command: is the SCTP module loaded? For the many hosts where it isn't, block it permanently and move on. For the ones where it is, patch to a post-August-6 kernel (to also catch the second SCTP UAF), and on container hosts treat it as high priority while remembering the fix that outlasts this CVE, remove the SCTP module surface and drop unneeded capabilities, so the next 18-year-old SCTP bug finds nothing to exploit. Independent reproduction of the container-escape claim is still pending, but "wait and see" is the wrong posture when the mitigation is one modprobe.d line.