A serious Linux security issue is back in the spotlight: the SCTP Phantom Linux bug is a use-after-free flaw in the kernel’s SCTP networking code. According to researchers at Tencent Zhuque Lab, the bug can be turned into full root on a host and was used in testing to escape a container and reach the underlying system.
The vulnerability is tracked as CVE-2026-64564 and was publicly disclosed on August 6. Fixes were already released earlier in the month, so the most practical advice is straightforward: update your Linux kernel—especially if your environment exposes SCTP.
What is the SCTP Phantom Linux bug?
SCTP (Stream Control Transmission Protocol) is a transport protocol that can carry one connection across multiple network paths at the same time. Linux also supports dynamic address reconfiguration, which allows peers to add or remove addresses while the connection is ongoing.
The problem sits in how the kernel handles identity and cleanup for these SCTP paths. In simplified terms, the kernel checks a delete request against one source address, but later acts on a path chosen using a different address that appears inside the same message. That mismatch can free internal path data and then continue using it via a stale reference.
Because the flaw is a use-after-free, it can open the door to corrupted execution flow. Where exploit conditions are met, that can escalate from local access to root privileges on the host.
Why it’s considered local (and why that still matters)
This vulnerability is described as local, not remote. That means an attacker needs the ability to execute code on the target system (or otherwise obtain local access), and it also requires that SCTP is reachable on the victim.
Those constraints reduce exposure compared with flaws that can be triggered over the network from scratch. Still, if an attacker already has a foothold inside a system—such as via another vulnerability, misconfiguration, or a weak internal service—the SCTP surface can become the next step toward privilege escalation.
In the Tencent Zhuque Lab write-up, the researchers report successful root outcomes on kernel builds they tested for several distributions, including Debian 13, Ubuntu 24.04, Rocky Linux 9, and RHEL 9, as well as OpenCloudOS. They did not provide public exploit code at the time of reporting, and the public community had not reproduced the container escape claim.
Timeline: disclosure and patches were already available
The SCTP Phantom Linux bug traces back to Linux 2.6.25 in 2008, and it has been present in kernels released since then. That long presence matters: it suggests that many systems may still be running kernels vulnerable to the same underlying logic.
Good news: patches shipped in stable kernels released on August 3. The updates mentioned include:
- Stable kernel 7.1.6
- Stable kernel 6.18.42
- Stable kernel 6.12.101
- Stable kernel 6.6.148
The public disclosure came two days after assignment to the kernel CVE team. As of August 7, the reporting also indicated no entry for this flaw in CISA’s Known Exploited Vulnerabilities catalog. Even without confirmation of active exploitation in the wild, the safest approach is to treat the bug as urgent once it affects your kernel and your configuration.
How the fix changes behavior
Linux’s advisory indicates that the patch prevents the kernel from processing a delete targeted at the path currently being handled for that message. This breaks the chain that allowed the kernel to free a structure and then reuse it via a dangling reference.
Because the underlying logic error exists across many kernel generations, upgrading to a kernel version that includes the patch is key. Relying on only the upstream version number can be misleading, since some vendors backport security fixes without changing the upstream version label.
Therefore, verify through your distribution’s security tracker whether your installed kernel package is actually patched for CVE-2026-64564.
Container escape: what researchers reported, and what’s uncertain
Tencent Zhuque Lab’s testing goes beyond root escalation. They describe attempts to escape a container and reach the host system underneath.
However, it’s important to separate what is reported from what is confirmed by others. The write-up is based on their own experiments, it does not name the container runtime used in testing, and no independent public reproduction was mentioned in the source reporting.
Sysctl details and privileges
In their notes, an early exploit approach appeared to require enabling specific SCTP sysctls:
- net.sctp.addip_enable
- net.sctp.addip_noauth_enable
Those settings made CAP_NET_ADMIN look like a prerequisite in that early path. Later, the lab claims they found a route that avoids relying on those settings by enabling the features on a per-socket basis instead.
The escape test reportedly kept the default seccomp profile and did not grant the container extra capabilities such as CAP_NET_ADMIN or CAP_SYS_ADMIN. By their count, six out of eight attempts reached root on the host.
Exposure depends on more than just kernel version
The lab also notes that real-world exploitability can shift due to other security controls, including:
- Socket access restrictions
- Seccomp profile choices
- User-namespace policy
In addition, an openKylin advisory covering the same bug reportedly stopped short of claiming anything beyond potential kernel panic and denial of service. Finally, the severity rating itself appears unsettled—Tencent assigned a value of 8.5 under CVSS v4.0, while the NVD had not published a score or weakness classification as of August 7.
What you should do now
If your system uses SCTP or could receive SCTP traffic, the safest move is to patch quickly.
Update your kernel (and confirm backports)
Install the stable releases that include the fix (or your distribution’s backported equivalent). Then double-check your vendor’s advisory or tracker to ensure CVE-2026-64564 is addressed in your running kernel package.
Reduce the attack surface if SCTP isn’t needed
If your workloads don’t require SCTP, disabling the SCTP module can remove an important part of the potential attack surface. This guidance is especially relevant because the vulnerability requires SCTP reachable on the target.
Watch for related patches in the same component
The reporting also mentions a second dangling-transport use-after-free bug in the same code path, patched on August 6 after the August 3 stable releases shipped. That means not all stable updates are identical in coverage—another reason to verify what your actual kernel packages include.
Broader context: long-dormant bugs resurfacing
Tencent credits the discovery to Corvus AI, a multi-agent research pipeline it built for kernel work. The disclosure is presented as the latest example of a run of long-dormant kernel vulnerabilities surfaced with machine assistance this year.
That trend matters because it signals: even if a flaw is old, attackers may still find practical paths when systems align with the right conditions. So, treat kernel updates as ongoing operational hygiene—not a one-time event.
Conclusion
The SCTP Phantom Linux bug (CVE-2026-64564) is a long-standing use-after-free flaw in Linux SCTP networking. While it is local and needs SCTP reachable, researchers report that it can lead to root and may enable container escape under specific conditions. The good news is that patches were released on August 3, so updating your kernel promptly is the most effective protection.
Check your distribution’s security tracker, apply the patched kernel packages, and consider disabling SCTP if it isn’t required. That combination gives you the best chance of staying ahead of this risk.
Source: https://thehackernews.com/2026/08/18-year-old-linux-sctp-flaw-could-let.html
