Tencent's Zhuque Lab disclosed SCTPhantom on August 6, 2026, reporting a Linux kernel vulnerability that can let a local attacker gain root privileges and escape a container. Tracked as CVE-2026-64564, the flaw has a CVSS v4.0 score of 8.5 and dates back to 2008.

The bug is a use-after-free in the kernel's SCTP implementation. Exploitation depends on the attacker being able to reach the vulnerable SCTP code, so an affected kernel alone doesn't establish that every container can be exploited. Still, a host doesn't need to run an application that deliberately uses SCTP to be exposed. On many Linux distributions, an unprivileged process can trigger the protocol's kernel module to load by requesting an SCTP socket.

As of August 9, 2026, patches have been reported for active stable kernel series. For container operators, the immediate work is to identify affected hosts, check whether workloads can access SCTP, and install the appropriate kernel update.

How the SCTP bug works

SCTP, or Stream Control Transmission Protocol, is a transport-layer protocol designed in 2000 for telecom signaling. It supports multi-homing, which lets a connection use multiple IP addresses, along with multiple streams and explicit message boundaries. It appears in 5G core networks, some storage area networks, and certain streaming applications, but it isn't commonly used by general-purpose web servers.

The vulnerability sits in SCTP's Dynamic Address Reconfiguration processing, known as ASCONF. An SCTP association, the protocol's equivalent of a connection, uses ASCONF chunks to add or remove IP addresses.

The problem is a mismatch between validation and removal. The kernel validates a DEL-IP operation against the source address of the incoming packet. The removal then acts on a transport object chosen using a different address, the one in the ASCONF Address Parameter.

The reported trigger is an ASCONF sequence such as [Address L][DEL-IP L][DEL-IP 0.0.0.0], where the packet's source address differs from parameter L. That sequence causes the kernel to free transport L while the association still holds pointers to it. Its primary_path and active_path can then refer to freed memory.

That is the use-after-free: code continues to use an object after the memory holding it has been released. If an attacker can arrange for controlled data to occupy that memory, later accesses may give the attacker influence over kernel behavior.

From freed memory to host access

Tencent's researchers reported a full exploitation chain, rather than just a crash. They tested it on Linux 5.14, 6.6, 6.8, 6.12, and 7.2-rc2. The chain combines several steps:

  1. Keep the stale pointer usable. The freed transport remains referenced by an active association, giving the attacker a dangling pointer to work with.
  2. Reuse the memory and leak kernel addresses. TPACKET V1 socket ring allocation reclaims the freed 1024-byte slab allocation and exposes kernel direct-map addresses.
  3. Read kernel memory. A controlled transport->asoc pointer enables 4-byte kernel reads through the SCTP_STATUS getsockopt operation.
  4. Bypass address randomization. Reading the interrupt descriptor table, or IDT, entry for the division-error handler reveals the kernel slide. That is the offset used by kernel address space layout randomization, or KASLR, to make kernel addresses harder to predict.
  5. Gain privileges. A fake graph of kernel objects provides a path into commit_creds.
  6. Escape the container. A usermode-helper variant reaches host namespaces from an unprivileged container context.

The container escape is particularly relevant to Kubernetes, Docker, and other environments where workloads share a host kernel. Root privileges inside a container don't ordinarily mean root access to the host. A successful kernel exploit can cross that boundary, depending on the host configuration and the operations available to the container.

SCTP access matters more than intentional use

This is a local vulnerability. An attacker needs local execution and access to the relevant SCTP functionality. Checking only whether a service advertises SCTP support won't answer whether a host is exposed.

On many distributions, SCTP ships as a loadable kernel module. A call to socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP) can trigger autoload through modprobe, without the calling process directly requesting privileged module-loading access.

A module loaded for one service or container becomes part of the shared host kernel. Other containers may then be able to use it if their security policies permit the necessary socket operations. The fact that a particular workload doesn't use SCTP is therefore a weak basis for dismissing the risk.

A useful initial check is lsmod | grep sctp. It shows whether SCTP is currently listed among loaded modules. That check should be paired with a review of module-loading policy and container restrictions, since a module that isn't loaded now may still be loadable on demand.

Tencent credits an AI-assisted research system

Tencent attributes the discovery to Corvus AI, a multi-agent vulnerability research pipeline built for kernel work. The reported system coordinates agents that can develop crash findings into exploit chains, including automated heap grooming, controlled memory allocation sequences, and KASLR bypass techniques. Heap grooming means arranging allocations so that useful data is more likely to land in memory affected by a bug.

According to the reporting, Corvus AI found the flaw and built a working exploit chain within weeks, from initial discovery to a full exploit. Tencent also credits the system with finding multiple long-dormant kernel flaws in 2026.

The age of this bug shows that code can remain vulnerable through many years of development and deployment. It doesn't establish how thoroughly that particular code path was reviewed during those years. The more useful operational observation is the reported speed of the work: a difficult memory-safety flaw was developed into a practical chain within weeks.

AI-assisted research could shorten the time available to respond to similar discoveries. For shared-kernel infrastructure, that supports treating a demonstrated container escape as urgent rather than assuming that a complex exploit will remain confined to a research lab.

Patched kernels and temporary restrictions

Reported patched kernel versions are 6.6.148, 6.12.101, 6.18.42, and 7.1.6, with backports reported for all active stable kernel series. The mainline commit is 9b2854f86f0b.

The upstream fix adds a single-line guard in ASCONF processing. It rejects deletion when the selected transport matches the transport processing the request:

if (peer == asconf->transport)
    return SCTP_ERROR_REQ_REFUSED;

Debian 13 has reportedly issued an updated kernel package. Ubuntu and RHEL updates were expected in distribution channels by August 9, 2026, so their availability should be checked with the relevant distribution rather than assumed. Install the distribution's fixed package and make sure the host is running the updated kernel.

Where an immediate update isn't possible, the available mitigations focus on preventing access to SCTP:

  • Block module loading where SCTP isn't needed. Add install sctp /bin/false to /etc/modprobe.d/blacklist-sctp.conf, then regenerate the initramfs with update-initramfs -u or dracut -f, as appropriate for the distribution. This is intended to prevent the module from loading on the next boot. Writing the configuration doesn't remove a module already loaded into the running kernel.
  • Restrict SCTP socket creation in containers. A seccomp rule that blocks socket(2) calls using IPPROTO_SCTP can prevent that route to module autoload and SCTP access. The restriction needs to be present in the profiles applied to the affected workloads.
  • Audit each host type. Run lsmod | grep sctp across the fleet and identify which services need the protocol. Hosts with SCTP already loaded require attention to their current running state, not just a configuration change for a later boot.

Blocking SCTP isn't suitable for hosts whose services depend on it, including relevant telecom workloads. Those hosts need the fixed kernel without losing required protocol support. For hosts that don't need SCTP, restricting it reduces access to this code while a kernel update is being arranged.