SCTPhantom (CVE-2026-64564): An 18-Year-Old Use-After-Free in the Linux Kernel's SCTP Stack — Root Claim Disputed

TL;DR — 90 seconds

Affected?

Practically every Linux kernel since 2.6.25 (2008) up to the fixed versions 7.1.6/6.18.42/6.12.101/6.6.148 (all released August 3, 2026) — bare-metal hosts, VMs, and especially container/Kubernetes/K3s nodes with the SCTP module loadable are affected.

Risk?

Use-after-free (CWE-416) in SCTP ASCONF handling: the kernel checks a delete request against the packet's source address, but then acts on a transport path selected using a different address found inside the message body — which can free a transport path the connection still references. Tencent (CVSS 8.5, CVSS v4.0) reports full root access including container escape in 6 of 8 test runs; that claim is not yet independently verified, and other sources have so far observed only kernel panic/DoS.

Immediate action?

Check your kernel version and update to 7.1.6/6.18.42/6.12.101/6.6.148 (or your distro's backport). Where SCTP isn't needed — true for most container/Kubernetes hosts — blacklist the sctp kernel module; that removes the attack surface entirely.

Recommendation?

Patch or mitigate regardless of the unresolved root/escape claim: the undisputed denial-of-service impact alone justifies prioritized action on multi-tenant and Kubernetes/K3s hosts.

Criticality?

high (hero badge) — CVSS 8.5, but requires a local attack vector, and the root/container-escape claim remains independently unconfirmed, so not “critical.”

What is the problem?

SCTP (Stream Control Transmission Protocol) is a transport protocol alongside TCP and UDP, used in telecom signaling (the SS7/Diameter world), some Kubernetes CNI and multipath scenarios, and generally anywhere multi-homing and ordered message delivery are needed. One of its features is dynamic address reconfiguration (ASCONF, RFC 5061): a running SCTP association can add or remove IP addresses during its lifetime without rebuilding the connection — convenient for multi-homing, but a complex state machine inside the kernel.

That's exactly where the bug lives: when the kernel processes an ASCONF delete request, it checks authorization against the source address of the incoming packet — but then picks the transport path to act on using a different address contained in the message body itself. A specifically crafted sequence can free a transport path this way while the association still holds a pointer to it — a classic use-after-free (CWE-416): the kernel subsequently operates on memory that's already been released and potentially reallocated.

The fact that a bug Tencent traces back to kernel 2.6.25 (2008) is only surfacing now has less to do with the age of the code than with how it was found: Tencent's Zhuque Lab says it discovered the flaw using an AI-assisted analysis tool called “Corvus AI” — a tool that apparently searches systematically for exactly this kind of mismatch between the check path and the execution path in complex kernel code that has grown over decades. That's notable because it suggests AI-assisted code analysis is starting to find bug classes that classic fuzzing and manual audits missed for 18 years.

Who is affected?

The table shows the four kernel branches where the fix shipped on August 3, 2026. Important: many distributions backport security fixes without bumping the visible kernel version number — simply comparing uname -r against the four version numbers above isn't sufficient. Check your distribution's security tracker or changelog instead.

Who's actually exposed? Per current reporting, exploitation requires local access to the target system, plus reachable or enabled SCTP — this is explicitly not a remote, unauthenticated internet bug. That makes SCTPhantom primarily relevant to: multi-tenant hosts where multiple customers or teams share the same kernel; Kubernetes and K3s nodes running untrusted or less-trusted workloads (shared clusters, platform offerings, PaaS); CI/CD runners that execute third-party code (dependencies, PR branches); and generally any system where an attacker already has an initial foothold — for example via a compromised application or a malicious container. Pure single-tenant systems running fully trusted code face the lowest risk, but given how cheap the mitigation is (blacklisting a kernel module), there's little reason to accept that risk there either.

Impact

Tencent's test result — full root access on the host in six of eight attempts, without CAP_NET_ADMIN, CAP_SYS_ADMIN, or a loosened seccomp profile, tested on Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9, and OpenCloudOS — would, if confirmed, be a full-fledged container-escape primitive: a single compromised container or pod could break isolation from the host and potentially compromise every other workload on the same node, meaning in Kubernetes/K3s clusters the blast radius extends well beyond one malicious pod.

That claim, however, is explicitly unconfirmed independently: as of disclosure, no verification by other security researchers or vendors was available, and other observers have so far reported only kernel panics or denial of service as the observed effect — not successful privilege escalation. It's plausible that the outcome varies depending on exact kernel configuration, memory allocator behavior, and hardening options (e.g. KASLR, slab hardening), which could explain why Tencent didn't succeed in all eight attempts.

Regardless of how the root/escape question resolves, the denial-of-service impact is undisputed: a use-after-free in the kernel's network stack can reliably trigger kernel panics or crashes — for production multi-tenant or cluster environments, that alone is a serious availability risk.

Mitigation / immediate steps

Operational decision block

• Act today if … your system runs an SCTP-capable kernel and hosts untrusted or less-trusted workloads — shared Kubernetes/K3s nodes, CI runners, PaaS offerings.
• Check with priority if … your running kernel version is below the fixed versions and you're not sure of your distro's backport status.
• Just monitor if … the sctp kernel module is already blacklisted fleet-wide or demonstrably not loaded, and your kernel is already at or above the fixed version.

Step 1 — Check whether SCTP is active at all

lsmod | grep sctp

No match only means the module isn't currently loaded — without blacklisting, it can still be loaded on demand at any time as soon as a process opens an SCTP socket.

Step 2 — Check your running kernel against the fixed versions

# running kernel version
uname -r
# target: 7.1.6, 6.18.42, 6.12.101, or 6.6.148 (or newer / your distro's equivalent backport)

# Debian/Ubuntu — installed kernel packages
dpkg -l 'linux-image-*' | grep ^ii
apt list --installed 'linux-image-*' 2>/dev/null
# check the changelog for the CVE reference
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i CVE-2026-64564

# RHEL/Rocky/AlmaLinux — installed kernel packages
rpm -q kernel
dnf list installed kernel
# check the changelog for the CVE reference
rpm -q --changelog kernel-$(uname -r) 2>/dev/null | grep -i CVE-2026-64564

Important: a plain version-number comparison isn't reliable because of distro backports — also check your distribution's security tracker.

Step 3 — Blacklist the sctp kernel module (where not needed)

# unload the active module (only if loaded and not in use)
modprobe -r sctp

# set blacklist and install directives so it also can't be
# loaded on demand
cat <<'EOF' > /etc/modprobe.d/blacklist-sctp.conf
blacklist sctp
install sctp /bin/false
EOF

# verify it's effective
lsmod | grep sctp
modprobe sctp; echo $?   # should fail (non-zero exit code)

Caution: don't blindly blacklist if a service actually needs SCTP (e.g. certain telecom/Diameter workloads or multipath scenarios) — check first whether an application you use depends on it.

Step 4 — Kubernetes/K3s: roll the kernel update safely across the node fleet

# check the kernel version per node
kubectl get nodes -o wide   # KERNEL-VERSION column

# cordon the node before maintenance (no new pods scheduled)
kubectl cordon <node>

# drain the node — evict running pods in a controlled way
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data --grace-period=60

# apply the kernel/distro patch on the node, then reboot

# uncordon the node once it's back up
kubectl uncordon <node>

--force is always a last resort — it also forcibly deletes unmanaged pods. On K3s the same kubectl commands apply against the K3s API (or k3s kubectl …); work node by node, never take your entire node pool's capacity offline at once.

Optional — seccomp as a compensating control

For workloads that provably don't need SCTP, you can additionally block creation of AF_SCTP sockets (address family 132 on Linux) via a seccomp profile — as a complementary layer on top of, not a replacement for, the container runtime's default seccomp profile:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [{ "index": 0, "value": 132, "op": "SCMP_CMP_EQ" }]
    }
  ]
}

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/block-af-sctp.json

Test a profile like this carefully before rolling it out — untested syscall filters can break workloads unexpectedly.

Detection / verification

Neither Tencent nor other sources have published public IOCs, log signatures, or a specific detection tool for CVE-2026-64564 so far — unlike bugs under active exploitation, there is (as of this post) no known exploit code and no documented attacks to search for specifically. The following checks are a starting point, not a complete forensic playbook.

Check whether SCTP is active

lsmod | grep sctp
cat /proc/net/sctp/assocs 2>/dev/null   # active SCTP associations, if any

Check kernel/crash logs for SCTP references

dmesg | grep -i sctp
journalctl -k | grep -i sctp
# look for use-after-free warnings (only relevant on KASAN/kernel debug builds,
# usually not enabled in production):
dmesg | grep -iE "use-after-free|KASAN"

Check kernel package versions across the fleet

# simple loop as a starting point — in practice use fleet/config management (Ansible, etc.)
for h in $(cat hosts.txt); do ssh "$h" 'uname -r'; done

General runtime indicators

Not specific to SCTPhantom, but worth monitoring regardless: unexpected root processes originating from a container namespace, unusual kernel panics/crashes on nodes with SCTP enabled, and container processes with host-namespace access outside expected patterns.

Operator recommendation

Mid-market

Start by checking with lsmod | grep sctp whether SCTP is even active on your servers and Kubernetes/K3s nodes — in most cases the module is either not loaded or not actually needed. Blacklist it wherever it's not needed; that takes a few minutes per host and makes the kernel patch itself less urgent (though not unnecessary — still schedule it for your next maintenance window).

Enterprise

Inventory kernel versions across your entire fleet, especially on shared Kubernetes/K3s nodes, CI runners, and multi-tenant platforms — that's exactly where the (disputed) root claim matters most, since that's where an attacker realistically already has local access via a compromised workload. Roll out sctp blacklisting as standard node hardening wherever SCTP isn't part of your operating model, and treat the kernel patch as a regular, prioritized patch window — regardless of whether the container-escape claim is ever confirmed, since the denial-of-service impact alone justifies prioritization. For environments with genuine SCTP requirements (e.g. telecom signaling), blacklisting isn't an option — there, the kernel patch matters even more.

Decision block

• Patch immediately: update the kernel to 7.1.6/6.18.42/6.12.101/6.6.148 or the distro-specific fix, especially on multi-tenant and Kubernetes/K3s nodes.
• Compensate if delayed: blacklist the sctp kernel module where it's not needed; additionally apply a seccomp profile blocking AF_SCTP socket creation for workloads without SCTP requirements.
• Monitor: track your distro's tracker and the NVD entry for a score/CWE assignment, and watch for independent confirmation (or refutation) of the root/container-escape claim.

Conclusion

In its undisputed facts, CVE-2026-64564 aka SCTPhantom is a solid, patchable kernel bug: an 18-year-old use-after-free in SCTP's ASCONF handling, with four clearly named fixed versions since August 3, 2026, and a trivial, cheap compensating control for anyone who doesn't need SCTP — blacklist the sctp kernel module. What remains unclear and explicitly unconfirmed is Tencent's claim that the flaw allows full root access with container escape in six of eight cases; other observers have so far seen only denial of service. For operators, that uncertainty changes little about the recommended action: the DoS impact alone justifies prioritized patching on multi-tenant and Kubernetes/K3s nodes, and blacklisting costs practically nothing. Patch or mitigate regardless of how the dispute over the root claim resolves.

Sources

• The Hacker News — 18-Year-Old Linux SCTP Flaw Could Let Attackers Gain Root Access (Aug 7, 2026)
• Tenable — CIS Debian Linux 12 Benchmark: 3.2.4 Ensure sctp kernel module is not available
• Red Hat Customer Portal — How do I prevent a kernel module from loading automatically?
• Plural — The kubectl drain node Command: A Complete Guide