SCTPhantom (CVE-2026-64564) Local Root Exploit: Status and Fixes for CloudLinux

SCTPhantom is a Linux kernel vulnerability that lets a local unprivileged user become root, and the researcher additionally demonstrated an escape from a container to the host. It was disclosed on August 6, 2026 by Fourie Zhang of the TencentOS Security Team, through a coordinated process rather than as a zero-day. A full-chain proof-of-concept has been public since August 7, 2026.

The flaw is old. It was introduced in Linux 2.6.25 in 2007, so the vulnerable code has shipped for eighteen years and is present in essentially every Linux distribution in use today, CloudLinux included. What differs by platform is whether an attacker can reach it, and on most CloudLinux versions a stock install keeps it out of reach.

Here “local” does not mean an insider or a customer you trust. It means any process on the machine, including the PHP worker behind a compromised WordPress plugin or an outdated CMS. The attacker is whoever hacked one of the sites you host. If they can reach this bug, they go from that one confined site to root over the whole server, and every other tenant on it.

Affected CloudLinux versions

The vulnerable SCTP code is present in every kernel CloudLinux ships. Exposure is conditional: it depends on whether the SCTP module can be loaded on the host, and on most versions a stock install keeps it unavailable. The table records the condition per version and the current fix state.

^† CloudLinux for Ubuntu takes its kernel from Ubuntu (Canonical) via apt, not a CloudLinux stream. As of August 31, 2026 Canonical has not published a fixed 22.04 kernel. Until it does, the mitigation below is the remedy on this platform.

^†† On CloudLinux 7 and CloudLinux for Ubuntu 22.04 an ordinary user can load the SCTP module, so the vulnerable code is reachable there in a way it is not on the other versions. The published exploit still fails on both because it needs unprivileged user namespaces, and CloudLinux keeps those switched off on both platforms. But a loadable module is a real gap. It leaves one control holding the line against this one exploit, where the other versions keep the module itself out of reach. The module change below closes that gap, which is why it is worth doing on these two rather than treating it as optional.

How to check your servers

Three commands, about ten seconds. Run them as root on each host.

# 1. Is the module loaded right now? Output means yes.
lsmod | grep -E '^sctp '

# 2. Is the module file even on disk? "not found" means it cannot be loaded at all.
modinfo -n sctp

# 3. Can an ordinary user reach SCTP? Run this as a non-root user.
python3 -c 'import socket; socket.socket(socket.AF_INET, socket.SOCK_STREAM, 132)'

What the answers mean:

• Command 1 prints nothing and command 2 says not found: nothing to do. The module cannot be loaded on this host by anyone. This is the normal result on a stock CloudLinux 8 or 9.
• Command 1 prints nothing, command 2 prints a path, and command 3 fails with Protocol not supported: the module exists but is blocked from loading on request. This is the normal result on a stock CloudLinux 10, and it is a safe state. The hardening below makes it firm.
• Command 1 prints a line: SCTP is loaded and running. Treat this host as exposed and act on it today.
• Command 3 succeeds: an ordinary user can reach the vulnerable code. Treat this host as exposed and act on it today.

On CloudLinux 7h, 8, 8 LTS, 9 and 9 LTS the sctp module ships only in the optional kernel-modules-extra package, which a standard install does not include. That is why command 2 reports it missing on a stock host. Installing that package is what puts the module on disk; check whether it is present with rpm -q kernel-modules-extra.

Is there a mitigation?

Yes, and on CloudLinux 7 and CloudLinux for Ubuntu 22.04 this step matters, because those two ship no blacklist and let an ordinary user load the module. On the other versions the module is already unavailable on a stock install; the same change makes that permanent, so it is worth doing but not urgent.

If you do not use SCTP, make the module unloadable and keep it that way:

printf 'blacklist sctp\ninstall sctp /bin/false\n' > /etc/modprobe.d/99-sctphantom.conf

Note: a plain blacklist only stops automatic loading; install ... /bin/false also defeats a deliberate modprobe.

What does not protect you. You may see advice that net.sctp.addip_enable = 0, the default, keeps you safe. It does not. The exploit switches the feature on per socket and never reads that system-wide setting. Judge exposure by whether the module can be loaded, not by that value.

If a host currently shows SCTP loaded, plan a reboot. Unloading the running module does not work reliably: on a test server the module refused to unload after a single load, reporting a use count with no dependent modules and no open SCTP sockets, and only a reboot cleared it. Write the configuration file above, then schedule a reboot. Do not assume rmmod sctp removed it.

Compatibility. Do not apply this if you actually use SCTP. That includes telecoms signalling stacks, some Kubernetes services configured for SCTP, and a few high-availability cluster interconnects. Check with lsmod | grep sctp and ss -a --sctp before changing anything.

Update instructions

The mitigation above closes the entry point on any host. The fixes below remove the vulnerability itself. Deploy whichever applies to your platform as it becomes available.

Stream 1: KernelCare livepatch

kcarectl --update

The livepatch closes the vulnerability on a running kernel with no reboot. Confirm it landed with kcarectl --patch-info | grep CVE-2026-64564 (see How to verify).

Stream 2: CloudLinux 8 and 7h kernels

Alternatively, the KernelCare livepatch closes the issue on CloudLinux 8 and 7h with no reboot, and the mitigation closes the entry point in the meantime.

Stream 3: AlmaLinux kernel (CloudLinux 9, CloudLinux 10)

Alternatively, the KernelCare livepatch closes the issue on CloudLinux 9 and 10 with no reboot, and the mitigation closes the entry point in the meantime.

Stream 4: TuxCare ELS LTS kernel (CL8 LTS, CL9 LTS)

How to verify you are patched

KernelCare livepatch (Stream 1). After an update, a patched server prints a line naming the CVE:

kcarectl --patch-info | grep CVE-2026-64564

If that prints nothing, the patch is not applied on that host. Check that kcarectl --update completed without error.

Kernel update (Streams 2, 3, 4). Once a patched kernel is released, compare your running kernel against the target version in that stream’s most recent status callout above:

uname -r

Mitigation. Re-run the self-check. With the configuration file in place, command 3 should fail with Protocol not supported and a deliberate modprobe sctp should fail as well.

The rest of this advisory is background for readers who want it: how the exploit plays out on a shared host, and the technical detail of the underlying bug. Neither is required to act on the status above.

Why this matters on a shared host

Where an attacker can reach this bug, the chain on an unpatched host is short, and none of it needs special access:

1. A web-tier compromise. An attacker exploits a vulnerable WordPress plugin, an outdated CMS, or one of the everyday web-application flaws shared hosting sees constantly. They now run as the site’s PHP-FPM identity or its CageFS account, in theory confined to that one site.
2. SCTPhantom. From that unprivileged process, the attacker frees and reclaims an SCTP transport object to corrupt kernel memory and become root. No prior root, no special capability, no admin action.
3. Root on the host. They now run outside every CageFS boundary and every per-tenant limit. Every other tenant’s files, databases, credentials, and backups on that server are within reach, and in the worst case recovery means rebuilding the whole server.

Step 2 is the one that platform configuration decides. Where the SCTP module cannot be loaded, the attacker never gets an SCTP socket and the chain stops at step 1. Where it can, on CloudLinux 7 and CloudLinux for Ubuntu 22.04, the locked user namespaces stop the published exploit a step later instead, on a narrower margin that the module change is there to widen. Either way, a web-tier compromise stays one site to clean up rather than a whole server to rebuild. That is what the mitigation, the livepatch, or a patched kernel each buy you.

The published exploit does not, on its own, run against a CloudLinux kernel. Its kernel addresses and structure offsets are hardcoded for a Debian build, and an attacker would have to re-derive every one of them for the specific kernel in front of them. That raises the bar, but it does not remove it. The barriers described in this advisory are doing real work, which is why keeping them in place matters.

Technical details of the bug

SCTP supports reconfiguring an association’s addresses while it is running, through ASCONF messages. When such a message asks to delete an address, the kernel validates the request against the packet’s source address, then acts on a different transport object: the one named by the message’s own address parameter. A single crafted message can therefore free a transport that the association still points at, leaving a dangling pointer in its primary and active path. From there the exploit reclaims the freed memory, forges a kernel structure inside it, and turns the dangling pointer into a controlled write, which it walks up to root.

Reaching the flawed code requires an SCTP socket, which on most CloudLinux versions an unprivileged user cannot obtain because the module is unavailable. Building a working exploit on top of it additionally needs a way to spray kernel memory. The published exploit uses a packet-socket ring buffer, which an unprivileged user can only get with elevated network capability inside a user namespace. That is the second independent barrier, and on CloudLinux 7, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04 unprivileged user namespaces are switched off.

The defect was introduced by commit 42e30bf3463c in Linux 2.6.25, released in December 2007, and the vulnerable code has been present ever since. The upstream fix is commit 9b2854f86f0b, “sctp: don’t free the ASCONF’s own transport in DEL-IP processing” — a six-line change to sctp_process_asconf_param() in net/sctp/sm_make_chunk.c.

References

• Original disclosure on oss-security, August 6, 2026: seclists.org/oss-sec/2026/q3/457
• Researcher’s technical writeup: SCTPhantom (CVE-2026-64564)
• CVE record: CVE-2026-64564
• NVD entry: CVE-2026-64564
• Upstream vendor advisory: Red Hat CVE-2026-64564
• Ubuntu security tracker: CVE-2026-64564
• Upstream fix: commit 9b2854f86f0b