I've been patching Linux kernels since before "container escape" was a threat category. Back when I was standing up bare-metal hosting infrastructure in the early 2000s, the scary bugs lived in TCP/IP, in NFS, in the memory allocator. You patched, you rebooted, you moved on. The vulnerabilities that never got found were the ones hiding in protocols nobody used heavily enough to audit carefully.
That's the story of SCTPhantom, a use-after-free in the Linux kernel's SCTP (Stream Control Transmission Protocol) implementation that has been sitting undetected since 2008. Researchers at Tencent's Zhuque Lab publicly disclosed it on August 6, 2026 as CVE-2026-64564, with a CVSS v4.0 score of 8.5. In the right conditions, it lets a local attacker escalate to root and — this is the part that should wake up every cloud operator — escape from a container to the host.
Let me walk through what happened, why it matters operationally, and what you need to do today.
Eighteen Years of Waiting
SCTP is a transport-layer protocol designed in 2000 for telecom signaling networks. It offers features TCP doesn't — multi-homing, multi-streaming, message framing — but it never broke through in general-purpose internet infrastructure. It lives in 5G core networks, some storage area networks, and certain streaming applications, but most web servers never enable it explicitly. On many Linux distributions, SCTP ships as a loadable kernel module that gets pulled in when first requested — no root required to load it.
That quiet residency in the kernel, rarely exercised, rarely audited, is exactly why a bug could sleep there for eighteen years.
The flaw lives in SCTP's Dynamic Address Reconfiguration (ASCONF) processing. When an SCTP association uses multiple IP addresses — the multi-homing feature — it sends ASCONF chunks to add or remove addresses. The kernel validates a DEL-IP operation by comparing it against the source address of the incoming packet. But the actual removal operates on a transport object selected by a different address — the one in the ASCONF Address Parameter.
Crafting an ASCONF sequence like [Address L][DEL-IP L][DEL-IP 0.0.0.0], where the packet source differs from parameter L, causes the kernel to free transport L while a stale pointer to it remains active in the association. The association's primary_path and active_path now point at freed memory. That's the classic use-after-free setup: the bug has survived eighteen years, and the door is open.
The Exploitation Chain
Tencent's researchers didn't stop at a crash. They built a full exploitation chain demonstrating privilege escalation to root and container escape, tested on Linux 5.14, 6.6, 6.8, 6.12, and 7.2-rc2. The chain is sophisticated:
- UAF survival: Retain the freed transport in an active association to create a controlled dangling pointer.
- Heap reuse and kernel address leak: Exploit TPACKET V1 socket ring allocation to reclaim the freed 1024-byte slab, leaking kernel direct-map addresses.
- Arbitrary kernel read: Use the controlled
transport->asocpointer to enable 4-byte kernel reads viaSCTP_STATUSgetsockopt. - KASLR bypass: Read the IDT entry for the division-error handler to recover the kernel slide.
- Privilege escalation: Construct a fake kernel object graph to chain into
commit_creds. - Container escape: A usermode-helper variant reaches host namespaces from an unprivileged container context.
That last step is what elevates this beyond an ordinary local privilege escalation. In a containerized environment — Kubernetes, Docker, any multi-tenant setup where containers share a host kernel — root inside a container is usually contained. SCTPhantom breaks that assumption. If SCTP is reachable from inside the container, the attacker is on the host.
Who Actually Uses SCTP in 2026?
This is the right operational question. The vulnerability requires local access and SCTP reachable on the target system. Let me be specific about what "SCTP reachable" means in practice.
On most Linux distributions, SCTP ships as a kernel module. A process doesn't need root to load it — calling socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP) will trigger autoload via modprobe. Once the module is in the kernel, any process that can open an SCTP socket can exercise the vulnerable code path.
In a container environment, if the SCTP module is loaded in the host kernel — whether because another container requested it, or because a system service uses it, or because it was manually loaded at any point — all containers sharing that kernel can reach it. You don't need to be running 5G software to be exposed. You just need to be on a host where someone, sometime, loaded the SCTP module.
The practical exposure landscape is broader than "we don't use SCTP." Check your hosts with lsmod | grep sctp. You may be surprised.
AI Found This Bug
I want to spend a moment on how this was discovered, because it connects directly to what I've been building and thinking about over the past year.
Tencent Zhuque Lab's discovery came through Corvus AI, a multi-agent vulnerability research pipeline built specifically for kernel work. Corvus AI isn't a single model scanning code — it's an orchestrated system of agents that can develop crash findings into full exploit chains, applying automated heap grooming strategies, controlled memory allocation sequences, and KASLR bypass techniques. This is the same multi-agent architecture I've been building for application-level code generation and security review, applied to the kernel at a depth that frankly would have taken a senior researcher weeks to work through manually.
The implications are significant. Eighteen years of human eyes — kernel developers, security researchers, distro maintainers, automated static analysis — looked at this code and missed this bug. Corvus AI found it and built a working exploit chain in a matter of weeks from initial discovery to full exploit. Tencent credits the system with surfacing multiple long-dormant kernel flaws this year.
If you're running infrastructure and you think your threat model only includes human attackers, you're behind. The same capability that found SCTPhantom is running against production systems — not just in security labs. The discovery-to-exploit timeline is compressing in ways that change how quickly you need to apply patches.
What You Need to Do Right Now
The good news: patches are out and have been backported to all active stable kernel series. The patched versions are 6.6.148, 6.12.101, 6.18.42, and 7.1.6. The upstream fix is a single-line guard in the ASCONF processing path that rejects deletion when the selected transport matches the processing transport:
if (peer == asconf->transport)
return SCTP_ERROR_REQ_REFUSED;The mainline commit is 9b2854f86f0b. Your distribution should already have or be preparing a kernel update — check your package manager and apply it. Debian 13 has already issued an updated kernel package; Ubuntu and RHEL updates should be in distribution channels now.
If patching immediately isn't possible — you're in a change freeze, waiting on a maintenance window, or have downstream dependencies — there are meaningful mitigations available today:
- Block the SCTP kernel module: Add
install sctp /bin/falseto/etc/modprobe.d/blacklist-sctp.confand regenerate your initramfs withupdate-initramfs -uordracut -f. This prevents the module from loading on the next boot. - Container seccomp hardening: The
socket(2)syscall withIPPROTO_SCTPis what triggers module autoload. Adding a seccomp rule to block SCTP socket creation in container profiles prevents exposure even if the host kernel is unpatched. - Audit loaded modules across your fleet:
lsmod | grep sctpon every host type. On hosts where SCTP is loaded and you cannot immediately patch, the blacklist approach gives you meaningful risk reduction.
The Broader Pattern Worth Watching
SCTPhantom is the third kernel vulnerability in four months to follow the same arc: quiet protocol implementation, dormant for years, surfaced by automated analysis, with a full exploit chain delivered alongside the CVE. The pattern isn't coincidence — it's what happens when purpose-built AI systems get directed at codebases that have never received that level of automated scrutiny.
For those of us running containerized, multi-tenant infrastructure, this changes the operating assumption. Container isolation rests on the kernel boundary holding. SCTPhantom demonstrates that the kernel boundary is a more dynamic target than it used to be — and the tools finding the gaps are getting faster.
Apply the patch. Block the module if you're waiting on a maintenance window. Audit which hosts have SCTP loaded. And take seriously that the threat model for infrastructure in 2026 includes AI-assisted exploitation research running at a pace that makes leisurely patch cycles a real risk.