SCTPhantom, the 18-Year-Old Linux SCTP Flaw That Hands Attackers Root and Breaks Container Isolation

On August 4, 2026, the TencentOS Security Team disclosed CVE-2026-64564, a Linux kernel vulnerability now called SCTPhantom. The vulnerable code was introduced in Linux 2.6.25, shipped in December 2007 — it took nearly 18 years to find. The flaw yields local privilege escalation to root and, more critically, reliable container-to-host escape. It was validated against Ubuntu 24.04, Debian 13, Rocky Linux 9, and kernels from 5.14 up through a 7.2 release candidate, earning a CVSS 4.0 score of 8.5.

The culprit is SCTP (Stream Control Transmission Protocol), a lesser-known TCP cousin designed for telecom signaling that almost nobody uses — but nearly everyone compiles into their kernel anyway.

An Identity Mismatch Inside ASCONF

The bug lives in SCTP’s Dynamic Address Reconfiguration feature, defined by RFC 5061. This extension lets an SCTP association add, remove, or reconfigure network paths on the fly via ASCONF chunks. The address-deletion logic (DEL-IP) validates the delete operation using the packet’s source address, while a separate cached pointer relies on the address parameter that was used to select the actual network transport.

A local attacker can craft an ordered ASCONF sequence: specify an address, request its deletion, then send a wildcard delete. The kernel removes the corresponding transport, but a stale pointer remains in the association’s active path and primary path fields. A subsequent socket operation dereferences this freed memory — the use-after-free condition is live.

TencentOS researchers, armed with their autonomous vulnerability-hunting system Corvus AI, turned this raw memory bug into a full exploit chain. Their approach reclaims the freed transport using a packet socket ring buffer, which leaks a kernel memory address in the process. That leak enables a repeatable four-byte kernel read, used to defeat KASLR by inspecting the interrupt descriptor table (IDT).

A second use-after-free is then triggered with attacker-controlled SCTP authentication key data, constructing a fake kernel object graph that ultimately calls commit_creds — granting global root, all without shellcode or a traditional ROP chain.

Container Escape Is the Real Threat

The most troubling demonstration is the container escape. By using per-socket SCTP options instead of system-wide sysctls, the exploit avoided needing elevated capabilities. It broke out of containers running default seccomp profiles in six out of eight attempts, ultimately triggering a usermode-helper process executing in the host’s initial namespace.

For a multi-tenant Kubernetes node, this means a single compromised container lets an attacker pivot to every other workload on that node, then to the host itself.

The affected surface is broad because SCTP is enabled by default in virtually every distribution kernel. The good news: the fix was merged upstream as commit 9b2854f86f0b and backported to stable branches 6.6.148, 6.12.101, 6.18.42, and 7.1.6.

Immediate Action Plan

If you cannot update immediately, disable the sctp module (modprobe -r sctp then blacklist it in /etc/modprobe.d/) if your workload allows. In Kubernetes, deploy a PodSecurityPolicy or seccomp profile that blocks SCTP syscalls (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)).

SCTPhantom surfaces an uncomfortable truth: the Linux kernel’s networking code is a living museum. Every protocol you leave compiled in “just in case” is an attack surface that can sleep for two decades. Configuration minimalism is not an aesthetic preference — it is a security policy.

References

• TencentOS Security — SCTPhantom Technical Analysis (August 6, 2026)
• Cyber Security News — 18-Year-Old Linux Kernel SCTP Vulnerability (August 7, 2026)
• Linux Kernel CVE Announcement — CVE-2026-64564 (August 4, 2026)
• RFC 5061 — SCTP Dynamic Address Reconfiguration