A newly disclosed Linux kernel vulnerability has security teams across the software industry paying close attention, not just because of what it can do, but because of how long it went unnoticed. The flaw, nicknamed SCTPhantom and officially tracked as CVE-2026-64564, allows a local attacker with no special privileges to escalate to full root access, and in some configurations, break out of a container entirely to compromise the host system underneath it.
The vulnerable code has existed in the Linux kernel since 2007 or 2008, meaning it sat undiscovered in one of the world’s most heavily reviewed pieces of open-source software for roughly 18 years before researchers finally found it.
Who Found It, and How
SCTPhantom was discovered by researchers at Tencent’s Zhuque Lab, who traced the flaw to code originally introduced in Linux kernel version 2.6.25. Notably, the researchers used an AI-assisted vulnerability research system called Corvus as part of their exploit-development workflow, an important detail that speaks to a broader trend: AI tools are making it increasingly practical for researchers to comb through decades of mature, previously “trusted” code at a scale that wasn’t realistic for human reviewers alone.
The vulnerability carries a CVSS severity score of 9.8 out of 10, reflecting just how serious the potential impact is once successfully exploited.
What SCTPhantom Actually Does
The bug lives in the Linux kernel’s implementation of SCTP (Stream Control Transmission Protocol), specifically in a feature called Dynamic Address Reconfiguration, which lets active network connections add, remove, or reconfigure network paths on the fly. Technically, it’s what’s known as a use-after-free vulnerability: the kernel fails to properly protect a cached network pointer when handling a specific type of delete request, creating an identity mismatch that attackers can exploit.
Here’s a simplified version of how the attack chain works:
- An attacker triggers the SCTP bug to free a kernel memory object while a dangling pointer still references it
- That stale pointer is reused to leak kernel memory addresses, which defeats KASLR (Kernel Address Space Layout Randomization), a core security protection designed to make memory locations unpredictable
- A second use-after-free is triggered using attacker-controlled data, allowing the construction of a fake kernel object
- That fake object is used to trigger a core kernel function that hands over root credentials to the attacker, all without shellcode or a traditional exploit chain
In container testing, using nothing more than a default security profile with no elevated container permissions granted, researchers successfully escaped from the container to the underlying host system in 6 out of 8 attempts.
Which Systems Are Affected
Because the vulnerable code has been present since 2007, it affects a very wide range of Linux distributions and kernel versions. Researchers specifically confirmed successful root access on:
- Debian 13 (Linux 6.12.95)
- Ubuntu 24.04 (Linux 6.8.0-134)
- Rocky Linux 9 / RHEL 9 (their respective vendor kernel builds)
Essentially, any Linux system with SCTP networking enabled and reachable is a potential target, which covers a substantial share of servers, cloud instances, and containerized infrastructure running today.
Important Context: It’s Not a Remote Attack (Yet)
It’s worth being precise about the actual risk level here, since headlines about kernel vulnerabilities can sometimes overstate real-world exposure. SCTPhantom requires local access to a system to be exploited, meaning an attacker needs some existing foothold, whether that’s a compromised low-privilege account, a malicious container tenant on shared infrastructure, or another initial access point, before this vulnerability can be used to escalate privileges.
As of early reporting, no public exploit code had surfaced, and the flaw had not yet appeared in CISA’s Known Exploited Vulnerabilities catalog, meaning there’s no confirmed evidence of active, in-the-wild exploitation at the time of disclosure. That said, security researchers have noted that some technical indicators suggest a network-based attack path may be possible under certain conditions, which is worth continued monitoring.
Real-world exposure also depends heavily on several environment-specific factors: whether SCTP is enabled at all, whether raw and packet sockets are accessible, the user namespace policy in place, the seccomp configuration, Linux capabilities granted, and any additional Linux Security Module policies layered on top.
The Fix Is Already Available
The good news: patches have already shipped. Updated stable kernel releases, including versions 7.1.6, 6.18.42, 6.12.101, and 6.6.148, released August 3, 2026, close the vulnerability. Anyone running an older kernel with SCTP reachable should prioritize updating as soon as possible.
For systems that don’t rely on SCTP functionality at all, an additional mitigation is available in the meantime: simply ensuring the SCTP kernel module isn’t loaded removes the attack surface entirely, regardless of patch status.
Why 18 Years Matters
The sheer age of SCTPhantom is arguably as significant as its technical severity. SCTP has long been considered a lower-priority, less-scrutinized corner of the Linux networking stack compared to more heavily used protocols, which likely contributed to the bug surviving unnoticed for so long. Code that has existed for nearly two decades without a reported issue tends to accumulate a kind of unearned trust among developers and security teams, the assumption that if something were seriously wrong, it would have surfaced by now.
SCTPhantom is a direct challenge to that assumption. It’s a reminder that “battle-tested” and “secure” aren’t the same thing, particularly for less commonly used features that see less real-world traffic and, therefore, less opportunity for accidental discovery.
What This Means for IT and Security Teams
A few practical takeaways for software teams and system administrators:
- Patch immediately if you’re running SCTP-enabled systems, especially in multi-tenant or containerized environments where the container escape risk applies.
- Audit whether you actually need SCTP enabled at all. Many organizations have it active by default without using it, and disabling unused kernel modules is a straightforward way to reduce attack surface.
- Don’t assume old, well-reviewed code is automatically safe. SCTPhantom is a clear reminder that even code that’s survived nearly two decades of open-source scrutiny can still hide serious flaws, particularly as AI-assisted research tools make deep code review dramatically more scalable.
- Expect more discoveries like this. As AI-powered vulnerability research tools like Corvus become more widely used across the security research community, the software industry should anticipate a wave of similar findings in other long-standing, previously “trusted” codebases.
The Bigger Trend Behind SCTPhantom
Beyond the specific technical details, SCTPhantom fits into a larger pattern reshaping the software security landscape in 2026: AI is changing not just how software gets built, but how it gets attacked and defended. The same AI research capabilities that let Tencent’s team surface an 18-year-old flaw are available, in various forms, to both defenders and attackers, which means the pace of vulnerability discovery across the entire software industry is likely to keep accelerating.
For more breaking software security news and the latest vulnerability disclosures affecting the tech industry, keep checking Tech News Reports for continuing coverage.
