Was SCTPhantom tatsächlich bricht

CVE-2026-64564 - von manchen Forschern, die darüber berichten, SCTPhantom genannt - ist eine Use-after-free-Schwachstelle in der Linux-Kernel-Implementierung von SCTP, dem Stream Control Transmission Protocol, das vor allem in der Telekom-Signalisierung, in einigen Finanz-Messaging-Systemen und in manchen Container- und Cluster-Netzwerkstacks eingesetzt wird. Der Fehler sitzt konkret in ASCONF, dem Code für Dynamic Address Reconfiguration, der es einer aktiven SCTP-Assoziation erlaubt, IP-Adressen hinzuzufügen oder zu entfernen, ohne die Verbindung abzubauen. Die CVE wurde am 4. August 2026 offiziell bekannt gegeben, nach einem privaten Offenlegungsprozess, der bereits am 12. Juli 2026 begonnen hatte.

Die eigentliche Ursache ist eine Identitätslücke: Wenn der Kernel eine DEL-IP-Anfrage zum Entfernen einer Adresse aus einer Assoziation verarbeitet, prüft er diese Anfrage anhand der Quelladresse im eingehenden Paket, während ein separater zwischengespeicherter Zeiger im Kernel sich weiterhin nach der im Anfrageparameter genannten Adresse richtet. Ein Angreifer, der eine gezielt geordnete Folge von ASCONF-Chunks konstruiert, kann diese Lücke zwischen den beiden Prüfungen ausnutzen, um einen Kernel-Speicherbereich freizugeben, während ein aktiver Zeiger noch darauf verweist - das Lehrbuchbeispiel eines Use-after-free und eines der verlässlicheren Werkzeuge, um aus einem Kernel-Fehler ausführbaren Code zu machen.

Achtzehn Jahre sind die Schlagzeile, nicht die Lehre

Der verantwortliche Code stammt aus Linux 2.6.25, veröffentlicht im Dezember 2007, was den Fehler zum Zeitpunkt der Entdeckung durch Tencents Zhuque Lab auf rund 18 Jahre alt macht. Die Forscher schreiben den Fund Corvus AI zu, einer autonomen Multi-Agenten-Pipeline zur Schwachstellenforschung, die das Team intern betreibt und die den ASCONF-Codepfad als prüfenswert markierte. Dieses Detail zählt fast so sehr wie der Fehler selbst: Es handelt sich nicht um einen bekanntermaßen riskanten Kernel-Bereich, der endlich einmal auditiert wurde, sondern um eine tatsächlich unauffällige Ecke, die fast zwei Jahrzehnte lang niemand genauer betrachtet hat.

Stabile Fixes erschienen am 3. August 2026 in den Kernel-Zweigen 6.6.148, 6.12.101, 6.18.42 und 7.1.6, und die Distributions-Maintainer beginnen bereits, diese in ihre eigenen Paketbäume zu übernehmen. Das ist der Teil der Geschichte, über den jedes Medium berichtet, und zugleich der Teil, der für die meisten Leser am wenigsten zählt. Eine Lücke von 18 Jahren zwischen dem Ausliefern und dem Entdecken des Fehlers belegt, dass eine Strategie des Wartens auf den Patch auf genau diesem Codepfad schon achtzehn Jahre lang stillschweigend versagt hat - es gibt keinen Grund anzunehmen, dass die nächste unbeachtete Ecke des Kernels schneller gefunden wird, weshalb es unabhängig von jedem einzelnen Patch-Datum darauf ankommt, was auf einer gegebenen Maschine überhaupt erreichbar ist.

Root-Zugriff und Container-Ausbruch, praktisch vorgeführt

Tencents Zhuque Lab führte den Exploit vollständig vor, nicht nur einen Absturz. Auf Systemen mit Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 und OpenCloudOS verwandelte das Team das Use-after-free in eine vollständige Root-Rechteausweitung von einem unprivilegierten lokalen Konto aus und nutzte dieselbe Technik anschließend, um in sechs von acht Versuchen aus einem Container auf den Host auszubrechen - ohne CAP_NET_ADMIN oder CAP_SYS_ADMIN, die erhöhten Rechte, die die meisten Container-Härtungsanleitungen als erste Hürde für einen Angreifer voraussetzen.

Die Exploit-Kette hebelte die Kernel Address Space Layout Randomization aus, verkettete ein zweites Use-after-free mithilfe angreiferkontrollierter SCTP-Authentifizierungsschlüssel und baute einen gefälschten Kernel-Objektgraphen auf, um Root zu erreichen - alles ohne Shellcode oder eine Return-Oriented-Programming-Kette, also genau die Techniken, die die meisten Kernel-Exploit-Abwehrmaßnahmen eigentlich abfangen sollen. Die Tests umfassten Kernel-Versionen von 5.14 bis zum Release-Kandidaten 7.2, und der Upstream-Fix landete als Commit 9b2854f86f0b, bevor er in die vier oben genannten stabilen Zweige zurückportiert wurde.

Die einfache Korrektur, die die meisten Teams auslassen

Der Patch ist real und lohnt sich, behandelt aber ein Symptom. Fast keine der Organisationen, die diese fünf Distributionen betreiben, hat sich bewusst für SCTP entschieden - es ist standardmäßig fest in den Mainline-Kernel einkompiliert, und die meisten Betreiber wissen nicht einmal, dass es vorhanden ist, geschweige denn, dass ein lokaler Prozess darauf zugreifen kann. Das ist die eigentliche Lehre, die im oss-security-Offenlegungsthread der Forscher steckt: Ein Beitragender im Thread wies darauf hin, dass RHEL-basierte Systeme SCTP standardmäßig draußen halten, ausgeliefert als separates Paket kernel-modules-extra mit gesperrtem automatischem Laden, während Debian- und Ubuntu-Kernel SCTP fest einbauen und es laden lassen, sobald irgendein Prozess danach fragt. Zwei Systeme können dieselbe CVE tragen und dennoch bei sehr unterschiedlichem realem Risiko liegen, und der Unterschied hat nichts mit dem installierten Patch zu tun.

Die diese Woche lohnende Maßnahme ist nicht das Warten auf das Distributions-Update, sondern die Prüfung, ob SCTP auf einer gegebenen Flotte überhaupt einen Nutzen erfüllt. Der Befehl lsmod | grep sctp zeigt, ob das Modul aktuell geladen ist; ein Blick in /etc/modprobe.d/ zeigt, ob ein Blacklist-Eintrag das automatische Laden bereits verhindert. Wo nichts legitim von SCTP abhängt - und auf den meisten Allzweck-Servern ist das der Fall - schließt eine Blacklist des Moduls die Tür unabhängig davon, welche Kernel-Version irgendwann eintrifft; eine Gewohnheit, die sich mit dem deckt, was das deutsche BSI (Bundesamt für Sicherheit in der Informationstechnik) in seinem IT-Grundschutz für jedes ungenutzte Kernelmodul ohnehin empfiehlt, nicht nur für dieses eine.

Weiterlesen: Das RMM-Tool Ihres MSP hat eine zweite Bypass-Lücke  |  Der Anruf, der Ihre Firmen-MFA aushebelt