News › security
By The Linux Camp News, September 19, 2026
SCTPhantom is a kernel memory-lifetime flaw with demonstrated root access and container escape. Here is how it works, what the exposure depends on, and how to check the running kernel against a vendor fix.
An old bug can remain dangerous because its age says nothing about whether its code path is safe. SCTPhantom, tracked as CVE-2026-64564, is a memory-lifetime flaw in Linux's SCTP implementation. Researchers demonstrated root access and container escape on tested systems. The useful question for an administrator is whether the vulnerable functionality is reachable and whether the running vendor kernel includes the fix. Research disclosure
The vulnerable sequence was present in Linux 2.6.25, released in 2008. That is the origin of the “18-year-old” description. It does not establish that attackers exploited the flaw for that entire period. Discovery, proof of exploitation, public disclosure and exploitation in the wild are different events. Original timeline
SCTP stands for Stream Control Transmission Protocol. It transports messages and supports multiple network paths within one connection, called an association. Originally designed for telephone signaling, it also has other applications. Its dynamic address-reconfiguration extension lets peers change the addresses associated with a connection. SCTP standard · Address reconfiguration
The defect is an identity mismatch during address removal. A check protected the packet's source address, while processing retained a reference to a transport selected through a different address. A particular sequence could remove that transport and later reuse the reference. The kernel would then be dealing with memory whose original object had already been freed. The upstream patch rejects deletion of the transport still needed to process the request. Linux CVE record
Think of a storage locker and its claim ticket. Returning the locker makes it available for someone else, but an old ticket still names the same locker. Treating its new contents as your original belongings is the mistake. In a use-after-free bug, the ticket is a pointer and the locker is a memory allocation. The analogy explains the lifetime problem; it does not imply that every stale pointer can be turned into a working exploit.
Ordinary Linux containers share a host kernel. Process isolation therefore depends in part on that shared kernel behaving correctly. A kernel compromise can undermine the boundary. Tencent's reported escape applies to its tested configuration; it is not proof that every container runtime or policy has the same exposure. Research results and constraints
Early coverage focused on local privilege escalation. Current Red Hat guidance also warns about crafted traffic from a remote SCTP peer. Reachable protocol features and configuration matter, so neither “all Linux is remotely compromised” nor “this is local only” is a sound blanket conclusion. Red Hat advisory
The video uses these read-only commands on a physical RHEL 9.5 server:
uname -r
rpm -q kernel-coreThe capture reported a running release of 5.14.0-503.40.1.el9_5.x86_64 and a matching installed kernel-core package. These are inventory observations, not an exploit test or a vulnerability verdict. uname -r identifies what is executing now. The package query lists what is installed; other machines may have several versions installed at once.
Do not judge a vendor kernel solely by its 5.14 base version. Vendors can backport a fix while retaining an older upstream version number. Match the complete package release and operating-system release against the advisory for this exact CVE. An installed update also needs to become the running kernel; verify the active version after the planned reboot. How Red Hat backports fixes
For systems that do not need SCTP, Red Hat documents preventing its module from loading as a mitigation, including the required initramfs and reboot steps. Disabling a protocol can disrupt applications that depend on it, so follow the complete vendor procedure. The video made no configuration changes and ran no exploit. Mitigation guidance
Correction, 22 September 2026: We removed an unsupported claim that CISA had added this CVE to its Known Exploited Vulnerabilities catalog. The official catalog snapshot dated 22 September did not contain CVE-2026-64564. Absence from KEV does not prove that exploitation has never occurred. CISA catalog