18-Year-Old Linux SCTP Flaw Grants Root Access and Enables Container Escapes

A use-after-free vulnerability in Linux's SCTP networking code — dormant since 2008 — can hand a local attacker full root privileges and allow escape from containerized environments, Tencent researchers revealed on August 6, 2026.

Tracked as CVE-2026-64564 and dubbed SCTPhantom by its discoverers at Tencent Zhuque Lab, the flaw affects every Linux kernel released over the past 18 years. Patches shipped on August 3 in stable kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148 — three days before public disclosure — giving administrators a narrow but critical window to act before details became widely available.

The vulnerability underscores a growing and uncomfortable reality in open-source security: bugs of significant consequence can survive undetected across decades of active development, and when they finally surface, the blast radius can be considerable. Understanding your exposure begins with knowing what you're running — and conducting a structured vulnerability assessment across your infrastructure is the most reliable starting point.

---

How SCTPhantom Works

The Protocol at the Centre of the Flaw

SCTP — Stream Control Transmission Protocol — is a transport-layer protocol that supports multi-path connections, meaning a single session can run across several network interfaces simultaneously. A companion feature called dynamic address reconfiguration allows peers to add or remove those network paths mid-connection.

SCTPhantom exploits a fundamental identity mix-up inside that reconfiguration process. The Linux kernel validates a delete request against the source address of an incoming packet but then acts on a different path — one selected using an address embedded inside the message body itself. That mismatch creates a dangerous sequence.

The Mechanics of Exploitation

According to the kernel's own advisory, a single crafted message can carry an address, a delete request targeting that same address, and then a wildcard delete. The kernel frees the path object and then immediately reuses the now-dead pointer. The connection ends up pointing at memory the kernel has already released — a classic use-after-free condition that skilled attackers can convert into arbitrary code execution.

The patch resolves this by refusing any delete instruction aimed at the path currently being processed. It is a targeted fix, but an important one given how long the flaw evaded detection.

Why use-after-free vulnerabilities matter: This class of flaw occurs when a program continues to reference memory after it has been freed. Attackers who can control what data occupies that freed memory can redirect execution flow, escalate privileges, or — as demonstrated here — escape sandboxed environments entirely. It remains one of the most reliably exploitable vulnerability classes in kernel-level code.

---

Confirmed Targets and Container Escape Claims

Affected Distributions

Tencent Zhuque Lab reports successful root access on tested builds of Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 and OpenCloudOS. Six of eight container escape attempts reached root on the underlying host during the lab's internal testing.

What the Container Escape Results Actually Mean

The container escape findings carry an important caveat. An early version of the exploit required two specific kernel sysctls — net.sctp.addip_enable and net.sctp.addip_noauth_enable — to be enabled, which would have implied a need for elevated privileges. The lab later identified a path that activates those features at the socket level instead, bypassing that requirement entirely. The lab says its final test maintained the default seccomp profile and granted neither CAP_NET_ADMIN nor CAP_SYS_ADMIN.

No independent researchers had reproduced the container escape as of August 7. The Tencent write-up does not name the specific container runtime used in testing. The lab itself acknowledges that socket access policies, seccomp profiles and user-namespace configurations all affect actual exposure in a given environment.

A separate advisory from openKylin covering the same CVE goes no further than describing kernel panic and denial-of-service as potential outcomes — a notably more conservative assessment than Tencent's findings.

Severity Score

The severity score remains contested. Tencent assigned it an 8.5 under CVSS v4.0. The National Vulnerability Database had not yet assigned a score or weakness classification as of August 7. The gap between Tencent's assessment and openKylin's more cautious framing reflects a broader challenge in vulnerability disclosure: real-world exploitability depends heavily on environmental configuration, and headline severity scores rarely capture that nuance.

---

Discovery, Disclosure, and What Administrators Should Do Now

How SCTPhantom Was Found

SCTPhantom was discovered using Corvus AI, a multi-agent research pipeline Tencent built specifically for kernel vulnerability work. The finding makes SCTPhantom the latest in a series of long-dormant kernel flaws surfaced with machine assistance in 2026, following GhostLock in July. AI-assisted vulnerability research is proving remarkably capable at identifying flaws that survived years of human code review — a trend that shows no signs of slowing.

The disclosure lands on the same day as Zapscape, an unrelated KVM escape vulnerability. Both flaws are addressed in the same four August 3 stable kernel releases, meaning a single update cycle covers both.

A Second Flaw in the Same Code

A second use-after-free vulnerability in the same SCTP code was patched on August 6, after the August 3 stable releases had already shipped. Systems updated to those releases will need an additional patch to cover this second flaw. Administrators who updated promptly and considered themselves protected should verify their patch status against their distribution's security tracker.

The Exploit Status as of August 7

No public exploit code had appeared as of August 7. The Hacker News found no entry for CVE-2026-64564 in CISA's Known Exploited Vulnerabilities catalog at the time of writing. That status can change without warning, and the level of technical detail now publicly available meaningfully shortens the time between disclosure and working exploit code in the hands of threat actors.

Immediate Steps for Security and Operations Teams

Administrators should note that vendors frequently backport fixes without incrementing the upstream kernel version number. A version string alone is not sufficient to confirm whether a system is protected. Checking the relevant distribution's security tracker — for Red Hat, Debian, Ubuntu or Rocky Linux — is the only reliable method.

Where SCTP is not operationally required, blocking the kernel module eliminates the attack surface entirely. For teams looking to build more structured and repeatable processes around events like this, following a proven framework for organisational cyber security provides the operational foundation that turns reactive patching into a managed, predictable discipline.

Security teams and DevOps engineers can take three immediate actions from this disclosure:

1. Verify kernel versions against distribution-specific security trackers rather than relying on upstream version strings alone.
2. Audit SCTP usage across your environment and disable the module if it is not operationally required — this eliminates the attack surface entirely.
3. Review seccomp profiles and user-namespace policies in containerised workloads. Even where the flaw has been patched, tightening those controls reduces exposure to future vulnerabilities in the same code paths.

For organisations running containerised infrastructure at scale, this disclosure is also a timely prompt to evaluate whether your container runtime's default configurations align with the principle of least privilege. Tencent's bypass of the default seccomp profile in some test configurations demonstrates that defaults, while a reasonable starting point, are not a substitute for deliberate hardening. Regular penetration testing of your network and containerised environments remains one of the most effective ways to identify exploitable configuration gaps before an attacker does.