# An 18-Year-Old Bug in Linux's SCTP Stack Can Hand Attackers Root — and Punch Through Containers
## The Threat
A use-after-free vulnerability in the Linux kernel's SCTP networking subsystem has been present in every kernel release since 2008 — and Tencent researchers say they turned it into a full root privilege escalation and a container escape. Tracked as CVE-2026-64564 and branded SCTPhantom by its discoverers at Tencent Zhuque Lab, the flaw lives in the dynamic address reconfiguration (addip) feature of the Stream Control Transmission Protocol, a transport layer alternative to TCP that can maintain a connection across multiple network paths simultaneously.
The bug is a pointer identity mixup. When a peer sends a request to delete one of those network paths, the kernel validates the request against the packet's source address — but then acts on a different path it selected based on an address embedded inside the message body. A crafted SCTP message can carry an address, a delete request for that address, and then a wildcard delete in the same packet. That sequence frees the path struct, then immediately dereferences the now-dead pointer, leaving the kernel's connection table pointing at released memory. The patch is blunt and correct: refuse any delete that targets the path the current message is being processed against.
Tencent's write-up adds a wrinkle that makes this more dangerous than the typical local privilege escalation: the lab claims it escaped a containerized environment using the bug, reaching the host kernel from inside a container that held neither CAP_NET_ADMIN nor CAP_SYS_ADMIN and ran with the default seccomp profile. Six of eight escape attempts succeeded in their testing. No independent reproduction has been published, and the lab did not name the container runtime involved — but the claim deserves to be taken seriously given the team's track record and their detailed technical write-up.
## Severity and Impact
| Field | Details |
|---|---|
| CVE | CVE-2026-64564 |
| Alias | SCTPhantom |
| CVSS Score | 8.5 (High) — CVSS v4.0, Tencent assessment |
| Vector String | NVD assignment pending as of August 7, 2026 |
| Attack Vector | Local (SCTP reachable on target) |
| Attack Complexity | Medium |
| Privileges Required | Low |
| User Interaction | None |
| CWE | CWE-416: Use After Free (NVD classification pending) |
| Impact | Local privilege escalation to root; potential container escape |
| Introduced | Linux 2.6.25 (2008) |
| Public Exploit | None confirmed as of August 7, 2026 |
| CISA KEV | Not listed as of August 7, 2026 |
## Affected Products
The flaw is present in every Linux kernel from 2.6.25 through the pre-patch stable releases. Tencent confirmed root-level exploitation on:
Note: Vendors routinely backport kernel fixes without incrementing their kernel version string. A version number alone will not tell you whether your distribution has applied the patch — check your distro's security tracker directly.
A second use-after-free in the same SCTP transport code was patched on August 6, after the August 3 stable releases had already shipped. Those four stable releases do not include the second fix.
## Mitigations
Patch first. The primary fix shipped in:
All four were released August 3, 2026. If your distribution has picked these up, patching is the complete remediation.
Block the SCTP module if you don't need it. SCTP is not enabled in every deployment. If your environment does not use it, unloading or blacklisting the kernel module eliminates the attack surface entirely:
echo "install sctp /bin/true" >> /etc/modprobe.d/blacklist-sctp.confRestrict addip sysctls. If you cannot immediately patch and must keep SCTP running, disabling dynamic address reconfiguration via net.sctp.addip_enable=0 raises the bar — though Tencent's later exploit variant bypassed this by enabling the feature per socket rather than system-wide.
Audit container policies. If your threat model includes hostile container workloads, verify that your runtime's seccomp and AppArmor/SELinux profiles restrict raw socket access. Tencent's escape used default profiles, which suggests many production container deployments are exposed if the host kernel is unpatched.
Monitor distribution advisories:
## References
---
## HackWire Analysis
SCTPhantom is the second high-profile kernel vulnerability in two months to be credited to a machine-assisted research pipeline — Tencent's Corvus AI, the same multi-agent system that surfaced GhostLock in July. That's worth sitting with. Corvus found an 18-year-old use-after-free that thousands of kernel developers, static analyzers, and fuzzers walked past for two decades. If AI-assisted kernel auditing is now consistently surfacing pre-2010 code with exploitable memory safety bugs, we should expect this cadence to continue, not slow down.
The container escape claim is the part that demands the most scrutiny — and the most caution. Tencent says six of eight escapes succeeded with default seccomp and no privileged capabilities. That's a meaningful result even without independent replication, because it narrows the exploitability gap that security teams often rely on to deprioritize local privilege escalations in containerized environments. The standard mental model — "it's local-only, and containers limit what you can do locally" — just took a hit. Cloud providers, Kubernetes operators, and CI/CD platforms that run untrusted or semi-trusted workloads in containers on shared kernels should treat this as a patching emergency, not a scheduled maintenance item.
The timing also matters: SCTPhantom landed the same day as Zapscape, a KVM escape affecting the same four stable kernel releases. Two host-escape primitives in one patch cycle, both fixed together, neither yet in CISA's KEV catalog. That's not an excuse to wait — it's a reason to move faster. Organizations running shared compute infrastructure with older kernels owe themselves an answer to a simple question: can an attacker reach SCTP on your hosts? If you don't know, find out today.
— HackWire Editorial
---
## Related Coverage