SCTPhantom: 18-Year-Old Linux Kernel SCTP Root Flaw

A bug that has sat quietly in the Linux kernel since 2007 is now public. On August 6, 2026, researchers at Tencent Zhuque Lab disclosed SCTPhantom, tracked as CVE-2026-64564 — a use-after-free vulnerability in the kernel’s Stream Control Transmission Protocol (SCTP) code. A local attacker who can reach an SCTP socket can exploit the flaw to escalate privileges to root and, in some configurations, break out of a container onto the host. The bug carries a CVSS v4.0 base score of 8.5, and fixes have already landed in the stable kernel trees.

The detail that has drawn the most attention is its age. The faulty logic traces back to code introduced in Linux 2.6.25 in December 2007, making SCTPhantom nearly 18 years old — a reminder that mature, heavily reviewed kernel subsystems can still hide serious memory-safety defects for the better part of two decades.

What SCTP is, and why it matters here

SCTP is a transport protocol that sits alongside TCP and UDP. It was designed for telephony signaling and is used in some telecom, clustering, and specialized enterprise workloads, but most general-purpose servers never touch it. That relative obscurity is central to the story: SCTP has seen far less adversarial scrutiny than TCP, and its ASCONF extension — the feature at the heart of this bug — is a niche corner of a niche protocol.

ASCONF (Address Configuration Change) lets an established SCTP association add or remove IP addresses on the fly, which is useful for multi-homed hosts that change network paths mid-connection. It is exactly the kind of rarely exercised, state-heavy code path where lingering memory-safety bugs tend to survive.

The root cause

According to Tencent’s write-up, SCTPhantom stems from a mismatch between two different identities the kernel uses while processing an ASCONF chunk. One is the IPv4 source address of the packet, used for the DEL-IP validation check that decides whether a delete request is legitimate. The other is the Address Parameter carried inside the chunk, used to select which transport object actually gets removed.

Because the check and the action key off different values, an attacker can craft an ordered sequence of ASCONF operations that passes validation against one address while causing the kernel to free a live transport object referenced by another. After the free, the association’s primary_path and active_path pointers still point at the now-released memory — a classic dangling reference. Any subsequent use of those pointers is a use-after-free, and with careful heap grooming that stale reference becomes a foothold for corrupting kernel memory and rewriting execution to attacker-controlled code.

Unlike a race condition, which depends on winning a timing window, SCTPhantom is triggered by a deterministic, attacker-ordered message sequence — which tends to make exploitation more reliable once the primitive is understood.

Impact: root and container escape

The practical consequence is local privilege escalation. Tencent Zhuque Lab reported obtaining root on the kernel builds it tested across a broad set of mainstream distributions: Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9, and OpenCloudOS. That breadth matters — this is not a single-distro quirk but a defect in shared upstream code that ships nearly everywhere.

More concerning for cloud operators, the researchers said that in certain configurations the flaw can be used to escape from a container to the host. Container isolation ultimately rests on the shared host kernel, so a kernel-level use-after-free that yields code execution can, depending on the sandbox’s syscall and capability restrictions, punch straight through the boundary between a container and the machine it runs on. For anyone running multi-tenant Kubernetes clusters, a container-escape primitive is close to the worst category of bug: it collapses the assumption that a compromised workload stays contained.

What limits the blast radius

There are meaningful constraints. SCTPhantom is a local vulnerability, not a remotely exploitable one — an attacker already needs the ability to run code on the target, whether as an unprivileged local user or inside a container. It also requires that SCTP be reachable on the system. On the many servers where the SCTP module is never loaded, the attack surface simply isn’t present.

That combination keeps SCTPhantom well short of a wormable, internet-facing emergency like the maximum-severity edge-appliance zero-days that have defined much of 2026’s security calendar. But privilege-escalation and container-escape bugs are the bread and butter of real-world intrusions: attackers routinely chain a low-privilege foothold — a phished credential, a compromised web app, a malicious container image — into full system control. A reliable local-to-root primitive is precisely the second stage such an attack needs.

The fix and mitigations

The bug has been patched upstream via kernel commit 9b2854f86f0b, and the fix has been backported to the stable branches, including 6.6.148, 6.12.101, 6.18.42, and 7.1.6. Distribution vendors have begun shipping updated kernels; the Debian 13 security update that carries the SCTPhantom fix also addresses a separate kernel flaw disclosed in the same window.

For defenders, the guidance is straightforward:

• Patch. Update to a fixed kernel build from your distribution and reboot. This is the only complete fix.
• Reduce the attack surface. On systems that do not use SCTP — which is most — prevent the module from loading by blacklisting it, so the vulnerable code path is never reachable. This is a durable hardening step, not just a stopgap.
• Harden container runtimes. Restrict the syscalls and capabilities available to workloads with tight seccomp and Linux Security Module profiles, which raises the cost of turning a kernel bug into a full escape.

The AI angle

One detail is worth flagging on its own. Tencent attributes the discovery to its Corvus AI project, part of a broader industry shift in which AI systems are increasingly used to hunt for deep bugs in complex, low-level code. Machine-assisted analysis is proving well suited to exactly this problem — reasoning about long, stateful protocol paths like SCTP’s ASCONF handling, where a decades-old flaw slipped past years of human review. It is a live example of the trend behind AI red-teaming: the same capabilities that help attackers find flaws are being turned toward finding and fixing them first.

What it means

SCTPhantom is not a five-alarm remote exploit, and system administrators should resist treating it like one. It is something arguably more instructive: a local privilege-escalation and container-escape bug in ubiquitous upstream code, hiding in plain sight since 2007. Its practical danger is as the second link in an attack chain — the step that converts a modest foothold into root, or a contained workload into host compromise.

Who should act first. Multi-tenant cloud and container operators carry the most exposure, because the container-escape path directly threatens the isolation their platforms are built on; they should prioritize patching kernels and tightening runtime sandboxes. Telecom and clustering environments that genuinely use SCTP need the fix urgently. Everyone else should patch on the normal cycle and, where SCTP is unused, disable the module to remove the surface entirely.

The broader lesson. The recurring pattern of long-dormant memory-safety flaws surfacing in the kernel — the same class of defect that has driven the industry’s push toward memory-safe languages — is exactly why understanding use-after-free bugs and staying disciplined about patching remains foundational. And the fact that this one was found by an AI-driven research effort hints at what’s coming: as machine-assisted bug hunting matures, expect more decades-old flaws to be pulled out of the kernel’s quietest corners, whether reported responsibly — as SCTPhantom was — or discovered as an unpatched zero-day by someone with worse intentions.