SCTPhantom ist eine neue Linux-Kernel-Lücke in der SCTP-Verarbeitung und wird als CVE-2026-64564 geführt. Forscher von Tencent Zhuque Lab beschreiben lokale Root-Eskalation und Container-to-Host-Escape auf getesteten Systemen. Gefährdet sind vor allem Hosts, auf denen SCTP nutzbar ist und ein verwundbarer Kernel läuft. Für Betreiber von Container-Hosts, CI-Runnern und Hosting-Plattformen zählt deshalb jetzt die Prüfung von Kernelstand, SCTP-Nutzung und Container-Härtung.
SCTPhantom steckt in SCTP ASCONF und betrifft Kernel seit 2008
SCTPhantom betrifft den SCTP-Code im Linux-Kernel. SCTP ist ein Transportprotokoll mit Multi-Homing-Funktionen. Die betroffene Komponente verarbeitet Dynamic Address Reconfiguration über ASCONF. Genau dort kann eine fehlerhafte DEL-IP-Verarbeitung laut NVD dazu führen, dass ein bereits freigegebener Transportzeiger weiterverwendet wird.
Für Linux-Server ist der Fall wichtig, weil es nicht um eine normale Nutzerland-Bibliothek geht. Die Schwachstelle sitzt im Kernel. Ein erfolgreicher Angriff kann deshalb auf getesteten Systemen lokale Root-Rechte erreichen. In Container-Umgebungen ist das besonders heikel, weil Container den Kernel des Hosts mitnutzen.
Tencent beschreibt SCTPhantom als Use-after-free in SCTP Dynamic Address Reconfiguration. Der Fehler entsteht durch eine Inkonsistenz zwischen der Adresse, die eine Löschoperation validiert, und dem Transport, den der Kernel für die weitere ASCONF-Verarbeitung behält. Dadurch kann ein Angreifer nach der Freigabe eines Transportobjekts erneut auf denselben alten Zeiger treffen.
Der CVE-Eintrag nennt Linux 2.6.25 als Beginn des betroffenen Bereichs. Damit steckt die anfällige Logik seit 2008 im Kernel. Das bedeutet nicht automatisch, dass jedes System praktisch angreifbar ist. Entscheidend ist, ob der betroffene SCTP-Code erreichbar ist, ob der Kernel noch verwundbar ist und ob ein Angreifer lokal Code ausführen kann.
Die wichtigsten Fakten im Überblick:
- CVE-2026-64564 betrifft SCTP ASCONF im Linux-Kernel.
- Use-after-free ist die technische Fehlerklasse.
- CVSS v4.0 liegt laut oss-security bei 8.5 und damit High.
- lokale niedrige Rechte reichen laut Forscherangabe als Ausgangspunkt.
- Root-Eskalation wurde auf getesteten Distributionen erreicht.
- Container-to-Host-Escape wurde durch Tencent auf getesteten Systemen demonstriert.
| Punkt | SCTPhantom | Admin-Einordnung |
|---|---|---|
| CVE | CVE-2026-64564 | Security-Ticket und Scanner-Abgleich nötig |
| Komponente | SCTP Dynamic Address Reconfiguration über ASCONF | Kernel-Netzwerkstack prüfen |
| Fehlerklasse | Use-after-free | Kernelrechte können betroffen sein |
| Angriffspfad | lokal mit niedrigen Rechten, bei Container-Hosts auch Container-to-Host nach Forscherangabe | nicht als reine Remote-Lücke einordnen |
| Fix | Upstream-Fix 9b2854f86f0b | Vendor-Updates bevorzugen |
| Veröffentlichungsstand | NVD veröffentlicht am 4. August und geändert am 7. August | aktuelle Advisories weiter beobachten |
Die ersten korrigierten Kernelversionen sind laut oss-security und NVD 6.6.148, 6.12.101, 6.18.42, 7.1.6 und 7.2-rc5. Bei Distributionskerneln reicht diese Liste aber nicht allein. Ubuntu, Debian, Red Hat, SUSE oder Cloud-Anbieter können Fixes zurückportieren und trotzdem eine ältere Basisversion anzeigen. Entscheidend ist deshalb das jeweilige Vendor-Advisory oder Paket-Changelog.
Tencent nennt erfolgreiche Tests auf mehreren Zielen. Dazu gehören Debian 13 mit Kernel 6.12.95+deb13-amd64, Ubuntu 24.04 mit 6.8.0-134-generic und ein Rocky-Linux-9/RHEL-9-Familienziel mit Vendor-5.14-Kernel, sofern SCTP geladen war. Diese Angaben zeigen reale Exploitbarkeit auf verbreiteten Plattformen, ersetzen aber keine pauschale Aussage über jede Distribution und jede Containerkonfiguration.
Der Fall erinnert daran, wie wichtig regelmäßige Kernelpflege bleibt. Der Linux-Patchcheck Juli 2026 zeigte bereits, wie schnell sich Kernel- und Distributionsstände unterscheiden können. SCTPhantom verstärkt diesen Punkt, weil ein älter wirkender Vendor-Kernel bereits gepatcht sein kann oder ein neuerer Eigenbau noch anfällig bleibt.
Wann Container wirklich gefährdet sind
Die wichtigste Einordnung: SCTPhantom ist keine klassische Internet-Remote-Lücke, bei der ein fremder Angreifer ohne Zugang direkt von außen Root wird. Der Angriff braucht lokalen Codezugriff oder einen bereits laufenden Container auf dem Zielhost. Genau deshalb sind Container-Hosts, Shared-Runner, Hosting-Systeme und Mehrmandanten-Umgebungen die kritischsten Ziele.
Ein hohes Risiko besteht vor allem bei dieser Kombination:
- verwundbarer Kernel: Der Kernel enthält den SCTP-ASCONF-Fehler noch.
- SCTP erreichbar: SCTP ist geladen, ladbar oder durch Containerprozesse nutzbar.
- lokaler Codezugriff: Ein Nutzer, Build-Job oder Container kann eigenen Code starten.
- unzureichende Isolation: Seccomp, Capability-Set, User Namespaces oder Modulpolitik blockieren den Pfad nicht ausreichend.
- gemeinsam genutzter Host: Ein erfolgreicher Kernelangriff hätte Folgen über einen einzelnen Container hinaus.
| Umgebung | Risiko | Priorität |
|---|---|---|
| CI-Runner mit untrusted Builds | hoch, falls SCTP erreichbar und Kernel anfällig | sofort Kernel und SCTP prüfen |
| Kubernetes-Worker mit mehreren Tenants | hoch bei Mehrmandantenbetrieb | Worker priorisiert patchen und isolieren |
| Docker-Host mit fremden Containern | hoch, wenn Container eigenen Code ausführen dürfen | Container-Profile und Kernelstand prüfen |
| klassischer Einzelserver ohne lokale Nutzer | niedriger, aber nicht irrelevant | regulär patchen und lokale Konten prüfen |
| Desktop ohne SCTP-Nutzung | meist niedrig, falls SCTP nicht geladen oder blockiert ist | Modulblockade und Update reichen oft |
Tencent betont, dass der Container-Escape in den eigenen Tests auch ohne CAP_NET_ADMIN und ohne CAP_SYS_ADMIN gelang. The Hacker News weist aber zurecht darauf hin, dass diese Angaben bisher aus dem Forscherbericht stammen und nicht unabhängig breit reproduziert wurden. Admins sollten den Fall deshalb weder verharmlosen noch als universellen Sofortbruch jedes Containers darstellen.
Die sinnvolle Reaktion besteht aus Patchen und Begrenzen. Erstens sollten Admins Kernelpakete über die eigene Distribution oder den Cloud-Anbieter aktualisieren. Zweitens sollte SCTP deaktiviert oder blockiert werden, wenn es im Betrieb nicht benötigt wird. Drittens sollten Container-Profile SCTP-Sockets und unnötige Protokollfamilien nicht erlauben, wenn Workloads sie nicht brauchen.
Für Container-Plattformen ist die SCTP-Frage oft einfach: Viele Web-, Datenbank-, Build- und App-Workloads benötigen SCTP nicht. In solchen Umgebungen kann eine Blockade des Moduls oder eine restriktive Seccomp-Policy das Risiko deutlich senken, bis gepatchte Kernel überall ausgerollt sind. Systeme mit Telecom-, Signaling- oder Spezialnetzwerk-Workloads brauchen dagegen sorgfältigere Tests vor einer Deaktivierung.
Admin-Teams sollten jetzt vier Prüfungen durchführen:
- Kernelstand prüfen: Vendor-Pakete, Security-Advisories und Changelogs gegen CVE-2026-64564 abgleichen.
- SCTP-Nutzung prüfen: Geladene Module, Kernelkonfiguration und Anwendungen mit SCTP-Abhängigkeit erfassen.
- Containerprofile prüfen: Seccomp, Capabilities, User Namespaces und untrusted Workloads kontrollieren.
- Runner priorisieren: CI-Systeme mit fremden Pull Requests, Plugin-Builds oder Kundenjobs zuerst patchen.
Eine pauschale Versionserkennung kann in die Irre führen. Ein RHEL- oder Ubuntu-Kernel mit älterer Basisnummer kann den Fix bereits als Backport enthalten. Ein selbst gebauter Kernel mit scheinbar neuer Version kann dagegen anfällig bleiben, wenn der konkrete Fix fehlt. Für produktive Systeme zählt daher die Paketquelle mehr als die reine Ausgabe von uname.
Für Hoster und Managed-Plattformen kommt die Kommunikation hinzu. Kunden müssen wissen, ob ein Hostkernel bereits gepatcht wurde, ob SCTP blockiert ist und ob Container-Worker neu gestartet wurden. Gerade bei Kubernetes reicht ein Paketupdate auf dem Node nicht immer, wenn der alte Kernel bis zum Neustart weiterläuft.
Auch mobile oder eingebettete Linux-Systeme verdienen Aufmerksamkeit, wenn sie eigene Kernelzweige nutzen. Nicht jedes Linux-Gerät bietet Nutzern lokalen Codezugriff. Trotzdem bleiben lange gepflegte Kernelzweige anfällig für alte Fehlerklassen, wenn Hersteller Backports versäumen. Die Ubuntu-Touch-Aktualisierung auf 24.04-2.0 zeigt, wie breit Linux-Plattformen inzwischen verteilt sind.
Zum Recherchezeitpunkt gibt es laut The Hacker News keinen Hinweis auf eine Aufnahme in den CISA-KEV-Katalog und keine bekannte öffentliche Exploit-Veröffentlichung. Das senkt den kurzfristigen Massendruck, aber nicht die Priorität für Container-Hosts. Sobald technische Details öffentlich sind, verkürzt sich das Fenster zwischen Forschung und praktischer Nachnutzung.
SCTPhantom ist deshalb vor allem ein Infrastrukturthema. Einzelne Desktopnutzer ohne SCTP-Nutzung haben ein anderes Risiko als ein Hoster mit fremden Containern. Die höchste Priorität liegt bei Servern, CI-Runnern und Mehrmandanten-Hosts mit ungepatchtem Kernel und nutzbarem SCTP. Dort sollten Updates, Neustarts und temporäre SCTP-Blockaden nicht auf den nächsten regulären Wartungslauf warten.