CVE-2026-64564 SCTPhantom: Linux SCTP Use-After-Free Explained

CVE-2026-64564, also known as SCTPhantom, is a Linux kernel use-after-free vulnerability in the Stream Control Transmission Protocol implementation. The flaw sits inside SCTP Dynamic Address Reconfiguration, specifically the processing of ASCONF chunks used to add, remove, and reprioritize addresses associated with an SCTP connection.

What makes SCTPhantom notable is not simply that it can crash the kernel. Researchers at Tencent Zhuque Lab demonstrated a full exploitation chain capable of turning the memory-safety bug into local privilege escalation to root and, under tested container configurations, container-to-host escape. The vulnerable logic can be traced back to Linux 2.6.25, making the underlying bug roughly eighteen years old by the time it was publicly disclosed in August 2026. (Tencent Matrix)

The vulnerability is technically interesting for another reason: it is the result of a subtle state-management inconsistency rather than a straightforward buffer overflow. Linux validates one address during an SCTP DEL-IP operation while retaining a transport object selected through another address. A carefully ordered ASCONF message can therefore cause Linux to delete the very transport object that later ASCONF processing still assumes is alive. The result is a dangling kernel pointer and a deterministic use-after-free. (Debian Security Tracker)

For defenders, however, the headline “Linux SCTP vulnerability enables root” needs context. SCTPhantom is not equivalent to an unauthenticated Internet attacker universally obtaining root on every Linux server. Real exposure depends heavily on whether SCTP is available, whether the module can be loaded, the privileges available to the attacker, the Linux distribution’s configuration, and whether the kernel already contains the relevant backport. The researchers’ demonstrated exploit requires the ability to construct the necessary SCTP traffic; in a follow-up on the oss-security list they clarified that the exploit does no requiere CAP_NET_ADMIN, but does require CAP_NET_RAW. (Openwall)

That distinction becomes especially important for container security.

CVE-2026-64564 at a Glance

Artículo	Detalles
CVE	CVE-2026-64564
Nombre	SCTPhantom
Componente	Linux kernel SCTP
Clase de vulnerabilidad	Use-after-free / expired pointer dereference
Affected feature	SCTP Dynamic Address Reconfiguration
Relevant mechanism	ASCONF / DEL-IP
Demonstrated impact	Local privilege escalation to root
Container impact	Container-to-host escape demonstrated
Research CVSS v4	8.5 High
Upstream fix	9b2854f86f0b
Public disclosure	August 2026
Historical origin	Vulnerable sequence dates to Linux 2.6.25

Tencent’s disclosure describes the issue as a deterministic SCTP transport use-after-free and gives it a CVSS v4 base score of 8.5 with a local attack vector and low privileges required. Red Hat independently currently scores its products at CVSS 3.1 7.8 with AV:L/AC:L/PR:L/UI:N, while other CVE data currently exposed through Ubuntu reflects a network-vector 9.8 score. These differences are an important reminder that CVSS records and vendor-specific product risk assessments are not always interchangeable. (Openwall)

What Is SCTP?

To understand CVE-2026-64564, it helps to understand why SCTP behaves differently from TCP.

SCTP, or Stream Control Transmission Protocol, is a message-oriented transport protocol. One of its important features is multihoming: a single SCTP association can have several network paths between endpoints rather than being permanently associated with one source-address/destination-address pair. Linux consequently needs to maintain multiple peer transports as part of one SCTP association. (Tencent Matrix)

At a simplified level, the Linux kernel maintains something resembling:

SCTP Association
    |
    +-- transport A
    |
    +-- transport B
    |
    +-- transport C

primary_path ------> transport B
active_path  ------> transport B

Each path is represented by a kernel struct sctp_transport, while the wider relationship is represented through an SCTP association. Pointers such as primary_path y active_path are expected to reference valid transports belonging to that association. (Tencent Matrix)

This becomes security-sensitive because transport objects have lifetimes. If a transport is removed from the association and eventually freed while some other part of the kernel still retains a pointer to it, subsequent operations can dereference memory that no longer represents the original transport.

That is the essence of a use-after-free.

What Is SCTP Dynamic Address Reconfiguration?

SCTP’s Dynamic Address Reconfiguration extension allows an established association to modify its address configuration. RFC 5061 defines mechanisms including operations conceptually equivalent to:

ADD-IP
DEL-IP
SET-PRIMARY

They are transported through ASCONF, or Address Configuration Change, chunks. An ASCONF chunk contains an Address Parameter followed by one or more operations, and Linux processes those parameters in their message order. (Tencent Matrix)

This ordering matters enormously for SCTPhantom.

The vulnerability is not simply “DEL-IP frees memory incorrectly.” Instead, the bug emerges when two different pieces of address identity are allowed to diverge while the kernel assumes they describe the same safe transport state.

The Root Cause of SCTPhantom

The critical distinction is between two addresses.

Call the actual IPv4 packet source:

S

and call the address specified by the ASCONF Address Parameter:

L

Normally it is tempting to think of those values as representing the same peer identity. But SCTP multihoming means they do not necessarily have to be the same.

That creates the crucial state mismatch.

Linux’s sctp_process_asconf() caches the transport against which an ASCONF chunk is processed inside:

asconf->transport

En __sctp_rcv_asconf_lookup() identifies the association using the ASCONF Address Parameter, that cached transport can correspond to L rather than to the SCTP packet’s actual network source S. (Ubuntu)

Meanwhile, existing validation in sctp_process_asconf_param() prevents a DEL-IP operation from deleting the packet’s source address.

The conceptual security check therefore looks like:

Requested DEL-IP == packet source S ?
    yes -> reject
    no  -> continue

The problem is that protecting S does not necessarily protect asconf->transport.

Si:

S != L

then deleting L can pass the source-address check even though L corresponds to the transport stored in asconf->transport.

This is where SCTPhantom begins.

The Dangerous ASCONF Sequence

The researchers identified the following ordered structure:

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

The first meaningful operation asks the kernel to delete L.

Because the packet’s actual source is S and:

S != L

the existing protection against deleting the packet source does not stop the operation.

Linux removes the peer transport associated with L, while:

asconf->transport

continues pointing at the transport that is being removed. Its release is RCU-deferred, but logically the pointer has become unsafe. (Openwall)

The wildcard:

DEL-IP 0.0.0.0

is then processed.

At this point, subsequent code reuses asconf->transport. According to the kernel CVE description mirrored by Ubuntu and Debian, this affects functions including:

sctp_assoc_set_primary()
sctp_assoc_del_nonprimary_peers()

The first operation can dereference the freed transport and install the stale reference into:

asoc->peer.primary_path
asoc->peer.active_path

while later cleanup may remove remaining valid transports. The association can therefore survive while important path pointers refer to freed memory. (Ubuntu)

In simplified form:

Before:

association
  |
  +--> transport S
  |
  +--> transport L  <--- asconf->transport


DEL-IP L:

association
  |
  +--> transport S

transport L -> removed / eventually freed

asconf->transport
       |
       +-------------> stale transport L


Wildcard DEL-IP:

primary_path --------> stale transport L
active_path  --------> stale transport L

That stale reference is the use-after-free primitive behind CVE-2026-64564.

Why This Is More Dangerous Than a Kernel Crash

Use-after-free vulnerabilities frequently first appear as crashes under sanitizers, fuzzing or stress tests. But a crash does not define the vulnerability’s maximum impact.

The more important question is whether an attacker can control what replaces the freed object.

Linux kernel memory allocators continuously reuse freed memory. If an attacker can manipulate allocator behavior so that controlled data occupies the memory previously used by the SCTP transport, stale references may begin operating on attacker-influenced contents instead of on random garbage.

This is why exploitable use-after-free vulnerabilities are so valuable in kernel exploitation.

The SCTPhantom researchers went considerably further than demonstrating a panic. Their published research documents a complete exploitation chain in which the surviving SCTP transport UAF was transformed into memory-disclosure and kernel-memory manipulation primitives before eventually reaching root privileges. (Tencent Matrix)

At a high level, the published chain moved through:

SCTP transport UAF
        ↓
controlled object reclamation
        ↓
kernel memory disclosure
        ↓
KASLR recovery
        ↓
additional controlled kernel state
        ↓
credential manipulation
        ↓
root privileges

The researchers also demonstrated a usermode-helper-based route in their work and used the resulting capability to validate container-to-host escape. (Tencent Matrix)

The important defender takeaway is that CVE-2026-64564 should not be categorized as “only a denial-of-service bug.”

SCTPhantom and KASLR

Modern kernel exploits must normally contend with Kernel Address Space Layout Randomization, or KASLR.

Even when a memory corruption primitive exists, an attacker cannot safely reference useful kernel structures or code if the relevant addresses remain unknown. Information-disclosure primitives therefore frequently become part of a full kernel exploitation chain.

Tencent reports that its SCTPhantom chain used object reclamation to obtain a direct-map disclosure followed by a repeatable kernel read primitive and IDT-based KASLR recovery. The researchers then developed another UAF reclamation stage before reaching the credential-changing portion of the exploit. (Tencent Matrix)

This progression matters because it demonstrates exploitation maturity.

There is a major difference between:

crafted packet -> kernel crash

and:

memory corruption
 -> controlled lifetime manipulation
 -> memory leak
 -> KASLR defeat
 -> arbitrary security-state manipulation
 -> root

SCTPhantom reached the second category in the researchers’ tested environments.

Can CVE-2026-64564 Be Exploited Remotely?

This question requires a careful answer.

Some vendor CVE data describes the vulnerability using a network attack vector. Red Hat’s public description, for example, says that a crafted sequence of SCTP ASCONF chunks could trigger the UAF, and the CVE scoring shown through Ubuntu currently includes a CVSS 3.1 network-vector score of 9.8. (Portal del cliente de Red Hat)

However, the publicly demonstrated root exploitation chain described by the SCTPhantom researchers is presented as local low-privileged privilege escalation and container escape. Their CVSS v4 assessment uses AV:L y PR:L. In an oss-security follow-up, the researchers further clarified that their exploit requires CAP_NET_RAW, although it does not require CAP_NET_ADMIN, and a separate network namespace is not strictly necessary. (openwall.com)

These statements are not necessarily contradictory.

They describe different layers of the problem:

Protocol reachability / bug trigger
                vs.
Demonstrated reliable privilege-escalation exploit

A remotely reachable protocol parser can still have substantially different practical exploitation requirements when the objective changes from causing corruption to obtaining reliable arbitrary kernel execution or root privileges.

For asset prioritization, administrators should therefore avoid interpreting the CVE as meaning:

Every Internet-accessible Linux server can be remotely rooted through SCTPhantom.

The evidence published so far supports a more precise conclusion:

A dangerous SCTP memory-safety flaw exists, and researchers have demonstrated reliable local privilege escalation and container-to-host escape on multiple affected systems when the required SCTP and capability conditions are available.

Why Containers Matter So Much

Container environments are one of the most important SCTPhantom threat scenarios.

Containers share the host’s Linux kernel. Namespaces and capabilities isolate workloads, but a kernel memory corruption vulnerability crosses the boundary beneath those abstractions.

The security model is fundamentally:

Container process
      |
 namespaces
 capabilities
 seccomp
 LSM
      |
      v
===================
 Shared Linux Kernel
===================
      |
      v
     Host

If a process inside a container can exploit the shared kernel itself, successful exploitation can undermine the isolation mechanisms that normally prevent it from affecting the host.

Tencent reported successful container-to-host escape, and the researchers specifically noted during the oss-security discussion that Docker grants CAP_NET_RAW by default and that their exploit worked from within a container. (Tencent Matrix)

That makes CAP_NET_RAW particularly significant.

Administrators should not assume that an “unprivileged container” automatically lacks every capability relevant to SCTPhantom.

A useful inventory command for an authorized environment is:

docker inspect <container> \
  --format '{{json .HostConfig.CapAdd}} {{json .HostConfig.CapDrop}}'

Inside a Linux process or container, capabilities can also be inspected using tools such as:

capsh --print

The security question is not merely:

Is the container privileged?

but also:

Can the workload access SCTP?
Can SCTP be loaded?
Does it retain CAP_NET_RAW?
Is the host kernel vulnerable?

Is SCTP Enabled on Every Linux System?

No.

This drastically changes real-world exposure.

SCTP may be compiled directly into a kernel, built as a loadable module, installed but blacklisted, unavailable by default, or deliberately enabled because an application depends on it.

Red Hat states that its sctp kernel module is disabled by default on RHEL 8, 9 and 10, which is one reason Red Hat currently classifies the vulnerability as Moderate impact for those products rather than treating every installation as immediately exploitable. (Portal del cliente de Red Hat)

The oss-security discussion also notes that on the relevant RHEL-family systems, SCTP is supplied through kernel-modules-extra, with blacklist behavior that prevents ordinary unprivileged autoloading. Systems that explicitly install and activate SCTP naturally have a different exposure profile. (Openwall)

This is a critical risk-management lesson:

Kernel version alone is not enough to establish exploitability.

You need kernel version plus feature availability plus runtime configuration plus attacker capabilities.

How to Check Whether SCTP Is Loaded

Administrators can begin with:

lsmod | grep '^sctp'

Another useful check is:

grep -w sctp /proc/modules

If SCTP is currently loaded as a module, output should normally identify it.

You can also inspect the module:

modinfo sctp

Si modinfo cannot locate an SCTP module, that might mean the feature is unavailable as a module, built directly into the kernel, or packaged separately.

Kernel configuration provides another clue:

grep CONFIG_IP_SCTP /boot/config-$(uname -r)

Possible results include:

CONFIG_IP_SCTP=m

meaning SCTP is a loadable module, or:

CONFIG_IP_SCTP=y

meaning SCTP is compiled directly into the kernel.

A disabled result would substantially reduce this specific attack surface.

These checks are exposure checks, not exploit tests. That distinction is useful because production systems usually do not need a destructive proof of concept to determine whether remediation should be prioritized.

Which Linux Versions Are Fixed?

The vulnerable sequence traces back to Linux 2.6.25-era code. The upstream mainline fix is:

9b2854f86f0b

The SCTPhantom disclosure and Linux CVE announcement identify the first fixed versions on several maintained branches as:

Kernel branch	First fixed version
6.6.y	6.6.148
6.12.y	6.12.101
6.18.y	6.18.42
7.1.y	7.1.6
Mainline	7.2-rc5

These versions come from the Linux kernel CVE announcement referenced by the original disclosure. (Openwall)

But do no reduce patch validation to:

uname -r

followed by a simple numerical comparison.

Enterprise Linux vendors routinely backport security fixes into older kernel branches without changing to the upstream kernel version containing the original fix.

Por ejemplo:

Vendor kernel 5.14.x

may contain a security backport even though upstream Linux first fixed the problem in much newer maintained branches.

Conversely, an older vendor kernel that has not received the backport may remain affected.

The authoritative source for production remediation is therefore your distribution’s security advisory and package status.

Debian Status

As of August 17, 2026, Debian’s security tracker shows that the vulnerability has been addressed in Debian 13/Trixie security through:

6.12.101-1

and is fixed in newer Debian development branches shown in the tracker, while older listed Bullseye and Bookworm packages remain marked vulnerable in the current tracker data. (Debian Security Tracker)

That status can change as additional security updates move through repositories, so Debian administrators should validate against the current package advisory rather than permanently relying on a version table copied from an article.

Ubuntu Status

Ubuntu published its CVE-2026-64564 page on August 4 and last updated the page on August 14 at the time of this research. Its tracker currently lists multiple Ubuntu kernel packages and releases as affected and explicitly documents disabling SCTP as a mitigation when the protocol is not required. (Ubuntu)

Ubuntu’s recommended mitigation is conceptually:

echo "install sctp /bin/false" | \
  sudo tee /etc/modprobe.d/disable-sctp.conf

sudo update-initramfs -u

and, when it can safely be unloaded:

sudo rmmod sctp

Ubuntu notes that this is appropriate when SCTP is not needed. (Ubuntu)

Production operators should first verify that no telecom, signaling, clustered service, infrastructure component or other application depends on SCTP.

RHEL Status and Why Default Configuration Matters

Red Hat’s treatment of SCTPhantom provides a useful example of why CVE severity cannot be interpreted independently from product configuration.

Red Hat currently assigns a CVSS 3.1 score of 7.8 using a local attack vector and low privileges:

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

and states that SCTP is disabled by default on RHEL 8, RHEL 9 and RHEL 10. (Portal del cliente de Red Hat)

Its documented mitigation is to prevent the SCTP module from loading. Red Hat provides a configuration resembling:

install sctp /bin/true
blacklist sctp

followed by regeneration of the initramfs and rebooting. Systems that genuinely depend on SCTP should instead prioritize the corrected kernel packages. (Portal del cliente de Red Hat)

This is a good demonstration of attack-surface reduction working as intended.

A dormant kernel vulnerability is much less useful to an attacker if the vulnerable subsystem cannot be activated by the attacker.

The Research Was Validated Across Multiple Systems

Tencent’s oss-security disclosure states that retained exploit tests reached root on several targets, including Debian 13 with a 6.12.95-based kernel, Ubuntu 24.04 with 6.8.0-134-generic, and a Rocky Linux 9/RHEL 9-family 5.14-based target where SCTP was loaded. The researchers also validated the exploit against a Linux 7.2-rc2 research kernel. (Openwall)

That breadth matters because it reduces the likelihood that the exploitability was merely an accident of one particular upstream debug build.

At the same time, those tests should no be interpreted as saying every distribution or kernel build has identical exploit reliability. Kernel allocators, configuration options, hardening, packaging and backports all affect exploitation.

CVSS Confusion Around CVE-2026-64564

SCTPhantom is a particularly good example of why vulnerability teams should avoid prioritizing exclusively by one CVSS number.

The researcher disclosure assigns:

CVSS v4.0: 8.5 High
AV:L / AC:L / PR:L / UI:N

for the demonstrated local escalation scenario. (Openwall)

Red Hat currently gives:

CVSS v3.1: 7.8 High
AV:L / AC:L / PR:L / UI:N

for its product context. (Portal del cliente de Red Hat)

Ubuntu’s CVE page currently surfaces a 9.8 CVSS 3.x score using:

AV:N / AC:L / PR:N / UI:N

while still giving the issue a distribution-specific Ubuntu priority of Medium. (Ubuntu)

This apparent inconsistency should not be hidden.

Instead, defenders should ask concrete questions:

Is SCTP present?
Is it loaded?
Can an attacker load it?
Is the vulnerable ASCONF functionality reachable?
Does an attacker already have a local foothold?
Does a container retain CAP_NET_RAW?
Has the vendor backported the fix?

Those answers are usually more operationally useful than arguing whether the vulnerability is “7.8,” “8.5,” or “9.8.”

How to Safely Assess Exposure

A production-friendly assessment should avoid intentionally triggering the kernel UAF.

Start by identifying the kernel:

uname -a
uname -r

Then determine the distribution:

cat /etc/os-release

Check SCTP availability:

modinfo sctp 2>/dev/null

Check whether it is currently loaded:

lsmod | grep '^sctp'

Check the kernel build configuration where available:

grep CONFIG_IP_SCTP /boot/config-$(uname -r)

Look for explicit module restrictions:

grep -R "sctp" \
  /etc/modprobe.d \
  /usr/lib/modprobe.d \
  /lib/modprobe.d 2>/dev/null

Then validate the installed kernel against the distribution’s CVE advisory.

For container hosts, add capability auditing.

For Docker:

docker inspect <container> \
  --format '{{json .HostConfig.CapAdd}} {{json .HostConfig.CapDrop}}'

For Kubernetes workloads, inspect security contexts for unnecessary capabilities and avoid granting capabilities that are not required by the application.

A useful remediation decision tree is:

CVE-2026-64564 assessment
        |
        v
Is affected kernel installed?
        |
       yes
        |
        v
Has vendor backported the fix?
     /      \
   yes       no
   |          |
patched       v
         Is SCTP required?
          /        \
        no          yes
        |            |
 disable SCTP     patch kernel
        |            |
        +------> verify

Disable SCTP If You Do Not Need It

For many Linux servers, the best short-term mitigation is extremely simple:

remove the unnecessary protocol from the attack surface.

Ubuntu and Red Hat both document disabling the SCTP module as a mitigation for systems where SCTP is not required. (Ubuntu)

The exact persistent configuration should follow the guidance for the distribution you operate.

The broader principle is more important than the precise command:

unused kernel subsystem
        +
security-sensitive parser
        +
attacker-controlled data
        =
unnecessary attack surface

Protocols, filesystem drivers and compatibility modules that are not needed should not automatically remain reachable merely because they ship with Linux.

Reduce Container Capabilities

Because the published SCTPhantom exploit requires CAP_NET_RAW, container-hardening policy deserves special attention. The researchers explicitly stated that CAP_NET_ADMIN was not required and that Docker’s default capability set provides CAP_NET_RAW in the scenario they tested. (Openwall)

Where an application does not legitimately require raw sockets, consider removing that capability.

Conceptually:

securityContext:
  capabilities:
    drop:
      - NET_RAW

The exact policy depends on the container runtime and workload.

Dropping NET_RAW should not be treated as a substitute for patching the host kernel. It is a defense-in-depth control that reduces one path toward exploitation.

Kernel vulnerabilities have a habit of acquiring alternative exploitation techniques after public research becomes available.

Monitoring for SCTP Attack Surface Changes

Security teams can also monitor whether SCTP unexpectedly becomes active.

Useful signals include:

kernel module loading
unexpected SCTP sockets
raw socket creation
container capability changes
new kernel-modules-extra installations
modprobe configuration changes
kernel crashes in SCTP paths

Por ejemplo:

lsmod | grep sctp

can be incorporated into configuration management or fleet inventory.

Module-loading telemetry may also be monitored through Linux audit, eBPF-based security tools, EDR agents or host-security platforms.

The goal is not to create a signature for one exploit packet. It is to identify when a normally unused attack surface unexpectedly appears.

Kernel Crash Evidence

Attempts to exploit memory corruption can produce unstable intermediate failures even when a published exploit is designed to be reliable.

Defenders investigating suspicious hosts should therefore review:

journalctl -k

and:

dmesg

for SCTP-related kernel faults, general protection faults, slab corruption, invalid pointer dereferences or crashes involving functions associated with SCTP address reconfiguration.

A kernel crash by itself does not prove exploitation.

Likewise, the absence of a crash does not prove that exploitation did not occur.

Sophisticated privilege-escalation exploits specifically try to avoid crashing the kernel.

Patch Verification Is More Important Than Exploit Verification

One recurring operational mistake in vulnerability management is assuming that a vulnerability must be reproduced before a system can be considered exposed.

For SCTPhantom, defenders normally already have enough evidence.

The vulnerable code path is known. The upstream correction is known. Multiple distributions track the vulnerability. Researchers demonstrated root privilege escalation. (Openwall)

That means a safer validation strategy is:

configuration evidence
+
package evidence
+
vendor advisory
+
patch evidence

rather than deliberately corrupting production kernel memory.

An authorized isolated laboratory can be useful for exploit research, detection engineering and verifying compensating controls, but it should not become a prerequisite for ordinary fleet remediation.

How the Upstream Fix Works

The fix is conceptually small compared with the eventual exploit chain.

The problem is that Linux allowed the transport retained for ASCONF processing to be deleted during the same ASCONF operation.

The correction prevents a DEL-IP from targeting the transport against which the ASCONF chunk itself is being processed.

In other words, the kernel now protects not only the packet-source identity but the actual transport object whose lifetime subsequent ASCONF logic depends upon. (Ubuntu)

Conceptually:

Old logic:

if requested_address == packet_source:
    reject deletion


Fixed logic:

if requested_address == packet_source:
    reject deletion

if requested_transport == asconf_processing_transport:
    reject deletion

That closes the identity mismatch before the dangling pointer is created.

The lesson is important for secure protocol implementation: validation should protect the object whose lifetime matters, not merely an external identifier that is expected to correspond to that object.

SCTPhantom Is Fundamentally a State-Machine Bug

A particularly interesting aspect of CVE-2026-64564 is that no single malformed integer explains the vulnerability.

The bug requires understanding relationships among:

packet source address
Address Parameter
transport lookup
DEL-IP validation
transport ownership
ASCONF ordering
wildcard deletion
RCU object lifetime
association state
cached path pointers

A local check can appear correct:

Do not delete the source address.

Yet the global state remains unsafe because the object that actually matters was selected using another identity.

This category of bug is difficult to discover with purely syntactic reasoning.

Security analysis needs to reason about:

identity
+
ordering
+
ownership
+
lifetime
+
cross-function state

That is one reason old networking code continues to reveal serious vulnerabilities decades after deployment.

Why an 18-Year-Old Bug Survived

The original vulnerable sequence is traced to a Linux 2.6.25-era commit. The researchers describe the flaw as having persisted for roughly eighteen years. (Openwall)

That does not necessarily mean the code received no scrutiny.

Protocol implementations such as SCTP have enormous state spaces.

Consider only a few dimensions:

number of peer addresses
transport state
primary path selection
source address
ASCONF address parameter
operation ordering
heartbeat state
RCU timing
association lifetime
socket operation timing

Even if every dimension has only a handful of valid states, combinations multiply quickly.

The vulnerable condition may therefore occupy a narrow but security-critical region of the state machine.

This is precisely where stateful fuzzing, symbolic reasoning, sanitizer-assisted testing and increasingly agent-assisted source analysis can complement traditional review.

AI-Assisted Vulnerability Research and SCTPhantom

Tencent says SCTPhantom was developed through Corvus AI, a persistent multi-agent vulnerability-research pipeline used for source analysis, reproduction, crash triage, kernel building, exploit development and cross-platform validation. The researchers emphasize that the system preserved evidence and constraints across stages rather than treating vulnerability discovery as a single prompt-and-response task. (Tencent Matrix)

That aspect of the disclosure is strategically important.

Modern security agents become more interesting when they can maintain a loop resembling:

source hypothesis
      ↓
test generation
      ↓
kernel build
      ↓
reproduction
      ↓
sanitizer / crash evidence
      ↓
hypothesis refinement
      ↓
cross-version validation
      ↓
patch analysis

rather than merely producing speculative source-code findings.

SCTPhantom is therefore simultaneously a Linux kernel vulnerability story and an example of how AI-assisted vulnerability research is becoming more operational.

The strongest evidence is not that an AI system suggested a suspicious line of code. It is that the research workflow ultimately produced reproducible memory corruption, a validated exploitation chain, cross-platform testing and an upstream fix. (Tencent Matrix)

What Security Teams Should Prioritize

The highest-priority environments are not necessarily every Linux system with a numerically old kernel.

A more useful risk model is:

Risk
 =
 vulnerable kernel
 × SCTP availability
 × attacker access
 × relevant capabilities
 × container density
 × host criticality

A Kubernetes worker running untrusted workloads with unnecessary network capabilities deserves very different treatment from a locked-down appliance where SCTP is unavailable and the vendor has already backported the patch.

That is why CVE management should incorporate exploit preconditions.

Practical Remediation Checklist

For CVE-2026-64564, the operational response is straightforward.

First, identify Linux hosts and container nodes whose kernels are affected according to their distribution vendor.

Second, apply the vendor’s corrected kernel package as soon as operationally practical.

Third, reboot into the fixed kernel when the update requires it. Merely installing a new kernel package does not help a system that continues running the vulnerable kernel.

Fourth, if SCTP is unnecessary, disable it persistently and ensure it cannot be automatically loaded.

Fifth, review containers for unnecessary CAP_NET_RAW exposure.

Sixth, monitor SCTP module loading and unexpected raw-socket use on systems that normally should not use them.

Finally, validate the running kernel and mitigation state after maintenance.

A simple post-update check can start with:

uname -r
lsmod | grep '^sctp'

and then compare the package against the distribution’s current advisory.

Frequently Asked Questions

What is CVE-2026-64564?

CVE-2026-64564 is a Linux kernel use-after-free vulnerability known as SCTPhantom. It affects SCTP Dynamic Address Reconfiguration and can leave an SCTP association holding pointers to a freed transport object. Researchers demonstrated local privilege escalation to root and container-to-host escape. (Openwall)

Is SCTPhantom a Linux remote code execution vulnerability?

It is safer not to describe it generically as “remote root RCE.”

Vendor scoring currently differs regarding attack-vector interpretation, while the publicly demonstrated complete privilege-escalation exploit is described by its researchers as requiring local low privileges and CAP_NET_RAW. (Portal del cliente de Red Hat)

Does CVE-2026-64564 affect containers?

Potentially yes. Tencent demonstrated container-to-host escape, and the researchers said their exploit works from a Docker container in the tested configuration because the required CAP_NET_RAW capability is available by default there. (Openwall)

Does SCTPhantom require CAP_NET_ADMIN?

According to the researcher’s oss-security clarification, no. Their exploit requires CAP_NET_RAWno CAP_NET_ADMIN. (Openwall)

Can disabling SCTP mitigate CVE-2026-64564?

Yes, when SCTP is supplied as a loadable module and the system does not require it. Ubuntu, Red Hat and the researchers’ oss-security discussion all document preventing SCTP from loading as a mitigation strategy. (Ubuntu)

When was SCTPhantom fixed?

The upstream fix is commit 9b2854f86f0b. The first fixed versions announced for maintained upstream branches include Linux 6.6.148, 6.12.101, 6.18.42 and 7.1.6, with the mainline correction appearing in 7.2-rc5. Vendor kernels may backport the fix into older version numbers. (Openwall)

How old is CVE-2026-64564?

The vulnerable sequence traces back to Linux 2.6.25-era code, making SCTPhantom roughly eighteen years old when it was publicly disclosed in 2026. (Openwall)

Conclusión

CVE-2026-64564 SCTPhantom is important because it turns a subtle SCTP state-management mistake into a real kernel security boundary failure.

At the root of the vulnerability is an identity mismatch. Linux validated deletion against the SCTP packet’s source address while retaining a transport selected through the ASCONF Address Parameter. Once those two identities diverged, a carefully ordered DEL-IP sequence could remove the transport that later processing still expected to be alive. The result was a dangling transport pointer and a deterministic use-after-free. (Ubuntu)

Researchers then demonstrated that the flaw could be developed far beyond a crash: memory disclosure, KASLR recovery, kernel-state manipulation, root privilege escalation and container-to-host escape were all demonstrated on their tested systems. (Tencent Matrix)

But the defensive conclusion should remain equally precise. SCTPhantom does not make every Linux server remotely rootable. Exploitability depends on SCTP exposure, kernel state, capabilities and distribution configuration. Red Hat, for example, disables SCTP by default on current RHEL 8, 9 and 10 systems, while the published exploitation work identifies CAP_NET_RAW as an important requirement for its demonstrated chain. (Portal del cliente de Red Hat)

For security teams, the response is therefore clear: patch affected kernels, remove SCTP when it is not required, reduce unnecessary container capabilities, and validate actual runtime exposure instead of relying on a CVSS number alone.

SCTPhantom’s deeper lesson is broader than SCTP. Complex protocol implementations accumulate security assumptions around identity, ownership and object lifetime. Some of those assumptions can survive for decades. As automated source analysis, stateful testing and agent-assisted vulnerability research improve, similarly old but exploitable state-machine bugs are likely to become increasingly difficult for defenders to dismiss simply because the underlying code has been stable for years. (Tencent Matrix)