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

> SCTPhantom (CVE-2026-64564) gives local root on Linux, and public exploit code exists. See who is exposed, the patch dates, and how to block SCTP.

Canonical: https://www.nihardaily.com/posts/sctphantom-gives-root-on-linux-do-you-need-to-care
Last updated: 2026-10-21

- Published: 2026-08-08
- Author: Nihar Ranjan Das
- Reading time: 8 min
- Categories: Software
- Tags: sctphantom, cve-2026-64564, linux kernel, container escape, privilege escalation, sctp, server security, patching

## Key takeaways

- SCTPhantom (CVE-2026-64564) is a local-only Linux kernel use-after-free that gives root and, in containers, reaches the host; public exploit code is out.
- Red Hat blacklists SCTP by default, Canonical's denylist does not, and Tencent got root on Ubuntu 24.04, Debian 13 and Rocky 9 with SCTP loaded.
- The public exploit needs CAP_NET_RAW, which Docker keeps by default, so dropping it is a cheap extra barrier.
- Distribution kernels arrived through October 6, about nine weeks after the upstream fix, so block the sctp module if you cannot patch.

You need to care about SCTPhantom (CVE-2026-64564) if untrusted code runs on a Linux host that can load the SCTP kernel module, and you can stop caring about most of it once you block that module or install a patched kernel. It is a local bug, not a remote one. But a public exploit now exists, and the patch dates differ a lot between distributions. This update replaces our August summary with what has changed since.

## What changed since August

- **A public exploit is out.** [LinuxSecurity reported on August 11](https://linuxsecurity.com/features/sctphantom-exploit-linux-container-escape) that public container-escape code exists. It did not report any exploitation in the wild, and we did not find a CISA known-exploited listing.
- **The "no special capabilities" line needs a footnote.** The public exploit uses packet sockets, which need `CAP_NET_RAW`. Docker's default capability set keeps that capability.
- **Red Hat blocks SCTP by default; Canonical does not.** That changes who is exposed on a stock install.
- **Distro patches landed through September and early October,** so the question has moved from "is there a patch" to "has my distribution shipped it."

## What is SCTPhantom?

**SCTPhantom** is a use-after-free in the Linux kernel's SCTP code that lets an unprivileged local user gain root and, in a container, reach the host. A **use-after-free** is a bug where code keeps using memory after it was released, so whatever lands there next is treated as the original object. **SCTP** is a transport protocol that sits beside TCP and UDP, used mostly in telecom signalling.

Tencent Zhuque Lab found the flaw and [published the analysis on August 6](https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564). The trigger is an address-reconfiguration message that deletes the transport the message itself depends on. The code that completes the vulnerable sequence goes back to Linux 2.6.25 in 2007, which is why the coverage says 18 years. The upstream fix, commit `9b2854f86f0b`, rejects deleting the transport kept for the ASCONF chunk.

In Tencent's container test, six of eight attempts reached host root. The two failures were clean misses without a kernel panic, so the exploit retries without crashing the machine.

## Who is exposed by default

Exposure depends on three things: whether the SCTP module can load, whether untrusted code can reach packet sockets, and whether your kernel is patched.

| Environment | SCTP on a stock install | What to check |
|---|---|---|
| RHEL 8, 9 and 10 | Blacklisted by default, per Red Hat | Confirm nobody removed the blacklist |
| Rocky Linux 9 | Exposed if the module is loaded | Tencent got root with SCTP loaded |
| Ubuntu 24.04 | Canonical's denylist does not include SCTP | Tencent got root on 6.8.0-134 |
| Debian 13 | No default block mentioned in the reports we found | Tencent got root on 6.12.95 |
| CloudLinux 8 to 10 | Only if the extra modules package is installed | Stock installs are the safe case |
| Docker containers | Host module decides | Default profile keeps `CAP_NET_RAW` |

The Red Hat and Canonical statements come from [LinuxSecurity's summary](https://linuxsecurity.com/features/sctphantom-exploit-linux-container-escape). The CloudLinux row comes from [its own advisory](https://blog.cloudlinux.com/sctphantom-cve-2026-64564-local-root-exploit-status-and-fixes-for-cloudlinux).

!Matrix of Linux environments showing whether SCTP loads by default and whether the public SCTPhantom exploit reaches root, from RHEL to Ubuntu to Docker defaults

The distinction that matters is who can run code. A shared build runner, a multi-tenant container host, or a machine that runs customer code is the real target. A single-tenant web server with no untrusted local users still needs the patch, but it is not an emergency.

## Does a container stop it?

No, not by itself. The bug is in the kernel that containers share. LinuxSecurity says the public exploit uses packet sockets to reclaim freed memory, which needs `CAP_NET_RAW`, and that Tencent's escape did not need `CAP_NET_ADMIN` or `CAP_SYS_ADMIN`. Docker's default seccomp profile permits the socket calls, and its default capability set retains `CAP_NET_RAW`.

That gives you two cheap hardening steps for container fleets:

1. **Drop `CAP_NET_RAW`** from workloads that do not need raw sockets. LinuxSecurity says this should stop the packet-ring technique in the public code. Treat it as an extra barrier, not a fix, because other techniques may exist.
2. **Enforce the Restricted Pod Security Standard** in Kubernetes. It drops all capabilities except `NET_BIND_SERVICE` and requires an approved seccomp profile. Policy written in a document does nothing, so check that it is enforced at the namespace.

Neither step replaces patching. They reduce what a stolen container can reach while you wait for a kernel.

## When did the patches arrive?

Upstream stable kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148 shipped on August 3, with the fix in mainline 7.2-rc5. Distribution kernels arrived later, and vendors backport fixes without changing the version string, so read your vendor advisory, not the upstream number.

CloudLinux's advisory is the most complete public timeline we found. It shows how long a distribution fleet can wait:

| Date | Event |
|---|---|
| August 3 | Upstream stable kernels released |
| August 6 | Disclosure by Tencent Zhuque Lab |
| August 11 | Public container-escape code reported |
| August 31 | KernelCare livepatch for most current CloudLinux lines |
| September 28 | CloudLinux 8 kernel stable release |
| September 29 | CloudLinux 9 kernel (5.14.0-687.51.1) |
| October 1 | Extended-support kernels for CloudLinux 8 and 9 LTS |
| October 6 | CloudLinux 10 kernel (6.12.0-211.59.1) and Canonical's Ubuntu 22.04 5.15 kernel (USN-8875-1) |

!Timeline from the August 3 upstream fix through the August 6 disclosure and August 11 public exploit to distribution kernels on September 28 to October 6

Those are CloudLinux's dates, not Red Hat's or Canonical's. They show the pattern: about nine weeks between the upstream fix and the last distribution kernel in one vendor family. CloudLinux 7 had no kernel patch at the time of that page, and its only option was the mitigation. The optional 6.8 HWE kernel on Ubuntu 22.04 was also not yet fixed.

## How to block SCTP if you cannot patch

If your workload does not use SCTP, block the module. [CIQ's Rocky Linux advisory](https://kb.ciq.com/article/security-advisories/cve-sctphantom-mitigation) gives the commands.

```
lsmod | grep -E '^sctp[[:space:]]'      # is it loaded?
ss --sctp -a                            # does anything use it?
printf 'install sctp /bin/false\n' | sudo tee /etc/modprobe.d/block-CVE-2026-64564.conf
sudo rmmod sctp
sudo modprobe -n -v sctp                # should print: install /bin/false
```

Three details trip people up:

- **A plain `blacklist` line is weaker.** It stops automatic loading only. The `install sctp /bin/false` line also blocks an explicit `modprobe sctp`.
- **`rmmod` can fail while the module is in use,** and unloading ends every active SCTP association. CloudLinux saw `rmmod` fail on a test server and recommends a reboot with the override in place instead.
- **The `net.sctp.addip_enable` sysctl is not a defense.** Its default is already 0, and the exploit enables the feature per socket.

If you do need SCTP, firewall the traffic where the workload allows it and rely on your security module policy to restrict raw and packet sockets. Check that SELinux or AppArmor actually restricts SCTP, because having the module installed does not prove the chain is blocked.

## Who legitimately needs SCTP

Most teams do not. SCTP is used mostly in telecom signalling and by a few clustered systems, so a typical web, API or database host never opens an SCTP socket. The check is quick: if `ss --sctp -a` shows no associations and nothing in your configuration names the protocol, blocking the module costs you nothing.

The exception is anyone running telecom or signalling software, where SCTP is part of the job. In that case the module block would break the service, and you should lean on patching, firewall rules and the capability limits described above. Plan a maintenance window for the reboot, because the kernel update is the only complete fix.

A version number can also mislead you in the other direction. Red Hat's 5.14 kernel looks ancient next to upstream 7.1, yet Tencent got root on it with SCTP loaded, because the vulnerable code came from 2007 and vendors backport fixes without renumbering. Judge a host by its vendor advisory and its module state, never by the version string alone.

## A five-minute check for your fleet

1. **Find who runs untrusted code.** CI runners, container hosts, shared hosting and notebooks are the priority.
2. **Check the module.** Run the `lsmod` and `modprobe -n -v` commands above on one host per image.
3. **Check the kernel against your vendor advisory,** not against the upstream version table.
4. **Drop `CAP_NET_RAW`** in pod and container specs where raw sockets are not needed.
5. **Plan the reboot.** A kernel package update does not take effect on a running system without live patching.

## Why the headline overstates the risk and why you should patch anyway

The 18-year framing makes SCTPhantom sound like a crisis for every Linux server. It is not. The preconditions rule out most internet-facing servers with no untrusted local users, and Red Hat's default blacklist removes a large part of the enterprise base.

Severity scores also disagree. Our August post quoted an 8.5 under CVSS v4. CloudLinux's notes say Red Hat rates the issue Moderate with a CVSS score of 7.8. Both can be right, because the score depends on how much a vendor assumes about local access.

What changed since August is the public exploit. A bug that needs local access is far more dangerous once working code is public, because defenders no longer have the lead time that a private research chain gives them. If you run other people's code on shared kernels, the patch or the module block is worth doing this week.

## The takeaway

SCTPhantom is a serious bug for shared hosts and container platforms, and a modest one for single-tenant servers. Block the module if you do not use SCTP, drop `CAP_NET_RAW` from containers that do not need it, and move to the vendor kernel that your advisory names. The dates above show that the wait for a distribution fix can run for weeks, so the mitigation is not optional while you wait.


## FAQ

### Can SCTPhantom be exploited remotely?

No. SCTPhantom needs local access first, so a remote attacker would need a separate foothold before it matters. That is why shared build runners, multi-tenant container hosts and machines that run customer code are the priority, while single-tenant servers with no untrusted local users are a smaller concern.

### How do I check if my server is exposed to SCTPhantom?

Run lsmod and look for sctp, then sudo modprobe -n -v sctp to see whether it would load. Use ss --sctp -a to see if anything uses it. Then compare your kernel package with your vendor advisory, because backported fixes keep older version numbers.

### How do I block SCTP to mitigate CVE-2026-64564?

Write install sctp /bin/false into a file under /etc/modprobe.d, then unload the module with rmmod or reboot. A plain blacklist line only stops automatic loading. Unloading ends active SCTP associations, so check ss --sctp -a first. Remove the file after you boot a patched kernel.

### Does Docker stop the SCTPhantom container escape?

No. The bug is in the shared kernel. The public exploit uses packet sockets that need CAP_NET_RAW, which Docker's default capability set keeps, and the default seccomp profile permits socket calls. Dropping CAP_NET_RAW should stop that technique, but it is an extra barrier, not a fix.

### Which kernel versions fix SCTPhantom?

Upstream stable kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148 shipped on August 3, with the fix in mainline 7.2-rc5. Distribution kernels arrived later, through October 6 in CloudLinux's timeline. Use your vendor's advisory, because backports do not change the version number.

## Related

- [Nihar Ranjan Das](https://www.nihardaily.com/author/nihar-ranjan-das)
- [MCP vs UTCP: we timed both on the same 10 tools](https://www.nihardaily.com/posts/mcp-vs-utcp-we-timed-both-on-the-same-10-tools)
- [Nginx vs Caddy: we load-tested both reverse proxies](https://www.nihardaily.com/posts/nginx-vs-caddy-we-load-tested-both-reverse-proxies)
- [AI coding tools hid 15 GB on my Mac. unclog found it](https://www.nihardaily.com/posts/ai-coding-tools-hid-15-gb-on-my-mac-unclog-found-it)