The disclosure of CVE-2026-64564, named SCTPhantom by Tencent Zhuque Lab, demonstrates how vulnerabilities can remain hidden for years inside mature operating-system networking code before being developed into powerful privilege-escalation attacks. The flaw affects Linux’s implementation of Stream Control Transmission Protocol Dynamic Address Reconfiguration and can create a use-after-free condition in the kernel when specially constructed SCTP address-configuration operations are processed in a particular sequence. Although the vulnerability is not remotely exploitable through the demonstrated attack and requires local access together with SCTP availability, researchers were able to turn the memory-corruption primitive into full root privileges and even escape from a container into the underlying Linux host. The vulnerable logic dates back to Linux 2.6.25 in 2008, meaning the underlying defect survived approximately 18 years of kernel development before being identified and corrected. 

SCTP is a transport-layer protocol designed for applications requiring features such as multistreaming and multihoming, allowing one association to maintain several possible network paths between endpoints. It is less visible to ordinary users than TCP or UDP but remains important in telecommunications, signaling systems, mobile-network infrastructure and some specialized enterprise applications. RFC 5061 added Dynamic Address Reconfiguration, commonly referred to through SCTP ASCONF functionality, allowing an endpoint to add, remove or change addresses associated with an established SCTP connection. That flexibility is useful when systems have several network interfaces or addresses, but it also creates complex kernel state because SCTP must continually maintain relationships between associations, peer addresses and internal transport objects.

SCTPhantom originates from an inconsistency in how Linux validates and later uses those SCTP transport identities. An incoming ASCONF message contains an Address Parameter identifying one peer transport and can then contain operations such as ADD-IP, DEL-IP or SET-PRIMARY. Linux processes these operations sequentially. Researchers found that the kernel validates one delete operation against the source address of the received packet while later processing relies on a transport selected from a separate address included inside the ASCONF message. By deliberately making those two addresses different, an attacker can cause Linux to approve deletion of a transport object that the remaining processing logic still expects to exist.

The critical sequence consists conceptually of selecting one transport, deleting that transport and then performing a wildcard delete. Because the validation and retained transport refer to different identities, the first operation can free the selected transport while the subsequent wildcard operation continues using the stale pointer. The SCTP association may consequently retain references such as its primary or active path pointing toward memory that has already been released. When userspace later requests information or causes additional SCTP processing, the kernel dereferences the stale transport object, producing the use-after-free condition from which exploitation begins.

Use-after-free vulnerabilities are especially serious inside the Linux kernel because freed memory can later be reallocated for an attacker-influenced object. If the attacker can reliably cause another allocation to occupy the same location, fields previously interpreted as one kernel structure may suddenly contain attacker-controlled data from another. The researchers developed SCTPhantom by carefully manipulating the Linux allocator so that the memory previously occupied by an SCTP transport could be reclaimed with structures whose contents they could influence. This transformed the original stale pointer into progressively stronger exploitation capabilities rather than merely causing a kernel crash.

The first major stage of the exploit uses packet-socket memory allocations to reclaim the released SCTP transport slot and disclose a kernel direct-map address. This provides an attacker with knowledge about where selected physical memory is mapped inside the kernel’s address space. Such disclosure is valuable because modern Linux kernels use Kernel Address Space Layout Randomization to make important kernel functions appear at unpredictable virtual addresses. Without defeating KASLR, constructing reliable kernel exploits becomes significantly more difficult because an attacker cannot easily know where useful code and objects reside.

Tencent’s researchers then converted the corrupted SCTP status path into a repeatable four-byte arbitrary kernel read. By controlling the stale transport’s pointer toward an SCTP association, they could cause the kernel to retrieve data from an attacker-selected address and return part of that value through normal SCTP socket status information. Repeating the operation allowed them to read selected kernel memory and eventually recover the KASLR slide by examining the Interrupt Descriptor Table mapping. Once the runtime layout of kernel code was known, addresses of useful kernel functions could be calculated reliably.

The final privilege-escalation chain uses a second vulnerable SCTP association and carefully constructed replacement objects to redirect legitimate kernel control flow toward `commit_creds()`, an internal Linux function responsible for applying process credentials. Rather than injecting conventional shellcode or constructing a large return-oriented programming chain, the exploit reuses existing kernel functions and attacker-controlled object relationships to cause the kernel to grant privileged credentials. Tencent verified successful exploitation by accessing resources such as `/etc/shadow` and creating files under `/root`, demonstrating genuine global root access rather than merely manipulating the process’s visible user identifier.

Researchers successfully tested the privilege-escalation chain across several Linux distributions and kernel families, including Debian 13, Ubuntu 24.04, Rocky Linux 9/RHEL 9 and OpenCloudOS-based systems. This breadth is important because it shows that the vulnerability is not limited to one unusual experimental kernel configuration. Enterprise distributions frequently maintain older kernel branches while backporting features and security corrections, which means a system displaying an older version number may still contain relevant SCTP code even though it differs substantially from current upstream Linux.

The container-escape demonstration makes SCTPhantom particularly significant for cloud and container environments. Containers share the host Linux kernel rather than running their own independent kernels, meaning a kernel vulnerability reachable from within a container can potentially bypass namespace, filesystem and process isolation. Tencent initially believed exploitation would require the container to possess `CAP_NET_ADMIN` because early proof-of-concept code depended on system-wide SCTP settings controlling dynamic address reconfiguration. Further development showed that the required SCTP features could instead be enabled on an individual socket through SCTP options and authenticated ASCONF messages, eliminating that capability requirement.

In Tencent’s retained container tests, the container used the default seccomp profile and was granted neither `CAP_NET_ADMIN` nor `CAP_SYS_ADMIN`, two capabilities commonly associated with dangerous container privileges. The exploit still succeeded in six of eight attempts, ultimately causing a user-mode helper to execute within the host’s initial namespaces and perform root-level filesystem operations outside the container. This is important because organizations sometimes assume that removing powerful Linux capabilities is enough to make potentially hostile containers safe. Capability restrictions remain extremely valuable, but they cannot fully protect against vulnerabilities inside kernel code that remains reachable through ordinary permitted system calls.

The container result should nevertheless be interpreted carefully. Tencent’s researchers performed the demonstration in their own environment, and at the time of disclosure the complete escape had not been independently reproduced publicly. The precise exposure of another container platform depends on its seccomp rules, Linux Security Module policies, namespace configuration, permitted socket operations and whether SCTP support is available to the workload. The absence of `CAP_NET_ADMIN` from the demonstrated chain therefore does not mean every Docker, Kubernetes or other container automatically provides an exploitable path.

The vulnerability is also local rather than a straightforward network-based remote attack. An attacker must already be capable of executing code on the affected Linux machine or inside a container sharing the vulnerable host kernel, and SCTP functionality must be reachable. This significantly reduces the immediate exposure compared with an unauthenticated remote-code-execution vulnerability in an internet-facing service. However, local privilege escalation is an extremely valuable stage in real attack chains because attackers commonly first obtain low-privileged execution through a web application, stolen account, malicious package or compromised container before searching for a kernel weakness that gives them control of the underlying system.

In cloud infrastructure, guest applications and containers should often be treated as potentially hostile by design. A hosting customer may legitimately possess complete control over the application code running inside a container while still being expected to remain isolated from the host. A vulnerability that converts ordinary container execution into host root therefore breaks a fundamental security boundary rather than merely increasing the privileges of an already trusted administrator.

Organizations should first determine whether SCTP is actually required on their Linux systems. Many enterprise servers never intentionally use the protocol, yet the SCTP kernel module may still be available for automatic loading when an application opens an SCTP socket. When the protocol is unnecessary, preventing the module from loading removes the vulnerable functionality from the accessible kernel attack surface and provides a useful temporary mitigation while patches are deployed. This principle extends beyond SCTP: unused kernel protocols, filesystems and device drivers should not remain available merely because they ship with the operating system.

Administrators should avoid assuming that closing SCTP ports at the network firewall completely eliminates the risk because the demonstrated attack is local. An attacker already running code on the machine may create SCTP sockets internally without receiving SCTP traffic from the public internet. Network filtering can reduce remote protocol exposure, but kernel-module restriction or deployment of the corrected kernel provides stronger protection against local exploitation.

The upstream correction changes the ASCONF deletion logic so that Linux refuses to delete the same transport retained for processing the current ASCONF chunk. By protecting the actual object that later operations will use, the fix removes the identity mismatch responsible for the dangling reference. The first corrected stable upstream releases are Linux 6.6.148, 6.12.101, 6.18.42 and 7.1.6, with the mainline correction included in the 7.2 development branch.

Enterprise administrators should not determine vulnerability status purely by running `uname -r` and comparing the result with those upstream version numbers. Red Hat, Ubuntu, Debian, SUSE and other distributions routinely backport individual security corrections into kernels whose main version numbers remain much older. A RHEL 9 kernel based on the 5.14 branch, for example, may receive the SCTPhantom correction without suddenly reporting itself as Linux 6.6 or 7.1. Organizations should therefore rely on distribution security advisories and package release information to determine whether the relevant patch has been incorporated.

Kernel updates also require attention to the running kernel rather than merely the packages installed on disk. Installing a fixed kernel package normally does not replace vulnerable code already loaded in memory. Unless a supported live-patching mechanism explicitly covers the SCTP fix, the system must reboot into the updated kernel before the vulnerability is removed. Vulnerability-management systems should distinguish between a corrected package being installed and the corrected kernel actually running.

Container and Kubernetes operators should prioritize host remediation because replacing a container image does nothing to repair a vulnerability in the shared host kernel. All containers running on an affected node depend on the same underlying kernel, regardless of whether the containers themselves use Ubuntu, Alpine, Debian or another userspace image. A Kubernetes environment may contain hundreds of apparently isolated workloads while a single vulnerable node kernel remains the security boundary protecting all of them.

Organizations should therefore identify which nodes expose SCTP functionality and which workloads can create SCTP sockets. Kubernetes deployments using telecommunications workloads deserve particular attention because SCTP support is deliberately used in some mobile-network and signaling architectures. In such environments, simply disabling SCTP may not be operationally possible, making rapid kernel patching substantially more important.

Container security policies should continue restricting capabilities, system calls and socket families even though the research shows that these controls cannot universally prevent SCTPhantom. Seccomp profiles can reduce access to kernel attack surfaces by preventing unnecessary system calls, while AppArmor and SELinux policies can constrain what compromised workloads can do before or after privilege escalation attempts. User namespaces can create additional separation, although their interaction with kernel vulnerabilities must be assessed individually.

Access to raw and packet sockets also influences exploitability because Tencent’s proof of concept uses packet-socket allocations as part of its memory-reclamation and address-disclosure strategy. Restricting these capabilities where applications do not require them can make the published exploitation technique more difficult. However, defenders should avoid treating removal of one proof-of-concept primitive as a permanent fix because skilled researchers may discover alternative heap-reclamation mechanisms.

Host monitoring may identify signs of attempted exploitation, but detection is considerably more difficult than simply patching the vulnerable code. The attack manipulates legitimate SCTP socket operations and kernel allocation behaviour rather than installing a recognizable payload before escalation. Unusual SCTP socket creation on systems that normally never use SCTP may provide a useful behavioral indicator, especially when accompanied by packet-socket activity and repeated SCTP status queries.

Security teams should establish whether SCTP activity is expected on each workload rather than creating one universal rule. On a telecom application server, large amounts of SCTP traffic may be completely ordinary. On an accounting server or CI runner, the creation of an SCTP association may deserve immediate investigation. Context provides far more value than simply flagging the protocol itself.

Kernel crashes and KASAN-style warnings involving SCTP transport structures may indicate failed exploitation or accidental triggering of the bug, although production kernels often do not run with the same diagnostic instrumentation used by researchers. Central collection of kernel logs remains important because a local attacker gaining root may subsequently clear records from the compromised machine. Remote logging increases the chance that early evidence survives.

If exploitation is suspected, defenders should treat the Linux host as fully compromised rather than merely restarting the affected application or container. Root-level kernel compromise can allow attackers to alter processes, credentials, files, network traffic and security controls throughout the machine. Every container sharing that host during the compromise period should be considered potentially exposed, and credentials or secrets accessible from the host may need to be rotated.

Rebuilding the host from a trusted image is generally safer than attempting selective cleanup after confirmed kernel-level compromise. The rebuilt system should boot directly into a corrected kernel, and workload images and configuration should be reviewed before restoration. Credentials should be replaced from a trusted environment only after attacker persistence has been removed, otherwise newly generated secrets may simply be stolen again.

The age of SCTPhantom is itself an important lesson. The vulnerable code has existed since 2008, surviving countless Linux releases, security reviews and deployments. Mature code should not automatically be considered secure merely because it has operated for many years without a publicly known exploit. Rarely exercised protocol paths, complex state machines and unusual combinations of operations can conceal vulnerabilities for extremely long periods because they receive less routine testing than common functionality.

SCTP is an especially good example of this problem because relatively few developers and organizations exercise every part of the protocol’s dynamic address-management logic. Code can be stable under ordinary workloads for years while still containing a lifetime-management error reachable only through an unusual sequence of technically valid operations. Attackers and security researchers increasingly use automated source analysis, fuzzing and AI-assisted reasoning to explore precisely these neglected paths.

Tencent credits the discovery and development process to Corvus AI, its multi-agent kernel vulnerability research system. According to the researchers, the platform helped analyse SCTP state transitions, generate test cases, reproduce crashes and progressively develop the vulnerability from an initial abnormal condition into a reliable privilege-escalation chain. Human researchers still made the critical decisions and validated the findings, but automation accelerated the repetitive work involved in exploring a large and complex kernel codebase.

The use of AI-assisted vulnerability research has implications beyond this one bug. Large mature projects such as the Linux kernel contain decades of code across networking protocols, filesystems, device drivers and compatibility layers. Many components were written long before current security expectations and may have received relatively little adversarial testing because they are rarely used. Automated agents capable of systematically reading code, generating hypotheses and testing them in virtual machines may uncover more dormant vulnerabilities that have survived conventional review.

Defenders should assume attackers can eventually gain access to similar capabilities. The existence of an obscure feature for 18 years is no longer strong evidence that nobody will examine it. Attack economics change when automated tools can explore rarely used kernel subsystems continuously rather than requiring expensive manual research from the beginning.

SCTPhantom therefore reinforces the value of attack-surface reduction. Linux systems routinely ship support for protocols and subsystems that a particular server will never need. Preventing unused modules from loading reduces the amount of kernel code reachable by local attackers and decreases the number of future vulnerabilities that matter to that system. Minimalism is not merely an aesthetic preference for administrators; it reduces the code an adversary can ask the kernel to execute.

The broader cybersecurity lesson from CVE-2026-64564 is that container isolation ultimately depends on the security of the shared host kernel. Containers provide strong operational separation, but they are not miniature virtual machines with independent kernels. When an attacker finds a vulnerability in a reachable kernel subsystem, namespace boundaries and removed capabilities may not be sufficient to preserve isolation.

Organizations running Linux should apply the corrected kernel packages supplied by their distributions, confirm that systems have rebooted into those kernels and disable SCTP entirely where the protocol serves no business purpose. Container operators should assess host kernels rather than container image versions, while environments intentionally relying on SCTP should prioritize remediation and review which workloads can access the protocol.

There is currently no public evidence that SCTPhantom is being exploited in real attacks, and no public exploit code had been released when the vulnerability was initially disclosed. That provides defenders with an opportunity to patch before the technique becomes easier to reproduce. The existence of a detailed technical write-up, however, means the window for comfortable delay should be considered limited.

An 18-year-old bug becoming a container escape and root exploit is a useful reminder that software age does not make a security assumption correct. Sometimes it merely means nobody had asked the right sequence of questions yet.

A use-after-free bug in Linux's SCTP networking code can be turned into full root on a host, and Tencent researchers say they used it to escape a container and reach the machine underneath. The flaw has existed since 2008. The fix already shipped: stable kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148, released August 3, close it. Anyone running an older kernel with SCTP reachable should update.

Source: 18-Year-Old Linux SCTP Flaw Could Let Local Users Gain Root and Escape Containers via The Hacker News — published 07 Aug 2026.