high

CVE

CVE-2026-64564

CWE

CWE-416

Affected Surface

  • Linux kernel SCTP implementations from the `2.6.25` introduction of the vulnerable sequence through the first fixed stable lines: `< 6.6.148`, `6.7.x < 6.12.101`, `6.13.x < 6.18.42`, `6.19.x < 7.1.6`, and mainline before `7.2-rc5`
  • Developer workstations, self-hosted CI runners, shared engineering hosts, and container platforms where untrusted local code can execute and the SCTP attack surface is present or loadable
  • Linux distributions publicly validated by the researchers, including Debian 13 (`6.12.95+deb13-amd64`), Ubuntu 24.04 (`6.8.0-134-generic`), and Rocky Linux 9 / RHEL 9-family targets with SCTP loaded
  • Container environments where the shared host kernel is vulnerable and workloads can reach the SCTP trigger path; the published tests retained the default seccomp profile and did not require `CAP_NET_ADMIN` or `CAP_SYS_ADMIN` for the container-escape variant

CVE-2026-64564, nicknamed SCTPhantom by its discoverers, is the most important Linux application-security story published in the last three days because it turns “already have local code execution” into host root and, in the published research chain, container-to-host escape. That matters directly to AppSec teams even though the bug is not in npm or PyPI: a malicious package, compromised build step, or workstation foothold often starts with an unprivileged shell. This kernel bug is what can turn that shell into control of the machine underneath.

The strongest public sources are the 6 August oss-security disclosure and Tencent Zhuque Lab’s deep technical write-up. Together they move this issue from “fresh CVE metadata” into “concrete, reproducible exploit chain” territory. The researchers did not stop at a crash. They showed a path from an SCTP transport lifetime bug to a direct-map leak, a kernel read primitive, a commit_creds() trigger, and a container escape on real distribution targets.

What is affected

The affected project is the Linux kernel, specifically SCTP Dynamic Address Reconfiguration handling in the SCTP stack. Machine-readable vulnerability feeds now reflect the same stable-line cutovers called out in the kernel announcement:

Upstream lineFirst fixed release
2.6.25 through 6.6.x6.6.148
6.7.x through 6.12.x6.12.101
6.13.x through 6.18.x6.18.42
6.19.x through 7.1.x7.1.6
mainline7.2-rc5

The public validation set matters because it shows this was not only exercised on a custom kernel:

  • Debian 13: 6.12.95+deb13-amd64
  • Ubuntu 24.04: 6.8.0-134-generic
  • Rocky Linux 9 / RHEL 9-family target: vendor 5.14 kernel with SCTP loaded

As always with Linux CVEs, vendor backports matter more than a naked uname -r string. But those fixed releases are still the right first triage boundary for AppSec teams managing Linux developer fleets, CI runners, and container hosts.

Root cause: the ASCONF chunk frees the transport it still plans to use

The bug sits in how Linux processes SCTP ASCONF chunks that carry both an Address Parameter and one or more DEL-IP operations. The vulnerable sequence is:

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

The important detail is that the packet source and the transport selected through the Address Parameter do not have to be the same identity. Public disclosure describes the failure mode this way:

  1. the kernel caches the transport chosen for the ASCONF chunk in asconf->transport
  2. a DEL-IP for address L passes the existing source-address guard
  3. sctp_assoc_rm_peer() removes and frees that same transport
  4. a later wildcard DEL-IP still reuses the now-dangling asconf->transport
  5. stale pointers end up living in primary_path and active_path

Tencent’s write-up reduces the bug to the mismatch between “the address we validated” and “the transport pointer we kept using.” The upstream fix is correspondingly small and precise:

peer = sctp_assoc_lookup_paddr(asoc, &addr);
if (!peer)
        return SCTP_ERROR_DNS_FAILED;

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

sctp_assoc_rm_peer(asoc, peer);

That new guard matters because it blocks the exact transport object the wildcard branch would later reuse. In other words, the patch is not generic cleanup. It closes the specific identity mismatch the exploit requires.

Why the exploit chain is serious

The most valuable part of the public research is that it does not stop at proving a kernel oops. The published chain is:

surviving SCTP transport UAF
-> reclaimed by pg_vec allocation
-> direct-map page disclosure
-> repeatable 4-byte kernel read
-> IDT-based KASLR recovery
-> second UAF reclaim with controlled SCTP auth-key data
-> data-oriented commit_creds()
-> global root
-> usermode-helper variant
-> container-to-host escape

Two exploit-engineering details make this especially relevant to defenders:

  1. The first use-after-free becomes an information leak, not just a crash. Tencent shows how a reclaimed pg_vec array in kmalloc-1024 can be reinterpreted by SCTP_STATUS, disclosing a kernel direct-map address for a page that is also mapped in attacker-controlled userspace.
  2. The final privilege jump does not require shellcode in kernel text. The published chain reuses existing kernel code and pivots into commit_creds() through a controlled object graph.

That is why the write-up should be taken seriously by AppSec teams. This is a practical second-stage privilege amplifier for Linux hosts that already let an attacker run code locally.

Container escape is part of the story, not a footnote

The container result is what pushes this beyond a normal local Linux root bug for many engineering organizations. The researchers state that the retained escape test:

  • kept the default seccomp profile,
  • did not grant CAP_NET_ADMIN,
  • did not grant CAP_SYS_ADMIN,
  • reached host root in six of eight attempts.

Their final escape path uses the same kernel compromise primitives and then pivots through call_usermodehelper_exec() so the host performs an operation in the initial namespaces:

container SCTP trigger
-> host-kernel UAF
-> direct-map disclosure + kernel read
-> controlled kernel object graph
-> call_usermodehelper_exec()
-> process runs in the host's initial namespaces
-> host-root side effect

For AppSec teams running self-hosted runners, internal build farms, or containerized developer sandboxes, that is the right mental model: a package compromise that “only” lands code in a container may still have a credible path to the host kernel.

Why this belongs in a software-supply-chain research library

Kernel bugs like CVE-2026-64564 are part of the software-supply-chain story whenever the first-stage foothold is delivered through software distribution:

  • a malicious npm package runs during install on a Linux workstation
  • a poisoned PyPI package lands on a self-hosted runner
  • a compromised GitHub Actions step reaches a build container
  • a vulnerable internal service yields unprivileged code execution on a shared engineering host

In each case, the kernel becomes the boundary that decides whether the blast radius stays local or becomes full-machine compromise. CVE-2026-64564 is important precisely because the public exploit chain shows how small the jump can be once local code execution already exists.

Detection and scoping

Start with the running kernel and whether SCTP is even present on the host:

uname -r
lsmod | rg '^sctp'
modinfo sctp 2>/dev/null

Then verify whether your vendor kernel has already backported the fix:

rpm -q --changelog kernel | rg 'CVE-2026-64564|sctp: don.t free the ASCONF'

apt changelog "linux-image-$(uname -r)" 2>/dev/null | \
  rg 'CVE-2026-64564|sctp: don.t free the ASCONF'

For container-heavy fleets, scope the systems where all of the following are true:

  1. workloads can execute less-trusted code locally
  2. the shared host kernel is on an affected line or backport status is unknown
  3. SCTP is available, loadable, or required by local workloads
  4. compromise of the host would materially widen access to secrets, registries, or source repositories

Because the public chain is kernel-local rather than process-local, endpoint telemetry that only watches application crashes is weak evidence. Treat package, CI, and workstation compromise investigations on vulnerable Linux hosts as potential kernel incidents too.

Remediation

Patch to a vendor kernel that includes the SCTP fix and reboot into it. Do not stop at package installation or an updated changelog entry; confirm the running kernel is remediated.

If SCTP is not needed, reducing or removing that attack surface is a sensible interim control while patching rolls out. But the practical response should still assume this is a real privilege-escalation path, not a theoretical parser bug:

  1. prioritize developer Linux endpoints and self-hosted CI runners, not only production servers
  2. verify vendor backport status instead of relying only on version strings
  3. treat post-package-compromise investigations on vulnerable Linux hosts as possible root compromises

The broad AppSec lesson is simple: when a supply-chain or CI incident gives an attacker local code execution on Linux, the next question should always be which kernel-level privilege amplifiers still exist. For the last three days, CVE-2026-64564 is the clearest example of why that question matters.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Get Demo

References