Linux SCTP flaw turns local code into root and container escape

At a glance

What this is: CVE-2026-64564 is a Linux kernel SCTP flaw that can convert local code execution into host root, with published research also demonstrating container-to-host escape paths.

Why it matters: It matters because developer hosts, self-hosted runners, and container platforms often treat local code execution as a contained event, but this bug shows how quickly that boundary can collapse.

Context

CVE-2026-64564 is a kernel privilege-escalation issue, not an application bug, which matters because many security programmes still treat local code execution as a lower-order event. In practice, that assumption breaks on shared Linux hosts, developer workstations, and container fleets where the kernel becomes the real trust boundary.

The article ties the flaw to SCTP handling in the Linux kernel and to a reproducible exploit chain that moves from memory corruption to privileged code execution. That makes it relevant to AppSec, cloud, and platform teams that rely on Linux as the execution layer for CI, build systems, and containerised workloads.

Key questions

Q: What fails in practice when a Linux kernel use-after-free becomes a root exploit?

A: The failure is not just memory corruption. It is the collapse of the kernel’s object-lifetime trust model, where a freed transport or structure can be reused as if it were still valid. Once an attacker can reclaim that memory with controlled data, the bug can become a read primitive, a privilege escalation, or both.

Q: Why do kernel privilege escalation bugs matter so much for container security?

A: Because containers still share the host kernel, a flaw reachable from one workload can become a host compromise. Once an attacker can influence kernel state, namespace separation does not stop escalation into adjacent workloads or the underlying node. Teams should treat kernel reachability as part of the container threat model and restrict dangerous interfaces accordingly.

Q: What are the signs that a Linux kernel privilege escalation issue may be being exploited on a host?

A: Look for suspicious process execution followed by setuid activity, especially an unknown binary appearing just before su runs. Also watch for esp4, esp6, or rxrpc loading around other suspicious activity, and for freshly dropped ELF files being executed. Those signals are not proof on their own, but they are the most practical indicators to investigate quickly.

Q: How should teams decide whether a kernel CVE needs emergency response or routine patching?

A: Treat it as urgent when the exploit path is reproducible, reachable from common workloads, and capable of turning local code into root or host escape. The more the flaw widens blast radius across shared Linux hosts, the more it deserves immediate remediation and scoping across endpoints, CI, and containers.

Technical breakdown

How SCTP transport lifetime handling fails

The flaw sits in how the Linux SCTP stack tracks transport objects while processing ASCONF chunks that combine an Address Parameter with DEL-IP operations. The kernel validates one transport, stores it, then later reuses that stored pointer after the referenced transport has already been freed. That is a classic use-after-free pattern: the object’s lifetime ends, but another code path still trusts the stale pointer. The exploit depends on an identity mismatch between the transport that was checked and the transport that was later reused.

Practical implication: treat SCTP support as attack surface on any Linux host where untrusted local code can run.

Why the bug becomes a read primitive before privilege escalation

Use-after-free bugs are dangerous because freed kernel memory can often be reclaimed with attacker-influenced data. In the published chain, the stale SCTP object is replaced with another allocation, which lets the attacker reinterpret memory and obtain a kernel information leak. Once an attacker can recover a stable kernel address, they can defeat KASLR and move from crash-only behaviour to controlled exploitation. That shift is the difference between a denial-of-service defect and a reliable privilege amplifier.

Practical implication: investigate any local Linux exploit path that includes both memory disclosure and object reuse as a likely root path.

How container escape happens through the shared host kernel

Container isolation does not stop kernel compromise because containers share the host kernel. The published test kept the default seccomp profile and did not require CAP_NET_ADMIN or CAP_SYS_ADMIN for the container-escape variant, which means the attacker only needed a route into vulnerable SCTP handling from inside the container. Once the host kernel is compromised, usermode-helper style pivots can move the impact from the container namespace into the host’s initial namespaces. The security boundary was never the container alone; it was always the kernel beneath it.

Practical implication: if untrusted code can run in a container, verify the host kernel patch level as part of your isolation model.

Threat narrative

Attacker objective: The attacker wants to convert a local foothold into host-level control, and in container environments, into escape from the shared kernel boundary.

1. Entry occurs when an attacker gets unprivileged local code execution on a Linux host or in a container that can reach the SCTP trigger path.
2. Credential access is not the main step here; instead, the exploit abuses SCTP object lifetime handling to obtain a kernel memory disclosure and a usable read primitive.
3. Privilege escalation follows when the attacker uses the leak and controlled object reuse to trigger commit_creds() and obtain host root.
4. Impact is host compromise, with the published container test also showing a path to container-to-host escape on vulnerable kernels.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kernel privilege amplifiers are now supply-chain risk. The article is not just about a Linux CVE. It shows how a local foothold delivered through packages, CI, or developer tooling can become host compromise once the underlying kernel contains a reliable privilege amplifier. For identity and access teams, the lesson is that blast-radius control does not stop at application boundaries. The practitioner conclusion is to treat kernel exposure as part of the trust model for build and workstation estates.

Shared-kernel container isolation is only as strong as the host patch line. The published escape path matters because it did not rely on unusual privileges or exotic container settings. That means platform teams cannot assume default seccomp or dropped capabilities are enough when the kernel itself is exploitable. The practitioner conclusion is to align container governance with host kernel remediation, not with namespace settings alone.

SCTP attack surface should be managed as an unnecessary privilege pathway. The named concept here is kernel privilege amplifier exposure: any reachable kernel feature that turns untrusted local code into root. This vulnerability illustrates why rare protocols and legacy stacks deserve the same scoping discipline as higher-profile services. The practitioner conclusion is to inventory whether SCTP is actually needed anywhere it is enabled.

Exploitability changes the priority order for Linux fleet response. A crash-only kernel bug can be scheduled alongside routine patching, but a reproducible root chain on developer machines and runners deserves faster triage. That changes how risk is weighted across endpoint, platform, and AppSec ownership. The practitioner conclusion is to elevate vulnerable Linux workstations and self-hosted CI first, because they are the most plausible entry points.

Identity governance still matters here, even though the flaw is in the kernel. Once local code execution exists, service accounts, secrets, and build credentials on the host become reachable through the widened blast radius. The article reinforces a basic governance point: privilege boundaries are only durable when the substrate below them is patched. The practitioner conclusion is to review which identities and tokens sit on machines exposed to this kernel path.

What this signals

Kernel privilege amplifiers are a governance problem, not only a patching problem. When a local foothold can become host root, the programme question changes from ‘is the package updated?’ to ‘which Linux assets can turn a minor compromise into full-machine control?’ That is especially important for engineering estates where secrets, runners, and build steps share the same host trust boundary.

Shared-kernel containers need host-level risk ownership. Default seccomp and dropped Linux capabilities do not neutralise a kernel bug that is reachable from an untrusted workload. Teams should align container operations, endpoint patching, and workload placement so that container isolation assumptions are continuously tested against the actual host kernel state.

For practitioners

• Prioritise patching on developer and CI Linux hosts Move affected kernels on developer workstations, self-hosted runners, and shared engineering hosts to a fixed vendor build, then reboot into the remediated kernel and confirm the running version rather than only package state.
• Verify SCTP exposure on every Linux fleet segment Check whether SCTP is loaded, loadable, or required on each host class, and document where the protocol is present so you can scope the vulnerable attack surface before patch rollout completes.
• Treat container compromise on vulnerable hosts as kernel compromise Escalate investigations when untrusted local code or a container foothold appears on a host with an unfixed kernel, because the exploit chain can cross the container boundary through the shared host kernel.
• Review build and runner secrets on exposed Linux systems Identify service accounts, tokens, and credentials stored on Linux endpoints or runners that could be reached after local code execution becomes root, then reduce their residency on those machines.
• Use vendor backport status as the triage source of truth Do not rely on uname -r alone. Check distribution advisories and backport notes to confirm that the SCTP fix is present in the exact kernel build actually running in production.

Key takeaways

• CVE-2026-64564 shows how a Linux kernel flaw can turn routine local code execution into host root, which makes kernel patching part of blast-radius control.
• The published exploit chain matters because it moves beyond a crash into a leak, a read primitive, and a reproducible privilege escalation path.
• Teams should prioritise vulnerable developer machines, self-hosted runners, and container hosts, because those systems turn a kernel bug into an identity and access problem as well as a platform one.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management alongside the access controls that limit blast radius. It is designed for practitioners who need to connect identity boundaries to real operational risk across modern environments.