SURIQ
Before you triage another kernel CVE by its severity score, look at what the researchers who found this one actually did with it. They sat inside an ordinary container, running under Docker's default seccomp profile with no added capabilities, and walked out to root on the host machine. Six times out of eight. That result, not the 8.5 severity number, is the reason to care about SCTPhantom.
Tracked as CVE-2026-64564, the flaw is a use-after-free in the Linux kernel's SCTP (Stream Control Transmission Protocol) code, the part that handles reconfiguring a connection's network paths on the fly. Tencent's Zhuque Lab disclosed it on August 6, and the fix reached the stable and long-term kernel branches on August 3 (exact versions below). The bug has been present since Linux 2.6.25 shipped in 2007, so it has ridden along in effectively every production kernel for 18 years. There is no public exploit at the time of writing, and it is not in CISA's Known Exploited Vulnerabilities catalog. The window to patch calmly is open. Use it.
What actually breaks
SCTP lets a live connection add, remove, and reshuffle its network paths using a mechanism called ASCONF from RFC 5061. The bug is an identity mix-up in that logic. The kernel decides whether a path-removal request is allowed by checking one address, but the path it then operates on was selected from a second address buried elsewhere in the same message. An ordered reconfiguration sequence can delete a path and then reference it again through a wildcard, and the connection is left holding a pointer to memory that has already been freed. From that dangling reference the researchers built a controlled write and then root. This is the shape of the bug, not a recipe. The operational detail lives in the vendor writeup, and the part a defender needs is knowing which of your assumptions it quietly breaks.
"We don't use SCTP" is not the same as "we're not exposed"
This is the first place the wire coverage stops short. Almost nobody deliberately runs SCTP; it is a telecom and signaling protocol most server fleets never touch. That feels like safety. It is not. On most distributions SCTP ships as a loadable module, and the kernel pulls it in automatically the moment any local process opens an SCTP socket. An unprivileged user, or a process inside a container, can trigger that load without asking anyone. This is exactly why hardening benchmarks such as CIS have told operators for years to blacklist niche network modules they do not need, SCTP among them. Most teams skipped that step because those modules never seemed to matter. They matter now.
The sysctl you would reach for does not help
The instinct on reading "ASCONF" is to switch it off at the host level, set net.sctp.addip_enable and net.sctp.addip_noauth_enable to 0, and move on. The researchers left those sysctls at their defaults and the exploit still worked, because it turned the feature on through per-socket feature flags, namely SCTP_ASCONF_SUPPORTED together with SCTP_AUTH_SUPPORTED, rather than the system-wide switch. So the one-line mitigation that looks obvious buys you nothing here. That gap is the difference between a fleet that is patched and a fleet that only believes it is.
Your container is not the boundary you think it is
The 6-of-8 container escape is the finding that should move a threat model, not just a patch queue. It ran under the default seccomp profile that Docker and containerd apply out of the box, with only minimal capabilities. Default seccomp does not block creating an SCTP socket, so the profile most teams treat as the secure default did nothing to stop the path from container to host kernel. If you rely on unprivileged containers as an isolation boundary, the reminder here is blunt: the real boundary is the shared host kernel, and one reachable kernel bug collapses it. We made the same point when a rigged image could seize the host through Docker's MCP gateway, and when a kernel flaw let code climb out of a sandbox in GhostLock. Container escapes are kernel-surface problems, and you shrink them by shrinking the kernel surface a container can reach.
The bigger pattern: old code, new hunters
SCTPhantom was not found by a person reading source over a weekend. Tencent credits Corvus AI, a multi-agent pipeline that compiles kernels, reproduces crashes, reads sanitizer logs, and refines a proof of concept across stages on its own. That is the third strand of a story we keep returning to: dormant, rarely-audited kernel code from the 2000s, like the XFS local-root bug and the Open vSwitch flaw, is now being mined systematically by machines, the same way an AI system recently surfaced 14,090 bugs across open source. The takeaway is not that AI is scary. It is that the supply of ancient local-root and container-escape bugs sitting in code nobody has read in a decade is far larger than the patch cadence assumes, and it will keep arriving. Chasing each one on its own is a losing race. Reducing what a local process or a container can reach pays off across all of them at once.
The fix, and the two steps teams skip
- Patch the kernel. Upstream shipped the fix as 6.6.148 and 6.12.101 on the long-term branches, plus 6.18.42 and the 7.1.6 release on newer ones; apply your distribution's backport. Trust the vendor security update rather than the raw version number, since fixes are backported without changing it, then reboot to load the new kernel.
- Blacklist SCTP where you do not use it. If nothing on the host speaks SCTP, stop the module from loading at all with an
install sctp /bin/trueline in your modprobe config. That removes the attack surface instead of patching one instance of it, and it is worth doing for the other niche network modules too. - Fix the container profile, not only the host. Default seccomp did not stop this. Add SCTP socket creation to your seccomp denylist for workloads that never need it, and treat unprivileged containers as a layer over a patched kernel, never as the boundary itself.
- Watch for the load, not just the exploit. An SCTP module load on a host with no reason to speak SCTP is a cheap, high-signal thing to alert on. Auditd rules on kernel-module loading and on unexpected privilege transitions catch the whole category, not only this CVE.
None of this is urgent in the drop-everything sense, because there is no exploit in the wild yet. It is urgent in the quieter sense: the fix is easy today, and the exposure stays silent right up until someone weaponizes it. Patch, blacklist what you do not run, and stop trusting the default container profile to hold a boundary the kernel does not.