Enterprise IT News

Enterprise IT News: 18-Year-Old Linux Kernel Root Flaw

Published August 9, 2026 · DNS Benchmark Pro Editorial · Reading time: 5 minutes

Verified researcher screenshot showing successful local root privilege escalation from the SCTPhantom Linux kernel zero-day vulnerability across four Linux distributions used in enterprise server infrastructure — Verified researcher screenshot: local privilege escalation to root reproduced on four separate Linux distributions using the SCTPhantom chain. *Credit: Tencent Zhuque Lab (Figure 2), published 6 August 2026.*

TL;DR — The week's biggest enterprise IT news is a kernel bug, not a breach. CVE-2026-64564, named SCTPhantom, is a use-after-free in the Linux SCTP dynamic address reconfiguration code that has existed since Linux 2.6.25 in 2008. Tencent Zhuque Lab reached root on Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 and OpenCloudOS, and escaped a container to the host in six of eight attempts with the default seccomp profile and no elevated capabilities. Fixes shipped in stable kernels 6.6.148, 6.12.101, 6.18.42 and 7.1.6 on 3 August; public disclosure followed on 6 August. The flaw is local, not remote, and needs SCTP reachable — which is the single most useful fact for triage.

Most enterprise IT news that involves the word "root" concerns an internet-facing appliance. This one concerns the transport layer of the operating system underneath practically every Linux server, hypervisor and container host in your estate. SCTPhantom is a zero-day vulnerability only in the narrow sense that nobody knew about it for eighteen years; there is no evidence of exploitation in the wild, and as of 7 August it had not appeared in CISA's Known Exploited Vulnerabilities catalog. What makes it worth an unscheduled patch cycle is the second half of the research: a working container-to-host escape.

What SCTPhantom actually breaks

The Stream Control Transmission Protocol, defined in RFC 4960, is a message-oriented transport built for multihoming — one association can span several network paths at once. It is the protocol carrying most SS7-over-IP and Diameter signalling in mobile core networks, and it turns up in telecom, finance and clustering software far more often than in general-purpose web stacks. RFC 5061 adds Dynamic Address Reconfiguration, letting a peer add or drop those paths mid-association.

The bug is an identity mismatch. When the kernel processes an ASCONF chunk, it validates a DEL-IP request against the packet's IPv4 source address, but selects the transport to act on using a different address carried inside the message body. Because those two identities can differ, an attacker can craft an ordered sequence — address parameter L, then DEL-IP L, then a wildcard DEL-IP 0.0.0.0 — that passes the source check, frees transport(L), and then has the wildcard branch reuse the now-stale pointer as the path to preserve. The association is left with primary_path and active_path both referencing memory the kernel has already released.

A later getsockopt(SCTP_STATUS) on the surviving socket dereferences that dangling pointer. From there the researchers built a full chain: reclaim the freed 1024-byte slot with a TPACKET pg_vec array to leak a kernel direct-map address, convert SCTP_STATUS's association-ID lookup into a repeatable four-byte kernel read, recover the KASLR slide from IDT gate 0, then reclaim a second use-after-free with controlled SCTP authentication-key data to build a fake object graph ending in a data-oriented call to commit_creds(). No shellcode, no ROP.

Why container escape is the part that matters for cloud security

Containers share the host kernel. That is the whole architectural bargain, and it is why any local kernel privilege escalation is a latent multi-tenancy problem. The researchers' first proof of concept required the net.sctp.addip_enable and net.sctp.addip_noauth_enable sysctls, which implied CAP_NET_ADMIN was a prerequisite. They subsequently found a path that leaves both sysctls untouched by enabling the features per socket via SCTP_ASCONF_SUPPORTED and SCTP_AUTH_SUPPORTED, with the trigger carrying a valid AUTH chunk. The final callback invokes call_usermodehelper_exec(), which runs in the host's initial namespaces.

Verified technical screenshot of a container-to-host escape achieved through the SCTPhantom Linux kernel vulnerability, demonstrating a cloud security risk for multi-tenant server infrastructure — Verified technical screenshot of the container-to-host escape, executed with the default seccomp profile and without `CAP_NET_ADMIN` or `CAP_SYS_ADMIN`. Six of eight attempts reached host root; the two failures were clean pointer-walk misses rather than kernel panics. *Credit: Tencent Zhuque Lab (Figure 3), published 6 August 2026.*

Two caveats belong alongside that claim, and good IT security practice is to hold both. First, nobody outside the lab has reproduced the escape, and the write-up does not name the container runtime tested. Second, the lab itself notes that socket access policy, seccomp profiles, user-namespace configuration and LSM policy all shift exposure elsewhere; an openKylin advisory covering the same bug goes no further than kernel panic and denial of service. Severity is likewise unsettled — Tencent scored it 8.5 under CVSS v4.0, while NVD had assigned neither a score nor a weakness class as of 7 August.

Patch status and server infrastructure exposure

Kernel branch	First fixed version	Notes
6.6.y	6.6.148	Stable release, 3 August 2026
6.12.y	6.12.101	Stable release, 3 August 2026
6.18.y	6.18.42	Stable release, 3 August 2026
7.1.y	7.1.6	Stable release, 3 August 2026
Mainline	7.2-rc5	Commit `9b2854f86f0b`

The upstream fix is three lines: reject the deletion when the selected peer is the transport retained for the ASCONF chunk being processed. It lands in net/sctp/sm_make_chunk.c. A second, related dangling-transport use-after-free in the same code was patched on 6 August, after those stable releases shipped — so the 3 August kernels do not carry that one, and a follow-up point release is worth watching for.

One operational trap deserves emphasis. Distribution vendors routinely backport security fixes without moving the upstream version string, so uname -r tells you almost nothing about your exposure here. Check the vendor tracker or the source package, not the number. Debian 13 shipped a kernel update covering both SCTPhantom and the unrelated Zapscape KVM escape disclosed the same day.

The practical triage question: is SCTP even reachable?

On most general-purpose Linux servers the sctp module is not loaded and is only autoloaded when a process creates an SCTP socket. That makes module blacklisting the cheapest and most durable mitigation available:

Inventory first. Check lsmod | grep sctp across the fleet, and confirm whether any workload actually opens SCTP sockets. Telecom signalling, some clustering stacks and certain financial messaging products do; almost nothing else does.
Blacklist where unused. Add install sctp /bin/true to a modprobe configuration file. This removes the attack surface outright rather than shrinking it, and it survives the next kernel bug in the same subsystem.
Patch where used. Telecom and signalling infrastructure cannot blacklist the module, and should be first in the patch queue rather than last.
Treat multi-tenant hosts as higher priority. Shared Kubernetes nodes, CI runners executing untrusted code, and any host running customer workloads carry the container-escape risk that a single-tenant application server does not.
Verify with seccomp. A profile that denies socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP) blocks the trigger at the syscall boundary for containerised workloads.

Why this enterprise IT news matters beyond one CVE

Three structural points sit under the headline.

Dormant protocol code is where the remaining kernel bugs live. SCTPhantom joins GhostLock and RefluXFS in a 2026 run of long-buried Linux flaws, and Tencent credits the find to Corvus AI, a multi-agent research pipeline built specifically to trace dense protocol state machines. Machine-assisted auditing is now reaching code paths that a decade of human review and fuzzing did not. Defenders should expect the discovery rate in obscure networking subsystems to keep climbing, which makes "disable what you do not use" a strategy rather than a chore.

Local is not low. A local-only flaw is a two-stage problem: it needs a foothold first. But every phishing click, exposed CI runner and compromised web application already supplies one, and a DDoS attack or noisy intrusion attempt is often the diversion rather than the payload. Once an attacker has any code execution on a shared host, a kernel primitive of this quality converts a contained incident into a platform-wide one.

Kernel patching is a network availability event. Rebooting fleets means rolling restarts across load balancers, DNS records and health checks. It is exactly the window in which stale records, half-drained pools and unexpected network latency surface. Teams that measure DNS server performance and resolver behaviour before and after a maintenance window catch those regressions in minutes rather than after the first support ticket. A lightweight network diagnostic tool that reports resolver latency from the affected site is faster than a config audit, and it doubles as a DNS security check — an unexpected resolver answering where it should not is one of the first signs that something changed on the host.

Chart from an earlier release of the DNS Benchmark Pro tool ranking DNS-over-HTTPS response times across public resolvers after kernel patching — Capture from the DNS Benchmark Pro engine as it stood in August 2026. **Correction (15 August 2026):** this chart was produced by a release of the benchmark that timed opaque browser requests and did not verify that a response was a valid DNS answer, so the figures may include HTTP errors and unreadable replies counted as fast responses. They should not be relied on. The engine has since been rebuilt to validate every response — see the current methodology. After a fleet-wide kernel reboot, re-measuring resolver behaviour from the affected site is a fast sanity check that name resolution came back the way you left it.

The takeaway for network and platform teams

SCTPhantom is not an emergency for most organisations, and framing it as one wastes the credibility you need for the next genuine emergency. It is, however, a clean argument for two habits that pay off repeatedly: keep an accurate inventory of which kernel modules your workloads actually require, and treat shared-kernel hosts as a distinct risk tier with its own patch SLA. The organisations that will patch this fastest are not the ones with the best scanners — they are the ones that can already answer, in an afternoon, which hosts have SCTP loaded and why.

Running a maintenance window this week? Confirm your resolver path afterwards with the free browser-based DNS speed test, read how the benchmark measures DNS over HTTPS latency and jitter, or revisit our earlier report on the SonicWall SMA 1000 zero-day chain for the edge-device side of the same problem.

Sources

Published by Genext Information Systems · August 9, 2026. DNS Benchmark Pro is an independent tool and is not affiliated with Tencent, the Linux Foundation or any vendor named in this article. This report summarises publicly available researcher and vendor disclosures and is provided for informational purposes. The two exploitation screenshots are genuine, unmodified figures published by Tencent Zhuque Lab and are reproduced here with attribution and a link to the original research; the benchmark chart is a real capture from the DNS Benchmark Pro engine. No AI-generated imagery is used on this page.