TL;DR: CVE-2026-64564, nicknamed SCTPhantom, can turn an unprivileged local shell into host root and, in published tests, a container-to-host escape on vulnerable Linux kernels, according to Corgea's analysis of the oss-security disclosure and Tencent Zhuque Lab research. The case shows why kernel privilege amplifiers must be treated as supply-chain and CI risk, not just an operating-system patching issue.
NHIMG editorial — based on content published by Corgea: CVE-2026-64564 and the SCTPPhantom Linux kernel exploit
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.
Questions worth separating out
A: The trust boundary breaks at the host kernel.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Corgea's analysis of CVE-2026-64564 and the SCTPPhantom exploit chain →
CVE-2026-64564 and SCTPPhantom: what Linux teams need to do?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Linux SCTP flaw turns local code into root and container escape