SCTPhantom Linux Kernel Flaw: 18-Year-Old SCTP Bug Enables Root and Container Escape

Researchers at Tencent Zhuque Lab disclosed an 18-year-old Linux kernel vulnerability in the Stream Control Transmission Protocol (SCTP) that could allow a local attacker to gain root privileges and escape container boundaries. Tracked as CVE-2026-64564 and dubbed SCTPhantom, the flaw was fixed in stable kernels released on August 3, but it has existed in every Linux kernel since 2008.

What Happened: SCTPhantom Exploits Identity Confusion in Linux SCTP

SCTPhantom is a use-after-free vulnerability in the kernel’s SCTP Dynamic Address Reconfiguration code. The flaw arises from an identity mismatch during ASCONF message processing, which can cause the kernel to free a transport path and then reuse the dangling pointer. Tencent researchers demonstrated a full exploit chain that turns this primitive into local root and container escape.

The vulnerability was discovered by Corvus AI, a multi-agent research pipeline developed by TencentOS Security Team. It was publicly disclosed on August 6, two days after the Linux CVE team assigned it. Fixes shipped in stable kernels 7.1.6, 6.18.42, 6.12.101, and 6.6.148 on August 3, 2026. Tencent scored the flaw at 8.5 under CVSS v4.0, though NVD had not yet assigned a base score as of early August.

Technical Details of the SCTPhantom Vulnerability

SCTP is a message-oriented transport protocol that supports multihoming, meaning a single connection can span multiple network paths. A companion feature, Dynamic Address Reconfiguration, allows peers to add or remove paths mid-connection via ASCONF chunks.

The bug exists in how the kernel processes ASCONF parameters. The vulnerability follows a specific message ordering that exploits an identity mismatch between the IPv4 packet source address and the transport selected by the ASCONF Address Parameter:

1. The attacker sends an ASCONF chunk containing an Address Parameter (L), a DEL-IP for that same address (L), and a wildcard DEL-IP (0.0.0.0).
2. The DEL-IP for L passes validation against the packet source address (S), even though L and S differ.
3. The transport associated with L is freed via RCU-deferred release.
4. The wildcard DEL-IP then reuses the now-freed transport pointer in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers().
5. The association retains the dangling pointer in primary_path and active_path, where a later socket operation dereferences it.

The upstream patch prevents this by rejecting a DEL-IP that targets the transport against which the ASCONF chunk itself is being processed. Without this guard, the freed pointer propagates into the association’s active state and survives until a later socket operation reaches it.

Exploit Chain: From Use-After-Free to Container Escape

Tencent’s published exploit chain is a multi-stage privilege escalation that reclaims the freed transport slot to build arbitrary kernel memory primitives. The lab reported the following progression:

1. Surviving the use-after-free — The exploit creates a multihomed SCTP association, forces heartbeats until a secondary path becomes ACTIVE, then disables heartbeats to stabilize state. It injects the crafted ASCONF sequence and accesses the stale path through the live socket after RCU release completes.
2. Kernel memory disclosure — The freed kmalloc-1024 transport slot is reclaimed by a TPACKET V1 transmit ring’s pg_vec array. SCTP_STATUS then interprets page pointers as transport fields, leaking a 64-bit kernel page address per attempt.
3. KASLR bypass — Repeated disclosures recover the IDT base address, which defeats Kernel Address Space Layout Randomization.
4. Controlled kernel object graph — A second use-after-free is reclaimed using a crafted SCTP authentication key, producing a controlled object layout.
5. Privilege escalation — The attacker executes commit_creds() via data-oriented programming and reaches global root.
6. Container escape — A usermode-helper variant completes the chain from root inside the container to code execution on the host.

Tencent reported that six of eight attempts reached root on the host under its test conditions. The test preserved the default seccomp profile and granted neither CAP_NET_ADMIN nor CAP_SYS_ADMIN. However, independent reproduction has not been confirmed, and the lab’s write-up does not specify which container runtime was tested.

Business and Operational Impact

SCTPhantom is a local vulnerability, which limits its exposure compared with remotely exploitable flaws. However, the container escape claim raises the stakes for organizations running multi-tenant container workloads on shared hosts.

• Cloud and container environments: Any platform that runs untrusted or semi-trusted containers with SCTP reachable is potentially at risk. The exploit requires local access and SCTP availability, but it does not need privileged container capabilities under Tencent’s reported configuration.
• Kernel age amplifies exposure: The bug has existed since Linux 2.6.25 in 2008. Any system running an unpatched kernel with SCTP support is theoretically vulnerable, even if the distribution itself is still supported.
• Distribution coverage: Tencent tested successful exploitation on Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9, and OpenCloudOS. However, other distributions may backport fixes without changing the upstream version string, so administrators should verify their specific package status.
• No confirmed in-the-wild exploitation: As of early August, no public exploit code had surfaced, and CISA had not added CVE-2026-64564 to its Known Exploited Vulnerabilities catalog. That does not eliminate risk, but it means the window for proactive patching remains open.

Mitigation and Recommendations

Immediate Actions for Defenders

1. Apply kernel updates — Update to a fixed stable release: 7.1.6, 6.18.42, 6.12.101, or 6.6.148. Vendor backports may also be available. Verify fixes through your distribution’s security tracker, not by kernel version string alone.
2. Disable SCTP if unused — If your workloads do not require SCTP, block or blacklist the sctp kernel module. This removes the attack surface entirely. Also consider disabling the Dynamic Address Reconfiguration feature.
3. Audit container runtime configurations — Review whether containers can create SCTP sockets and whether user namespaces or seccomp profiles would block the exploit path. Tencent’s claim of container escape without CAP_NET_ADMIN means runtime defaults may be insufficient.
4. Restrict container socket creation — Tighten seccomp profiles and AppArmor or SELinux policies to limit socket types available to untrusted workloads.

Long-Term Defensive Measures

Organizations should treat kernel vulnerabilities with long dormancy periods as a reminder that legacy protocol code remains an attack surface. Furthermore, the trend of AI-assisted vulnerability discovery means the pace of similar disclosures is likely to increase.

• Integrate kernel security updates into your patch cycle with shorter SLA targets for container hosts.
• Evaluate whether multihoming transport protocols like SCTP are necessary in your environment.
• Monitor CISA KEV catalog and distribution advisories for future updates on CVE-2026-64564.

Bottom line: CVE-2026-64564 is an 18-year-old Linux kernel flaw that researchers have demonstrated as a root and container escape. Patching is the definitive fix, and disabling SCTP is an effective workaround where the protocol is not needed.

Incident Summary

CVE ID / Incident:	CVE-2026-64564 (SCTPhantom)
Affected Systems:	Linux kernels from 2.6.25 through unpatched versions before 7.1.6, 6.18.42, 6.12.101, 6.6.148
Disclosure Date:	August 6, 2026
Patch Status:	Patches available in stable kernels released August 3, 2026
Severity (CVSS 4.0):	8.5 (Tencent assessment); NVD unassigned as of August 7
Attack Vector:	Local — requires SCTP reachable and crafted ASCONF messages
Exploitability:	Proof-of-concept demonstrated by Tencent; no confirmed in-the-wild exploitation

References

1. The Hacker News, “18-Year-Old Linux SCTP Flaw Could Let Local Users Gain Root and Escape Containers,” August 7, 2026, https://thehackernews.com/2026/08/18-year-old-linux-sctp-flaw-could-let.html, accessed August 9, 2026.
2. Tencent Zhuque Lab, “SCTPhantom: An 18-Year-Old SCTP ASCONF Transport Use-After-Free,” Matrix, August 6, 2026, https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564, accessed August 9, 2026.
3. National Vulnerability Database, “CVE-2026-64564 Detail,” NVD, https://nvd.nist.gov/vuln/detail/CVE-2026-64564, accessed August 9, 2026.
4. Linux Kernel Stable Commits, https://git.kernel.org/stable/c/74e8f3e7114f0e26d1b2c4c048044db9fcc27603, accessed August 9, 2026.
5. OpenWall OSS-Security Mailing List, “CVE-2026-64564: Linux kernel SCTP use-after-free,” August 6, 2026, http://www.openwall.com/lists/oss-security/2026/08/06/3, accessed August 9, 2026.