A newly disclosed Linux kernel vulnerability nicknamed SCTPhantom and tracked as CVE-2026-64564 lets an attacker with only unprivileged local access climb all the way to full root — and, in a striking number of test cases, break out of a container to compromise the host system underneath it.

A Bug Nearly Two Decades in the Making

What makes SCTPhantom particularly notable isn’t just its severity, but its age. The flaw is a use-after-free bug in the kernel’s SCTP Dynamic Address Reconfiguration feature, and its root cause traces back to code first introduced in Linux 2.6.25, released in December 2007. That means the bug sat undiscovered in the kernel for nearly 18 years before researchers finally uncovered it.

The vulnerability lives in how the kernel processes ASCONF chunks, a mechanism defined in RFC 5061 that allows SCTP network associations to add, remove, or reconfigure paths on the fly. At the heart of the bug is an identity mismatch: when the kernel validates a delete-IP operation, it checks the packet’s source address, but a separate cached pointer elsewhere in the code relies on the address parameter used to select the actual network transport. By carefully sequencing ASCONF messages — specifying an address, deleting that same address, then sending a wildcard delete — an attacker can trick the kernel into removing a transport object while a stale reference to it still lingers in the association’s active and primary path pointers. When a later socket operation touches that stale reference, it dereferences freed memory, creating the use-after-free condition attackers can build on.

From Memory Bug to Full Root, Without Shellcode

Researchers at the TencentOS Security Team, using an autonomous vulnerability-research system called Corvus AI, turned this raw memory-corruption bug into a complete, repeatable privilege-escalation chain. The exploit first reclaims the freed transport object using a packet socket ring buffer, which leaks a kernel memory address in the process. That leak provides a repeatable four-byte kernel read, which the researchers used to defeat kernel address space layout randomization (KASLR) by inspecting the interrupt descriptor table.

From there, a second use-after-free — this time exploited with attacker-controlled SCTP authentication key data — lets the exploit construct a fake kernel object graph. That fake graph is ultimately used to trigger the kernel’s commit_creds function, handing the attacker global root privileges. Notably, the entire chain avoids both shellcode and a traditional return-oriented-programming (ROP) chain, relying instead on manipulating kernel data structures directly.

Escaping the Container, Too

The researchers didn’t stop at local privilege escalation. By using per-socket SCTP options rather than system-wide sysctls, they built a variant of the exploit that avoids needing elevated capabilities inside a container — and successfully broke out of containers running default seccomp profiles in six of eight attempts, ultimately triggering a usermode-helper process running in the host’s initial namespace.

The exploit chain was validated across a broad range of environments, including:

• Ubuntu 24.04
• Debian 13
• Rocky Linux 9
• Multiple kernel builds spanning 5.14 through a 7.2 release candidate

Root access was achieved in every environment tested, underscoring how broadly the flaw applies across current Linux distributions rather than being limited to a narrow set of configurations.

Severity and Patch Status

Under CVSS v4.0, the flaw carries a base score of 8.5, rated High severity — a reflection of its low attack complexity combined with high impact on confidentiality, integrity, and availability. The Linux kernel CVE team formally announced CVE-2026-64564 on August 4, 2026, following a private disclosure process that began on July 12.

The upstream fix, merged as commit 9b2854f86f0b, closes the gap by rejecting any delete-IP request that targets a transport still referenced by the current ASCONF chunk. Patches have already been backported to several stable kernel branches, including 6.6.148, 6.12.101, 6.18.42, and 7.1.6.

What System Administrators Should Do

Given the demonstrated ease of exploitation, the severity of impact, and the fact that a working exploit chain has already been publicly documented, administrators running SCTP-enabled kernels should treat patching as urgent rather than routine — particularly in multi-tenant or containerized environments where a single compromised workload could otherwise be used to pivot to the underlying host. Recommended steps include:

• Updating to a fixed kernel version (6.6.148, 6.12.101, 6.18.42, 7.1.6, or later) as soon as possible
• Auditing which workloads actually require SCTP and disabling the protocol where it isn’t needed
• Paying particular attention to multi-tenant and containerized hosts, where the demonstrated container-escape path raises the stakes of a successful exploit

SCTPhantom is a reminder that even rarely used kernel subsystems can hide serious, long-lived bugs — and that AI-assisted vulnerability research is increasingly capable of turning obscure memory bugs into fully weaponized exploit chains.