SCTPhantom gives root on Linux. Do you need to care?

A kernel bug that survived 18 years is a good headline. It is a poor way to judge risk.

SCTPhantom is real, it works, and researchers used it to walk out of a container onto the host. It also needs local access and a network protocol most servers never touch.

Both of those things are true. The useful question is which one applies to your machines.

Key Takeaways

• SCTPhantom, tracked as CVE-2026-64564, is a use-after-free in the Linux kernel's SCTP code that dates to version 2.6.25 in 2007 and rates 8.5 under CVSS v4.
• It gives an unprivileged local user root on the host and allows a container escape, with no special capabilities required.
• Fixed kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148 shipped on August 3, and unloading the SCTP module blocks the bug on hosts that cannot patch yet.

What SCTPhantom actually is

SCTP is a transport protocol that sits alongside TCP and UDP, used mostly in telecom signalling and a few clustered databases. Most Linux servers have the module available and never send a packet with it.

The flaw lives in the part of SCTP that lets a connection change its addresses while running. A use-after-free is a bug where code keeps using memory that has already been released, so whatever lands in that memory next gets treated as the original object.

Tencent Zhuque Lab published the full chain in its SCTPhantom analysis. An ordered sequence of address-reconfiguration messages removes a transport, then reuses the stale pointer. A second use-after-free with attacker-controlled authentication key data builds a fake object graph, which ends in a call that grants root.

The root cause traces back to a commit in Linux 2.6.25, released in 2007. That is why the coverage keeps calling it an 18-year-old flaw.

Who is actually exposed

This is the part most write-ups bury. The bug is local, not remote. Nobody is scanning the internet and taking your server with it.

An attacker needs three things to line up.

Precondition	Detail
Local access	Any unprivileged account or code execution on the box
SCTP reachable	The module loaded, plus raw and packet socket access
Nothing else	No special capabilities, and it works under default seccomp

That last row is the uncomfortable one. A container escape is the step where code inside a container reaches the host that runs it, and here nothing extra stands in the way once the first two conditions hold.

So the exposure is shaped by who can already run code on your machine. Consider a shared build runner, a multi-tenant container host, or any box where untrusted code executes. Those are the systems where a local privilege bug becomes a real incident.

A single-tenant web server with no untrusted local users is a much smaller problem. It still needs patching, just not at three in the morning.

Which systems were confirmed vulnerable

The researchers did not stop at a proof of concept on one kernel. They reported getting root across mainstream distributions.

• OpenCloudOS 6.6.119
• Debian 13 running 6.12.95
• Rocky Linux 9 and RHEL 9 on the 5.14 vendor kernel
• Ubuntu 24.04 on 6.8.0-134-generic

That spread matters because vendor kernels backport heavily. A version number that looks old, such as the 5.14 line in RHEL 9, does not mean the vulnerable code is absent.

The disclosure went to the oss-security mailing list on August 6, and The Hacker News covered the escape angle the same week. Cyberpress reported the same root and escape result.

What to do this week

Patching is the whole answer, and the patches already exist.

Stable kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148 landed on August 3, with the fix in mainline 7.2-rc5. Debian 13 shipped a kernel update covering this bug and a second one, as 9to5Linux reported. Check your distribution's advisory rather than the upstream version, because backported vendor kernels carry their own numbering.

If you cannot reboot yet, the mitigation is straightforward. Unload the SCTP module and blacklist it on hosts that do not need the protocol. That removes the attack surface entirely rather than making the exploit harder.

Where SCTP is genuinely required, the fallback options are narrower. Restrict raw and packet socket access through your security module policy, and firewall SCTP traffic where the workload allows it.

How this compares to the week's other bugs

It is worth putting this next to the other security news. Google's AI-assisted work on browser security produced a large chrome vulnerability count this year, and most of those bugs were found before anyone shipped an exploit.

SCTPhantom is the opposite case. The exploit came first, complete and demonstrated on four distributions. That inversion is the reason a local-only bug still deserves a same-week patch window.

It also lands in the same month as a run of developer security incidents, from supply chain attacks on package registries through to agent tooling. The common thread is that attackers keep finding value in the boring infrastructure nobody audits.

Frequently asked questions

Can SCTPhantom be exploited remotely?

No. It requires local access to the machine first. A remote attacker would need a separate foothold before this bug becomes useful to them.

How do I check whether SCTP is loaded?

List your loaded kernel modules and look for the sctp entry. If it is absent and nothing on the host needs the protocol, blacklisting it prevents the module from loading on demand.

Does this affect containers specifically?

Containers are the notable case because the researchers demonstrated an escape to the host. A container boundary does not stop it, since the bug is in the shared kernel both sides use.

Is a reboot required after patching?

Yes, unless you use live kernel patching. A kernel package upgrade does not take effect on a running system by itself.

The takeaway

The eighteen-year framing makes SCTPhantom sound like a crisis for everyone running Linux. It is not. The precondition list rules out most internet-facing servers with no untrusted local users.

But it is a genuine problem for anyone running other people's code on shared kernels. If that describes your fleet, the patch is out, the mitigation is one module away, and neither is worth deferring.