SCTPhantom CVE-2026-64564: Patch This 18-Year Linux SCTP Root Exploit Now

An 18-year-old Linux kernel bug just became a working root exploit with a public proof-of-concept covering roughly 800 kernel builds. On August 4, 2026, the Linux kernel CVE team formally announced SCTPhantom CVE-2026-64564 — a use-after-free flaw in the kernel’s SCTP Dynamic Address Reconfiguration feature. Security researchers at TencentOS Security Team, using an AI-powered vulnerability research system called Corvus AI, turned this raw memory bug into a complete privilege-escalation chain that delivers root from an unprivileged local process and escapes containers to compromise the underlying host. The vulnerable code traces back to December 2007 — Linux 2.6.25 — making it nearly 18 years old before discovery. Patched kernels are now rolling out across major distributions. This post covers exactly what the flaw is, which systems are exposed, how to check if your kernel is vulnerable, and what to do right now.

What Is SCTPhantom CVE-2026-64564?

The vulnerability lives in the SCTP (Stream Control Transmission Protocol) Dynamic Address Reconfiguration feature, specifically in how the kernel handles ASCONF chunks — a mechanism defined in RFC 5061 that lets SCTP associations add, remove, or reconfigure network paths on the fly. Because ASCONF processing involves complex state management across multiple kernel objects, a use-after-free condition exists when a transport object is freed during a specific sequence of address configuration operations.

The Corvus AI system identified the raw memory bug, and TencentOS researchers then built a complete exploit chain around it. The exploit reclaims the freed transport using a packet socket ring buffer, leaking a kernel memory address in the process. That leak enables a repeatable four-byte kernel read, which the researchers used to defeat KASLR by inspecting the interrupt descriptor table. From there, a standard Return-Oriented Programming chain delivers root. The entire chain works from an unprivileged local process — no special capabilities, no user namespaces required.

According to CyberSecurityNews, the container escape vector makes SCTPhantom particularly dangerous for multi-tenant environments. Since SCTP kernel code is shared between the host and all containers, a compromised container can use this exploit to break out to the host kernel and then pivot to every other workload on the same machine.

Which Systems Are Affected?

Every Linux kernel that includes SCTP support and has CONFIG_IP_SCTP enabled is potentially vulnerable. Since SCTP has shipped by default or as a loadable module in virtually every distribution since Linux 2.6.25, the exposure is extremely broad. Here is the current patch status across major distributions as of August 10, 2026:

Check If Your System Is Exposed in 60 Seconds

Three conditions determine your exposure level. Run these checks on every server before doing anything else:

# CHECK 1: Is SCTP loaded or loadable?
lsmod | grep sctp
# Any output = SCTP is currently loaded

# Check if SCTP module is available even if not loaded
find /lib/modules/$(uname -r) -name 'sctp.ko*' 2>/dev/null
# Any output = SCTP can be loaded on demand

# CHECK 2: Is ASCONF/Dynamic Address Reconfig enabled in kernel config?
grep CONFIG_SCTP /boot/config-$(uname -r) 2>/dev/null
# CONFIG_SCTP=y or CONFIG_SCTP=m = affected

# CHECK 3: Current kernel version
uname -r
# Compare against your distro's patched version when advisory is published

# FULL AUDIT: Check if any service is using SCTP
ss -tnlp | grep sctp 2>/dev/null
grep -r 'sctp' /etc/sysctl* 2>/dev/null

If SCTP is loaded and your kernel has not yet received the patch, apply the no-reboot mitigation immediately. Since most Linux servers do not actually use SCTP for any production workload, blacklisting the module is clean and disruption-free in the vast majority of environments.

Apply the Kernel Patch

Patched kernels are rolling out now. Update and reboot as soon as your distribution publishes the fix. A kernel restart is required — there is no live-patch available yet for this CVE except via KernelCare on supported platforms.

Fedora 44 / 45 (already patched)

dnf upgrade --refresh -y
reboot
uname -r
rpm -q --changelog kernel | grep CVE-2026-64564 | head -3

Ubuntu 22.04 / 24.04 / 26.04

apt update && apt upgrade linux-image-generic -y
reboot
uname -r
# Check when patch lands:
# https://ubuntu.com/security/CVE-2026-64564

RHEL 9 / AlmaLinux 9 / Rocky 9

dnf clean metadata && dnf upgrade kernel -y
reboot
uname -r
rpm -q --changelog kernel | grep CVE-2026-64564 | head -3

Debian 12 / 13

apt update && apt full-upgrade -y
reboot
uname -r
# Track Debian advisory:
# https://security-tracker.debian.org/tracker/CVE-2026-64564

Immediate No-Reboot Mitigation: Disable SCTP

Unlike some recent kernel LPEs, SCTPhantom has a clean and disruption-free mitigation available on most production servers. Since SCTP is not used by the vast majority of Linux server workloads — it is a transport protocol mainly used in telecom and VoIP infrastructure — blacklisting the module removes the attack surface entirely without affecting anything else:

# Step 1: Confirm SCTP is not in active use
ss -tnlp | grep sctp
lsof 2>/dev/null | grep sctp
# If no output, proceed safely

# Step 2: Unload the SCTP module if currently loaded
rmmod sctp 2>/dev/null && echo 'sctp unloaded' || echo 'sctp not loaded or in use'

# Step 3: Blacklist SCTP to prevent future loads
echo 'blacklist sctp' > /etc/modprobe.d/blacklist-sctp.conf
echo 'install sctp /bin/false' >> /etc/modprobe.d/blacklist-sctp.conf

# Step 4: Verify the blacklist is active
cat /etc/modprobe.d/blacklist-sctp.conf

# Step 5: Confirm SCTP cannot load after blacklisting
modprobe sctp 2>&1
# Should return: modprobe: ERROR: could not insert 'sctp'

# Step 6: Make it permanent across reboots (update initramfs)
# Ubuntu / Debian:
update-initramfs -u
# RHEL / AlmaLinux:
dracut -f

If your environment does use SCTP — telecom signaling, certain VoIP platforms, or systems following the 3GPP standard — disabling it is not an option. In that case, restrict which processes can access SCTP sockets using a custom seccomp profile or an SELinux/AppArmor policy that limits socket creation to authorized processes only.

Container and Kubernetes Environments: Extra Steps Required

Because SCTPhantom enables container escape, every Kubernetes worker node and Docker host deserves immediate attention — even if the workloads themselves do not use SCTP. A single compromised container on a vulnerable host kernel can escape to the host and pivot to every other pod on the same node. Run these checks on every container host:

# Check worker node kernel versions in Kubernetes
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'

# Blacklist SCTP on all worker nodes (if not in use)
# Run on each node after draining:
kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
ssh root@NODE_NAME 'echo install sctp /bin/false > /etc/modprobe.d/blacklist-sctp.conf && dracut -f'
kubectl uncordon NODE_NAME

# Docker: check if any container uses SCTP
docker ps -q | xargs -I{} docker inspect {} \
  --format '{{.Name}}: {{range .HostConfig.PortBindings}}{{.}}{{end}}' 2>/dev/null | grep -i sctp

# Verify SCTP is blacklisted on each node
for NODE in $(kubectl get nodes -o name | cut -d/ -f2); do
  echo -n "$NODE: "
  ssh root@$NODE 'cat /etc/modprobe.d/blacklist-sctp.conf 2>/dev/null || echo NOT BLACKLISTED'
done

Verify the Patch After Rebooting

After rebooting into the patched kernel, confirm the fix is active and remove the temporary SCTP blacklist if your environment needs SCTP restored:

# Confirm patched kernel version
uname -r

# RHEL / AlmaLinux: confirm CVE is in changelog
rpm -q --changelog kernel | grep CVE-2026-64564

# Ubuntu: confirm from apt
apt-cache show linux-image-$(uname -r) 2>/dev/null | grep -i CVE-2026-64564

# If patch is confirmed, remove SCTP blacklist if SCTP is needed
rm /etc/modprobe.d/blacklist-sctp.conf
# RHEL: update initramfs
dracut -f
# Ubuntu/Debian:
update-initramfs -u

# Reload SCTP module and verify
modprobe sctp
lsmod | grep sctp

SCTPhantom in the 2026 Linux LPE Landscape

SCTPhantom is the latest entry in what has become an extraordinary year for Linux kernel privilege escalation disclosures. Copy Fail, Dirty Frag, CIFSwitch, ssh-keysign-pwn, CVE-2026-23111 nf_tables, GhostLock, Bad Epoll, OVSwrap, and now SCTPhantom — each targeting a different kernel subsystem, each found with AI-assisted analysis tools. What these vulnerabilities share is old, heavily used kernel machinery that had not been formally audited in years until automated tools started combing through it. SCTP Dynamic Address Reconfiguration code dates to December 2007. It sat unreviewed for nearly 18 years before Corvus AI flagged it.

The pattern matters for how sysadmins think about kernel updates in 2026. Because AI-assisted vulnerability discovery is accelerating the rate at which old code paths are being turned into working exploits, the gap between kernel patch availability and active exploitation is shrinking. Treating kernel updates as optional or deferring them indefinitely is no longer viable. Our Linux server hardening checklist covers standing configurations that reduce exposure across this entire class of vulnerability, including module blacklisting and disabling unprivileged user namespaces. If you have not yet patched GhostLock CVE-2026-43499 from July, a single kernel update this week closes both that and SCTPhantom simultaneously on most distributions.

Conclusion

The SCTPhantom CVE-2026-64564 Linux fix is rolling out now across all major distributions. Start by checking whether SCTP is loaded on your servers with lsmod | grep sctp. After that, blacklist the SCTP module immediately if your workloads do not use it — that takes 30 seconds and requires no reboot. Then schedule the kernel update and reboot as soon as your distribution publishes the patched version. For Kubernetes environments specifically, drain and patch each worker node individually and verify the SCTP blacklist is in place before uncordoning. After rebooting into the patched kernel, confirm the CVE entry appears in the changelog before removing the SCTP blacklist. An 18-year-old bug with a public 800-build exploit coverage does not stay theoretical for long. Patch today.