- The Mess: A Linux kernel use-after-free in SCTP, tracked as CVE-2026-64564 and dubbed SCTPhantom, has been sitting in the kernel since Linux 2.6.25. Tencent researchers demonstrated local privilege escalation to root and, under tested conditions, a container-to-host escape.
Eighteen years.
That’s how long the bug survived.
The problem lives in SCTP Dynamic Address Reconfiguration, specifically the handling of ASCONF messages and DEL-IP operations.
The kernel can end up freeing an SCTP transport object and then continuing to use a stale pointer to that object.
Classic use-after-free.
But this one doesn’t stop at a kernel crash.
Tencent’s researchers developed the bug into a working privilege-escalation chain. They demonstrated root access on multiple Linux distributions, including Debian 13, Ubuntu 24.04 and Rocky Linux/RHEL 9 configurations where SCTP was available.
Then they went one step further.
Container escape.
The researchers reported that their exploit could start inside a container and reach root-level operations on the underlying host. Their tested container scenario retained the default seccomp profile and did not grant CAP_NET_ADMIN or CAP_SYS_ADMIN; six of eight attempts reportedly reached host root.
That’s the part administrators should care about.
Containers are supposed to provide isolation.
SCTPhantom demonstrates how a kernel memory-management bug can turn that isolation into something considerably less reassuring.
- The Damage: A local attacker able to reach the vulnerable SCTP code path can potentially escalate to kernel-level root, while certain container configurations may allow the attacker to escape the container and compromise the underlying host.
There is an important limitation.
This is not a simple remote RCE against every Linux server on the internet.
The attacker needs local execution and the vulnerable SCTP functionality needs to be reachable. That significantly reduces the attack surface.
But container environments change the equation.
An attacker may first compromise an application running inside a container. If that container can reach the vulnerable kernel path, the attacker potentially gets a completely different objective:
container → kernel → host
And the kernel is shared.
That means patching the application inside the container isn’t enough if the underlying host kernel remains vulnerable.
The bug was introduced in Linux 2.6.25 and has therefore existed across an enormous number of kernel generations. The upstream kernel team fixed it in 6.6.148, 6.12.101, 6.18.42 and 7.1.6, with the mainline fix landing in the 7.2 release candidate series.
Vendor kernels may backport the fix while retaining an older-looking kernel version, so administrators should check their distribution’s security advisory rather than judging vulnerability solely by the base kernel number.
Red Hat provides an interesting example.
On RHEL 8, 9 and 10, the SCTP kernel module is disabled by default, so Red Hat rates the impact as Moderate for those releases. Red Hat also recommends preventing the module from loading as a mitigation where SCTP is not required.
That is a useful reminder:
Not every Linux machine is equally exposed.
- The Fix: Patch the Linux kernel using your distribution’s security updates; if SCTP is not required, disable or prevent loading of the
sctpmodule until the host is patched.
For servers running containers, Kubernetes workloads or other multi-tenant environments, this deserves extra attention.
Check whether SCTP is actually required.
Check whether the module is loaded.
Check the kernel security status.
And don’t blindly cherry-pick the individual upstream commit unless you absolutely know what you’re doing. The Linux kernel CVE team explicitly recommends updating to the latest stable kernel rather than treating individual commits as a supported replacement for a proper kernel update.
If you were running an exposed vulnerable kernel before patching, investigate as well.
A reboot after updating fixes the kernel.
It doesn’t prove nobody exploited the old one.
Bugstoday Opinion
This is exactly the kind of Linux vulnerability that gets our attention.
Not because SCTP is sitting on every desktop.
It isn’t.
Not because every Docker container is suddenly compromised.
It isn’t.
It’s because an 18-year-old kernel bug was turned into a practical root escalation and container escape.
That’s a much more interesting story.
Container security ultimately depends on the kernel underneath the container. If the kernel has a memory-corruption bug that crosses that boundary, your beautifully configured container isolation doesn’t matter nearly as much as you hoped.
And the age of this bug is the uncomfortable part.
Linux 2.6.25.
Different hardware. Different distributions. Different threat models.
Same bug.
Bugstoday verdict: if your Linux hosts use SCTP, patch the kernel. If they don’t, disable SCTP. And if you’re relying on containers to protect a vulnerable kernel, you’re trusting the wrong layer.
