SCTPhantom CVE-2026-64564: an 18-year-old Linux flaw led to root

SCTPhantom, tracked as CVE-2026-64564, is a use-after-free vulnerability in the Linux kernel’s SCTP implementation. Code introduced around 2008 incorrectly handled address removal during Dynamic Address Reconfiguration. A local attacker able to interact with an SCTP socket could make the kernel use a freed transport structure and turn memory corruption into root privileges.

Tencent Zhuque Lab researchers reported successful privilege escalation in tested configurations of Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 and OpenCloudOS. They also demonstrated container escape where a process could reach the host’s vulnerable SCTP path. This does not make every container automatically vulnerable: the relevant namespaces, modules, capabilities and protocol access still have to be available.

Where the use-after-free occurs

SCTP can maintain multiple addresses for one association. Its dynamic reconfiguration extension permits addresses to be added or removed while a connection remains active. The kernel must associate the address with the correct transport object, determine whether deletion is safe, retire references and prevent later use of a stale pointer.

In the vulnerable path, the address validated before a DEL-IP operation did not always match the transport subsequently selected by the networking stack. An object could be removed while another part of the handler still retained its pointer. A later event then used freed memory. If an attacker can shape heap allocations, a new object may occupy the same location and alter data interpreted by the kernel.

The CVE-2026-64564 record classifies the bug in the Linux networking subsystem. The fix keeps the object being validated consistent with the transport used by later logic and closes the stale-reference path.

Why containers do not provide a kernel boundary

A container shares its host’s kernel. A network namespace isolates the view of interfaces and sockets but does not create a separate kernel. If a process can invoke vulnerable host networking code, a memory-safety bug executes beneath the namespace boundary. Exploitability therefore depends on capabilities, seccomp policy, SCTP module availability, network configuration and the running kernel version.

SCTP should not be disabled blindly in telecommunications, signalling networks or systems that genuinely require it. Inventory comes first, followed by patching and a controlled reduction of the attack surface.

Patching and detection work

1. Install a fixed kernel. Listed stable releases include 7.1.6, 6.18.42, 6.12.101 and 6.6.148; for a distribution kernel, follow its backport status rather than comparing upstream numbers alone.
2. Reboot the host and verify uname -r; having the package on disk does not mean the corrected kernel is running.
3. Identify where the sctp module is loaded and which services, pods and containers create SCTP sockets.
4. Where the protocol is unnecessary, prevent automatic module loading and restrict the relevant socket families through seccomp or runtime policy.
5. Remove unnecessary network capabilities, avoid privileged containers and restrict host-network access.
6. Monitor crashes, KASAN warnings, kernel Oops events, unusual SCTP module loads and processes opening sockets for the protocol.
7. After suspected exploitation, treat the host and all shared secrets as potentially compromised; restarting a container does not remove kernel-level root access.

Facts and Breachroad analysis

Public information confirms the use-after-free, local attack model, long lifetime of the defect and stable-branch fixes. Research results across several distributions demonstrate feasibility but do not establish identical exploitability in every container configuration. Prioritising multi-tenant hosts is Breachroad’s conclusion based on the shared kernel and the larger population of untrusted processes.

Infrastructure security training helps teams understand isolation boundaries, while a cloud and container security assessment connects kernel versions to actual protocol exposure and workload privileges.