Severity
High
Analysis Summary
Linux kernel vulnerability CVE-2026-64564, dubbed SCTPhantom, is a high-severity use-after-free flaw in the SCTP Dynamic Address Reconfiguration (ASCONF) functionality. The vulnerability originates from code introduced in Linux 2.6.25 in December 2007, making the underlying bug nearly 18 years old. It affects the handling of ASCONF chunks, defined by RFC 5061 to allow SCTP associations to dynamically add, remove, and reconfigure network paths. The flaw results from an identity mismatch in how the kernel processes address deletion: one validation step relies on the packet's source address, while a cached pointer uses the address parameter associated with the selected network path, or transport.
Attackers can exploit this mismatch by sending a carefully ordered sequence of ASCONF operations for example, selecting an address, deleting it, and then issuing a wildcard deletion. This can cause the kernel to free an SCTP transport while stale references to that transport remain in the association's active and primary path pointers. A subsequent socket operation can dereference the freed memory, triggering the use-after-free. Researchers, using the Corvus AI autonomous vulnerability-research system, developed this primitive into a complete local privilege-escalation exploit. The exploit reclaims the freed transport through a packet-socket ring buffer and obtains a kernel memory leak, enabling a repeatable four-byte kernel read that can defeat KASLR by examining the interrupt descriptor table.
The researchers then chained the vulnerability with another use-after-free involving attacker-controlled SCTP authentication key data to construct a fake kernel object graph. This ultimately triggers commit_creds, allowing an unprivileged local attacker to obtain root privileges without shellcode or a conventional ROP chain. The same research demonstrated a serious container escape scenario: by using per-socket SCTP options rather than system-wide sysctls, the exploit avoided requiring elevated capabilities and successfully escaped containers using default seccomp profiles in six of eight attempts. The attack ultimately triggered a usermode-helper process in the host's initial namespace, demonstrating that the vulnerability can cross container isolation boundaries and compromise the underlying host.
SCTPhantom was successfully validated on Ubuntu 24.04, Debian 13, Rocky Linux 9, and multiple Linux kernel builds ranging from 5.14 through a 7.2 release candidate, achieving root access in every tested environment. The vulnerability received a CVSS v4.0 score of (High) because of its relatively low exploitation complexity and significant confidentiality, integrity, and availability impact. The upstream fix, commit 9b2854f86f0b, prevents DEL-IP requests from targeting the transport still referenced by the current ASCONF chunk. Patches have been backported to stable kernels 6.6.148, 6.12.101, 6.18.42, and 7.1.6. The Linux kernel CVE team announced the vulnerability on August 4, 2026, after private disclosure beginning July 12. Organizations running SCTP-enabled Linux systems, especially multi-tenant and containerized environments, should prioritize upgrading to a fixed kernel version.
Impact
- Gain Access
Indicators of Compromise
CVE
- CVE-2026-64564
Remediation
- Upgrade the Linux kernel immediately to a patched version: 6.6.148, 6.12.101, 6.18.42, or 7.1.6, or a newer vendor-provided release.
- Apply vendor security updates for distributions such as Ubuntu, Debian, Rocky Linux, and other affected Linux distributions.
- Disable SCTP if not required by the environment to reduce the attack surface associated with ASCONF processing.
- Restrict unprivileged access to SCTP functionality where possible, particularly on shared and multi-tenant systems.
- Strengthen container isolation and avoid granting unnecessary SCTP-related capabilities or permissions to containers.
- Monitor for exploitation attempts, including unusual SCTP/ASCONF traffic, unexpected SCTP socket activity, and suspicious kernel crashes or privilege-escalation behavior.
- Prioritize container and host kernel patching, as successful exploitation can potentially escape a container and compromise the underlying host.
- Maintain defense-in-depth controls, including seccomp, least-privilege configurations, endpoint monitoring, and kernel hardening, while recognizing that these controls should not replace patching.
- Verify kernel versions across all systems, including cloud instances, container hosts, Kubernetes nodes, and legacy servers, to ensure vulnerable kernels are not still deployed.

