Container isolation is the assumption an enormous amount of cloud infrastructure is built on: one tenant’s workload should never be able to reach another’s, or the host underneath both of them. SCTPhantom is a reminder that this assumption is only as strong as the kernel code enforcing it, and in this case, the code had a hole in it for nearly two decades before anyone found it.
An 18-year-old bug, found by an AI research pipeline
The flaw sits in the kernel’s SCTP Dynamic Address Reconfiguration feature and traces back to code introduced in Linux 2.6.25 in December 2007. It is a use-after-free: an attacker can send an ordered ASCONF sequence that removes a network transport and then reuses the now-stale pointer to it, leaving the association holding dangling references it should not have. Tencent credits the discovery to Corvus AI, a multi-agent research pipeline it built specifically to hunt for this class of kernel bug, making SCTPhantom the latest in a run of long-dormant kernel flaws surfaced with machine assistance this year. The bug was disclosed publicly on 6 August, two days after the kernel CVE team assigned it a number.
From local privilege escalation to a host takeover
On its own, the bug grants local privilege escalation, an unprivileged local user reaching root. What makes it more serious is what Tencent’s researchers demonstrated next: reused inside a container, the same bug lets an attacker escape the container boundary entirely and take root on the host machine underneath. Tencent Zhuque Lab confirmed working exploits against kernel builds used by Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9, and OpenCloudOS. Exploitation requires local access and SCTP reachable on the target, which limits the attack surface compared with a remote, unauthenticated flaw, but “local access” describes exactly the position every tenant on a shared container host already occupies by design.
Why this matters more for containers than servers
Fixed kernels, 7.1.6, 6.18.42, 6.12.101, and 6.6.148, shipped on 3 August. For a standalone server, this is a routine patch cycle. For any organisation running multi-tenant container platforms, whether that is a Kubernetes cluster, a managed container service from a European cloud or hosting provider, or shared infrastructure serving multiple customers, an unpatched host means the isolation between tenants is not actually holding. That is precisely the scenario data residency and sovereignty commitments are meant to rule out, and it is worth confirming directly with your infrastructure provider whether their host kernels were patched, rather than assuming a routine update cycle already covered it.
If your organisation runs containerised workloads on Linux and needs help verifying patch status across your fleet or reviewing container isolation assumptions in your infrastructure, contact Excello Digital. We help European businesses keep cloud and container infrastructure genuinely isolated, not just isolated on paper.