A trapdoor in a hallway nobody walks down — unless your containers left that hallway unlocked
CVE-2026-64564, dubbed SCTPhantom, is a use-after-free in the Linux kernel's SCTP Dynamic Address Reconfiguration path (net/sctp/sm_make_chunk.c). When processing an ASCONF chunk containing a DEL-IP parameter, the kernel frees the transport structure the chunk arrived on while a dangling pointer to it persists. A second operation dereferences the freed pointer, giving an attacker controlled kernel memory corruption. The vulnerable code was introduced in Linux 2.6.25 (December 2007) — eighteen years of exposure. Affected upstream versions span everything from 2.6.25 through 7.2-rc2. Fixes landed in stable branches 6.6.148, 6.12.101, 6.18.42, and 7.1.6. The public PoC from ethanolgolf/CVE-2026-64564 on GitHub achieves reliable local privilege escalation on Debian 13 (kernel 6.12.95) and demonstrated container-to-host escape in 6 of 8 attempts against default Docker seccomp profiles.
NVD's 9.8 CRITICAL with AV:N is factually wrong. The attack requires local code execution — either an unprivileged shell on the host or a process inside a container sharing the host kernel. Red Hat correctly scores it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8, and classifies RHEL impact as *Moderate* because RHEL 8/9/10 ship with the SCTP module blacklisted from unprivileged autoload. SUSE and CVSS v4.0 both rate it 8.5 HIGH. The real severity hinges on one question: *can an unprivileged process on your host open an SCTP socket?* On Debian/Ubuntu defaults, yes — the kernel autoloads sctp.ko on demand. On RHEL/Rocky with kernel-modules-extra not installed, no. The container-escape angle is genuine and the reason this stays HIGH rather than MEDIUM: default Docker grants CAP_NET_RAW, default seccomp allows the required syscalls, and the exploit needs nothing else to break out to host root.
5 steps from start to impact.
Local code execution
AV:N vector is incorrect. Red Hat, SUSE, and the original oss-security disclosure all classify this as local.- Unprivileged user shell OR container process on the target host
- Requires prior initial access — phishing, stolen credentials, or exploiting a separate RCE to land on the box
- Cloud workloads with ephemeral containers reduce dwell time
SCTP module availability
AF_INET / SOCK_STREAM / IPPROTO_SCTP socket, which triggers kernel autoload of sctp.ko if not already loaded. On Debian/Ubuntu, this succeeds for unprivileged users by default. On RHEL 8/9/10, the module is in kernel-modules-extra (often not installed) and is blacklisted from unprivileged autoload via /etc/modprobe.d/. CIS Level 2 benchmarks also recommend install sctp /bin/true.- SCTP kernel module loaded OR autoloadable by unprivileged users
- RHEL/Rocky/Alma 8/9/10 blacklist SCTP autoload by default
- CIS L2 hardened hosts already block it
- Hosts without
kernel-modules-extracannot load the module at all
auditd rules on init_module/finit_module syscalls; lsmod baseline drift detectionTrigger UAF via crafted ASCONF DEL-IP
asconf->transport while the pointer remains live. A subsequent wildcard DEL-IP operation dereferences the freed pointer. The PoC (ethanolgolf/CVE-2026-64564) automates this with a compiled C binary.- Ability to create SCTP sockets and craft raw ASCONF chunks
- CAP_NET_RAW capability (for packet-socket memory reclamation)
- Kubernetes pods with
securityContext.capabilities.drop: [NET_RAW]block the reclamation step - Hardened seccomp profiles (e.g.,
RuntimeDefaultwith SCTP socket restrictions) can blocksocket(IPPROTO_SCTP)
KASLR bypass + memory reclamation
CAP_NET_RAW). The exploit inspects the Interrupt Descriptor Table (IDT) to leak kernel base addresses, defeating KASLR. This step is reliable — the PoC reports consistent KASLR bypass across tested kernels 5.14 through 7.2-rc2.- CAP_NET_RAW (Docker default, many K8s pods)
- Kernel compiled with standard IDT layout (virtually all production kernels)
- Dropping CAP_NET_RAW from container capabilities breaks this step entirely
- gVisor/Kata Containers interpose the kernel — the host kernel is not directly reachable
Root escalation / container escape
modprobe_path or triggers a usermode_helper execution in the host's initial namespace, escaping the container's mount/PID/net namespaces. The result is a root shell on the host. Tencent Zhuque Lab demonstrated 6/8 success rate against default Docker containers. From host root, the attacker can access kubelet credentials, all pod secrets, and pivot across the cluster.- Successful KASLR bypass from step 4
- Host kernel shares namespace with container (standard Linux containers)
- VMs and microVMs (Kata, Firecracker) isolate the kernel — no escape to host
- Hosts with kernel lockdown mode restrict usermode_helper abuse
kubectl audit for node-level privilege use/etc/modprobe.d/disable-sctp.conf with install sctp /bin/false and blacklist sctp, regenerate initramfs (dracut -f or update-initramfs -u), then rmmod sctp if currently loaded. This completely eliminates the attack surface — the UAF cannot be triggered if the SCTP stack is not in kernel memory. Per the noisgate mitigation SLA for HIGH, deploy within 30 days. If you have no SCTP workloads (most enterprises), do this immediately.securityContext.capabilities.drop: ["NET_RAW"] on all pod specs, or enforce via OPA/Gatekeeper/Kyverno policy. In Docker, use --cap-drop=NET_RAW. This blocks the memory-reclamation and KASLR-bypass steps of the exploit chain, preventing container escape. LPE on the host is still theoretically possible but significantly harder without packet sockets. Deploy within 30 days (noisgate mitigation SLA for HIGH).- Network firewalls / IDS — the attack is entirely local; no network traffic crosses a perimeter or segment boundary. Blocking SCTP at the firewall does not help because the exploit creates local-only SCTP associations that never leave the host.
- SELinux targeted policy (default) — unconfined processes (which includes most container runtimes and user shells) are not restricted from creating SCTP sockets. Only a custom SELinux policy explicitly denying
sctp_socketwould help, and almost nobody writes those. - AppArmor default profiles — standard AppArmor profiles do not restrict socket types by protocol number. The SCTP socket creation passes AppArmor checks on stock Ubuntu/Debian.
- Kernel ASLR alone — the PoC includes a reliable KASLR bypass via IDT inspection. KASLR does not meaningfully impede this exploit.
The supporting signals.
| In-the-wild exploitation | No confirmed in-the-wild exploitation. Not listed on CISA KEV. No GreyNoise or Shadowserver tags observed as of 2026-10-07. The oss-security disclosure thread from Tencent Zhuque Lab (2026-08-06) is the primary public source. |
|---|---|
| Proof-of-concept | Public, weaponized LPE + container escape. GitHub repo ethanolgolf/CVE-2026-64564 contains compiled C exploit targeting Debian 13 kernel 6.12.95. Tencent Zhuque Lab (Fourie Zhang) demonstrated 6/8 container escape success rate. Listed on KitPloit/Sploitus. Aggregator repos (asvorg/CVE-2026-PoCs, SecureWithUmer/CVE-2026-PoCs) also reference it. |
| EPSS | 0.01411 (1.4%) — low exploitation probability, consistent with local-only attack requiring pre-existing access. Well below the 90th-percentile threshold. |
| KEV status | Not listed. No CISA KEV entry as of 2026-10-07. |
| CVSS vector analysis | NVD: 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — AV:N is incorrect; attack is local. Red Hat: 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — accurate. CVSS v4.0: 8.5 (High). The NVD score should not be used for prioritization. |
| Affected versions | Linux kernel 2.6.25 (Dec 2007) through 7.2-rc2. Vulnerable code in net/sctp/sm_make_chunk.c, introduced in the SCTP Dynamic Address Reconfiguration implementation. PoC validated across kernels 5.14–7.2-rc2. |
| Fixed versions | Upstream stable: 6.6.148, 6.12.101, 6.18.42, 7.1.6, 7.2-rc5. Commit 9b2854f86f0b. SUSE: live patches for SLE 15 SP4/SP5/SP6 (kernel 5.14.21-150500.55.121+). Debian: included in October 2026 kernel security update (1,313-CVE batch). RHEL: RHSA-2026:70482 (check yum updateinfo). |
| Exposure / scanning data | SCTP is a niche protocol — primarily used in telecom (SS7/Diameter), some HA clusters, and WebRTC data channels. Shodan queries for SCTP services return a tiny fraction compared to TCP/UDP. Most enterprise Linux hosts do not have sctp.ko loaded. RHEL/Rocky default installs blacklist unprivileged autoload. |
| Disclosure timeline | Discovered by Tencent Zhuque Lab (Fourie Zhang) using their Corvus AI vulnerability research system. Upstream fix: 2026-08-03. CVE published: 2026-08-04. oss-security disclosure: 2026-08-06. Public PoC appeared within days. |
| Reporter | Fourie Zhang, Tencent Zhuque Lab / TencentOS Security Team. Found via automated kernel fuzzing (Corvus AI). |
Sources.
- NVD — CVE-2026-64564
- Red Hat — CVE-2026-64564 (CVSS 7.8, AV:L)
- oss-security — Original disclosure (Fourie Zhang, Tencent Zhuque Lab)
- CyberSecurityNews — 18-Year-Old Linux SCTP Flaw
- LinuxSecurity — Container Escape Analysis
- MSBiro — SCTPhantom Threat Modeling
- CIQ — Rocky Linux Mitigation Guide
- ethanolgolf — Public LPE PoC (GitHub)
Why this verdict
- NVD attack-vector error: NVD assigned
AV:N(network) but the attack is strictly local — the attacker must already have code execution on the host or inside a container. Red Hat, SUSE, and the original researchers all classify itAV:L. This single correction drops the base from 9.8 to 7.8. - SCTP-not-loaded friction: On RHEL/Rocky/Alma 8/9/10 (the dominant enterprise Linux family), the SCTP module is in
kernel-modules-extraand blacklisted from unprivileged autoload. A sysadmin must explicitly install and load it. CIS L2 benchmarks also disable SCTP. This narrows the reachable population substantially — estimated <20% of enterprise Linux hosts have SCTP loadable by unprivileged users. - Prior-access requirement: The attacker is already inside — this is a post-initial-access escalation tool. It compounds with whatever chain got the attacker local access, but it is not independently exploitable from the internet. EPSS at 1.4% reflects this.
- Role multiplier: Container hosts (Docker/Kubernetes nodes) — chain succeeds on Debian/Ubuntu-based container hosts with default Docker capabilities (
CAP_NET_RAWgranted). Blast radius is host root → kubelet credentials → cluster-wide pivot. Kubernetes worker nodes are a canonical high-value role. This outcome (fleet-scale compromise) with >1% of the Linux installed base running vulnerable container hosts sets the verdict floor at HIGH. - Role multiplier: Telco signaling servers — SCTP is actively used in telecom infrastructure (Diameter, SIGTRAN). These are high-value targets where the module is loaded by design. Chain succeeds; blast radius is signaling-plane compromise. However, telco Linux hosts are <1% of the general enterprise installed base, so this alone does not set the floor.
- Role multiplier: Standard servers/workstations — SCTP rarely loaded, module often not even on disk. Chain fails at step 2. Risk is LOW for this deployment role.
- No in-the-wild exploitation and no KEV listing — despite a public PoC available since early August 2026, there are no confirmed campaigns. This tempers urgency but does not reduce the floor.
Why not higher?
The SCTP subsystem is not a canonical high-value-role component (it is not a hypervisor, identity provider, or backup agent — it is an optional transport protocol). Less than 20% of enterprise Linux hosts have SCTP loadable, and on the dominant RHEL family it is blacklisted. The attack requires prior local access. These factors prevent the verdict from reaching CRITICAL despite the container-escape chain. If SCTP were loaded by default on all distros, this would be CRITICAL.
Why not lower?
The container escape path is real, public, and reliable (75% success rate demonstrated). Default Docker and many Kubernetes configurations grant CAP_NET_RAW, making container hosts on Debian/Ubuntu kernels directly exploitable. Kubernetes worker nodes are a high-value role where host compromise leads to cluster-wide blast radius. The public weaponized PoC lowers the skill bar. These factors establish a firm HIGH floor that SCTP-off-by-default friction cannot pull below.
Crowdsourced verification payload.
Run this script on each target Linux host as root for full checks (unprivileged works for basic version check). Invoke with: chmod +x check_sctphantom.sh && sudo ./check_sctphantom.sh. Outputs VULNERABLE, PATCHED, MITIGATED, or UNKNOWN with exit codes 1, 0, 2, 3 respectively.
#!/bin/bash
# CVE-2026-64564 (SCTPhantom) — SCTP ASCONF DEL-IP UAF Checker
# Target: Linux hosts | Privileges: root recommended | Exit: 0=PATCHED 1=VULNERABLE 2=MITIGATED 3=UNKNOWN
set -uo pipefail
KERNEL="$(uname -r)"
echo "[*] Kernel: $KERNEL"
# Extract numeric version (handles distro suffixes like 5.15.0-123-generic)
KVER="$(echo "$KERNEL" | grep -oE '^[0-9]+\.[0-9]+\.[0-9]+')"
if [ -z "$KVER" ]; then
echo "UNKNOWN — could not parse kernel version."
exit 3
fi
MAJOR=$(echo "$KVER" | cut -d. -f1)
MINOR=$(echo "$KVER" | cut -d. -f2)
PATCH=$(echo "$KVER" | cut -d. -f3)
echo "[*] Parsed version: $MAJOR.$MINOR.$PATCH"
# --- Version check against upstream fix points ---
# Fixed in: 6.6.148, 6.12.101, 6.18.42, 7.1.6, 7.2-rc5+
# Vulnerable from: 2.6.25 onward
vuln=1
if [ "$MAJOR" -ge 8 ]; then
vuln=0
elif [ "$MAJOR" -eq 7 ]; then
if [ "$MINOR" -ge 2 ]; then
vuln=0 # 7.2-rc5+ contains fix
elif [ "$MINOR" -eq 1 ] && [ "$PATCH" -ge 6 ]; then
vuln=0 # 7.1.6
fi
elif [ "$MAJOR" -eq 6 ]; then
if [ "$MINOR" -gt 18 ]; then
vuln=0
elif [ "$MINOR" -eq 18 ] && [ "$PATCH" -ge 42 ]; then
vuln=0
elif [ "$MINOR" -gt 12 ] && [ "$MINOR" -lt 18 ]; then
vuln=1 # 6.13-6.17 — no backport branch listed, assume vulnerable
elif [ "$MINOR" -eq 12 ] && [ "$PATCH" -ge 101 ]; then
vuln=0
elif [ "$MINOR" -gt 6 ] && [ "$MINOR" -lt 12 ]; then
vuln=1
elif [ "$MINOR" -eq 6 ] && [ "$PATCH" -ge 148 ]; then
vuln=0
fi
elif [ "$MAJOR" -lt 2 ]; then
vuln=0
elif [ "$MAJOR" -eq 2 ] && [ "$MINOR" -lt 6 ]; then
vuln=0
elif [ "$MAJOR" -eq 2 ] && [ "$MINOR" -eq 6 ] && [ "$PATCH" -lt 25 ]; then
vuln=0
fi
if [ "$vuln" -eq 0 ]; then
echo "[+] Kernel version is at or above a fix level."
echo ""
echo "PATCHED"
exit 0
fi
echo "[!] Kernel version $KVER is in the vulnerable range."
echo " NOTE: Distro backport patches (RHSA/DSA/USN) may have fixed"
echo " this without changing the version string. Cross-check with"
echo " your package manager (rpm -q kernel / dpkg -l linux-image-*)."
# --- SCTP module status ---
sctp_loaded=0
sctp_blacklisted=0
sctp_on_disk=0
if lsmod 2>/dev/null | grep -qw '^sctp'; then
sctp_loaded=1
echo "[!] SCTP module is currently LOADED."
else
echo "[+] SCTP module is NOT currently loaded."
fi
if grep -rqsE '(blacklist sctp|install sctp /bin/(true|false))' /etc/modprobe.d/ 2>/dev/null; then
sctp_blacklisted=1
echo "[+] SCTP module is BLACKLISTED in /etc/modprobe.d/."
else
echo "[-] No SCTP blacklist found in /etc/modprobe.d/."
fi
if modinfo sctp &>/dev/null 2>&1; then
sctp_on_disk=1
fi
# --- Final verdict ---
echo ""
if [ "$sctp_loaded" -eq 1 ]; then
echo "VULNERABLE — kernel $KVER is unpatched and SCTP module is loaded."
exit 1
elif [ "$sctp_blacklisted" -eq 1 ]; then
echo "MITIGATED — kernel $KVER is unpatched but SCTP is blacklisted."
exit 2
elif [ "$sctp_on_disk" -eq 1 ]; then
echo "VULNERABLE — kernel $KVER is unpatched and SCTP module can be autoloaded."
exit 1
else
echo "MITIGATED — kernel $KVER is unpatched but SCTP module not found on disk."
exit 2
fi