Linux SCTP flaw turns local code into root and container escape

At a glance

What this is: This is a Linux kernel SCTP use-after-free that can elevate local code execution to root and, in some container scenarios, escape to the host.

Why it matters: It matters because developer workstations, self-hosted runners, and shared engineering hosts often carry the exact local-code foothold attackers need before a kernel bug converts that foothold into full machine compromise.

By the numbers:

• The vulnerable sequence spans Linux kernel releases from 2.6.25 through first fixed stable lines such as 6.6.148, 6.12.101, 6.18.42, and 7.1.6.

👉 Read Corgea's analysis of CVE-2026-64564 and the SCTPPhantom exploit chain

Context

Linux kernel privilege-escalation bugs matter most when they sit beneath environments that already allow local code execution. In this case, the SCTP attack surface turns an ordinary workstation, build runner, or container host into a potential host-compromise path if the kernel is vulnerable and SCTP is reachable.

For identity and access teams, the key issue is blast radius. Once a malicious package, compromised CI step, or developer foothold can trigger kernel-level escalation, the boundary is no longer the application session or container sandbox but the host kernel that protects secrets, registries, and source control credentials.

Key questions

Q: What breaks when a Linux host allows local code execution and an exploitable kernel privilege bug is present?

A: The trust boundary breaks at the host kernel. An attacker who starts with an unprivileged shell can sometimes turn memory corruption into credential theft, root access, and persistence beneath the application layer. On shared developer or CI systems, that can expose secrets, repositories, and build infrastructure even when the original foothold looked low risk.

Q: Why do shared developer and CI hosts increase the impact of kernel privilege escalation?

A: They concentrate untrusted code, automation credentials, and high-value secrets on the same machine class. If the shared kernel is vulnerable, one foothold can cross from a package install or build step into host compromise, widening access far beyond the original process. That is why these systems deserve priority over ordinary endpoints.

Q: How can security teams tell whether a container escape risk is really a host-kernel problem?

A: Check whether the attack requires only ordinary container defaults, whether the host kernel is shared across workloads, and whether the exploit path reaches kernel memory or credential state. If the answer is yes, the container boundary is not the control that matters. The host kernel and its patch state become the decisive security controls.

Q: Who is accountable when a kernel exploit turns a workload foothold into root access?

A: Accountability usually spans platform, cloud, and identity teams because the path to exploitation often begins with access decisions, exposed services, or weak workload isolation. NIST CSF and OWASP NHI both support treating that chain as a shared governance problem, not a single-team failure.

Technical breakdown

How the SCTP ASCONF path creates a use-after-free

The flaw sits in Linux SCTP Dynamic Address Reconfiguration, specifically how ASCONF chunks handle address changes and DEL-IP operations. The kernel stores a transport pointer after validating one address, then later reuses that pointer after the peer association has already been removed and freed. That mismatch between the validated address and the surviving pointer creates a classic use-after-free condition. Because the same object can be reclaimed by attacker-influenced allocations, the bug becomes more than a crash: it can become a read or write primitive.

Practical implication: confirm whether SCTP is enabled or loadable on developer and CI hosts before assuming the kernel path is irrelevant.

Why the bug escalates from memory corruption to root

The public exploit chain shows that a dangling transport can be reclaimed in a way that leaks kernel memory, then used to recover high-value addresses and build a repeatable primitive. Once an attacker can disclose direct-map data and defeat address randomisation, they can chain a second reclamation into controlled kernel object handling and ultimately trigger credential changes through existing kernel logic. This is the difference between a parser bug and a privilege amplifier: the exploit does not need new code in kernel text, only enough control over object reuse and layout.

Practical implication: treat any local execution on an affected host as a possible kernel incident until the running kernel is verified as fixed.

Why container escapes are credible in this case

Container isolation does not neutralise a shared host kernel. If untrusted code can reach the SCTP trigger path inside a container, the same kernel bug can be exercised beneath default seccomp settings, even without CAP_NET_ADMIN or CAP_SYS_ADMIN in the published variant. The security boundary that matters is the host kernel, not the container process itself. That is why the issue is relevant to self-hosted runners, internal build sandboxes, and developer platforms that reuse a common Linux kernel across workloads.

Practical implication: map vulnerable kernels to any shared-host environment where less-trusted code can run, then prioritise patching over workload-level containment assumptions.

Threat narrative

Attacker objective: The attacker wants to turn a low-privilege foothold into host root and extend that access beyond the container or workstation boundary.

1. Entry occurs when an attacker gets unprivileged local code execution on a vulnerable Linux host or inside a container that can reach the SCTP path.
2. Escalation follows when the SCTP ASCONF use-after-free is triggered and the freed transport is reclaimed for memory disclosure and controlled object reuse.
3. Impact is host root, and in the container variant the same kernel compromise can be leveraged into host-level escape from the shared kernel.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Privilege amplifiers are the real supply-chain risk here: this bug does not begin with a remote internet exploit, it begins after local code execution has already been achieved. That makes package installs, build steps, and developer shells the relevant trust boundary. AppSec programmes that focus only on application-layer scanning miss the moment when the kernel becomes the deciding control plane. Practitioners should treat host-kernel exploitability as part of software supply-chain risk.

SCTP surface area is a governance problem, not just a kernel problem: the attack requires the vulnerable protocol path to exist on the host, be loadable, or be reachable from untrusted workloads. That means teams need inventory, configuration ownership, and exception handling for SCTP just as they do for exposed services. The control gap is hidden attack surface, not simply delayed patching. Practitioners should make protocol exposure visible before they rely on version numbers alone.

Blast-radius control is the missing concept in developer and CI security: the published container escape shows that a default seccomp profile is not enough when the shared host kernel is exploitable. The real boundary is whether an attacker can cross from a less-trusted workload into the kernel underneath it. That is a ZTA and NHI-adjacent problem because secrets, tokens, and build credentials on those hosts become reachable once the host is lost. Practitioners should redesign trust around the host boundary, not the container boundary.

Kernel privilege escalation should be tracked as a residual risk in identity programmes: the systems most exposed here often hold human credentials, service tokens, registry secrets, and automation keys. When local code execution and host compromise converge, identity controls such as least privilege and secret isolation can be bypassed by the platform itself. That means IAM and PAM teams need a seat in incident triage for developer endpoints and runners, not only for directory or cloud events. Practitioners should include kernel escape paths in identity risk reviews.

Named concept: local-to-host privilege amplification: this is the pattern where an attacker starts with unprivileged code and uses a kernel flaw to expand into host control. It is especially dangerous in shared engineering environments because one compromised workload can affect many identities, pipelines, and repositories. The practical conclusion is that patch latency, protocol exposure, and host reuse all contribute to the final blast radius. Practitioners should rank these systems as high-consequence assets.

From our research:

• The published research chain retained the default seccomp profile and did not require CAP_NET_ADMIN or CAP_SYS_ADMIN for the container-escape variant, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• For a broader NHI lens, see 52 NHI Breaches Analysis for repeated patterns of exposed credentials and fast abuse paths.

What this signals

Local-to-host privilege amplification should now be treated as a programme risk wherever untrusted code runs on shared Linux hosts. The practical question is no longer only whether the kernel is patched, but whether the environment concentrates secrets, automation tokens, and CI trust on a single attackable kernel boundary.

The next control gap is inventory and enforcement around protocol exposure. If SCTP, container runtime defaults, or self-hosted runners are not explicitly governed, teams will continue to assume the sandbox is the boundary when the kernel actually is. That is a governance failure with identity consequences, especially where host compromise exposes human and non-human credentials.

For practitioners

• Patch and reboot affected kernels Install a vendor kernel that includes the SCTP fix and confirm the running kernel is actually remediated after reboot, not just the package catalog. Track the exact fixed line for each distribution and do not rely on uname alone.
• Reduce SCTP exposure on shared hosts Disable SCTP where workloads do not require it, and remove it from container hosts, developer stations, and runners that can execute untrusted code. This reduces the trigger surface while patching is rolling out.
• Prioritise developer and CI fleets first Put workstation images, self-hosted runners, and internal build sandboxes ahead of production servers if they allow less-trusted code execution. Those systems are the most likely first-stage footholds for local-to-host escalation.

Key takeaways

• CVE-2026-64564 matters because it converts ordinary local code execution into host root on vulnerable Linux kernels.
• The published container variant shows that default container settings do not eliminate risk when the shared host kernel is exploitable.
• Developer workstations and self-hosted runners need the fastest remediation because they combine untrusted code, secrets, and the attack surface most likely to be targeted first.

Key terms

• Use-after-free: A use-after-free occurs when code continues to read or write memory after it has already been released. In kernel networking paths, this often becomes a security issue because stale pointers can expose secrets, corrupt control flow, or crash the system under the right timing conditions.
• Linux Kernel Privilege Escalation: A vulnerability that lets an attacker move from low privilege to root or kernel-equivalent control on a Linux system. These issues matter because the kernel sits above applications, containers, and most security tooling, so a single flaw can invalidate many downstream trust assumptions.
• Container escape: A condition where code running inside a container reaches beyond the container boundary and gains control over the underlying host or other workloads. The risk increases when the host kernel is vulnerable or when the container is granted unnecessary capabilities or debug access.
• Protocol attack surface: Protocol attack surface is the set of network or transport features that can be exercised by untrusted input and reach privileged code paths. It matters because unused or lightly used protocols can still expose kernel parsers, lifetime bugs, and memory corruption conditions.

What's in the full analysis

Corgea's full analysis covers the exploit mechanics and kernel-version details this post intentionally leaves at the governance and remediation level:

• Distribution-by-distribution kernel cutovers and backport status for Debian, Ubuntu, and RHEL-family targets
• The exact exploit chain from transport lifetime bug to direct-map leak, kernel read primitive, and privilege escalation
• Container-escape test conditions, including seccomp settings and capability requirements
• Detection commands and triage steps for identifying affected Linux hosts and verifying patch status

👉 The full Corgea post covers the kernel exploit path, affected Linux lines, and validation details

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of real-world identity risk. It helps practitioners connect identity controls to the broader security architecture that developers, pipelines, and shared hosts depend on.