SCTPhantom (CVE-2026-64564): eine 18 Jahre alte Use-after-Free-Lücke im Linux-Kernel-SCTP-Stack — Root-Behauptung umstritten

TL;DR — 90 Sekunden

Betroffen?

Praktisch jeder Linux-Kernel seit 2.6.25 (2008) bis zu den Fix-Versionen 7.1.6/6.18.42/6.12.101/6.6.148 (alle veröffentlicht am 3. August 2026) — betroffen sind Bare-Metal-Hosts, VMs und insbesondere Container-/Kubernetes-/K3s-Nodes mit aktivierbarem SCTP-Modul.

Risiko?

Use-after-Free (CWE-416) in der SCTP-ASCONF-Handhabung: Der Kernel prüft eine Delete-Anfrage gegen die Quelladresse des Pakets, handelt dann aber auf Basis einer anderen, im Nachrichtenkörper enthaltenen Adresse — das kann einen Transportpfad freigeben, auf den die Verbindung anschliessend noch verweist. Tencent (CVSS 8.5, CVSS v4.0) berichtet in 6 von 8 Testläufen vollen Root-Zugriff inkl. Container-Escape; diese Behauptung ist unabhängig noch nicht verifiziert, andere Quellen sehen bislang nur Kernel-Panic/DoS.

Sofortmaßnahme?

Kernel-Version prüfen und auf 7.1.6/6.18.42/6.12.101/6.6.148 (oder den distributionsspezifischen Backport) aktualisieren. Wo SCTP nicht benötigt wird — auf den meisten Container-/Kubernetes-Hosts der Fall — das sctp-Kernelmodul blacklisten; das entfernt die Angriffsfläche vollständig.

Empfehlung?

Trotz der ungeklärten Root-/Escape-Behauptung patchen bzw. mitigieren: Der unbestrittene Denial-of-Service-Impact allein rechtfertigt priorisiertes Handeln auf Multi-Tenant- und Kubernetes-/K3s-Hosts.

Kritikalität?

hoch (Hero-Badge) — CVSS 8.5, aber lokaler Angriffsvektor vorausgesetzt und Root-/Container-Escape-Behauptung unabhängig unbestätigt, daher nicht „kritisch“.

Was ist das Problem?

SCTP (Stream Control Transmission Protocol) ist ein Transportprotokoll neben TCP und UDP, das u. a. in Telekom-Signalisierung (SS7-/Diameter-Umfeld), manchen Kubernetes-CNI- und Multipath-Szenarien sowie generell überall dort zum Einsatz kommt, wo Multi-Homing und geordnete Nachrichtenzustellung gebraucht werden. Eine seiner Eigenschaften ist dynamische Adress-Rekonfiguration (ASCONF, RFC 5061): Eine laufende SCTP-Assoziation kann während ihrer Lebenszeit IP-Adressen hinzufügen oder entfernen, ohne die Verbindung neu aufzubauen — praktisch für Multi-Homing, aber ein komplexer Zustandsautomat im Kernel.

Genau in dieser Zustandsverwaltung sitzt der Fehler: Wenn der Kernel eine ASCONF-Delete-Anfrage verarbeitet, prüft er die Berechtigung anhand der Quelladresse des eingehenden Pakets — wählt den zu bearbeitenden Transportpfad aber anhand einer davon abweichenden Adresse, die im Nachrichtenkörper selbst enthalten ist. Eine gezielt konstruierte Sequenz kann dadurch einen Transportpfad freigeben (free), während die Assoziation weiterhin einen Zeiger darauf hält — ein klassisches Use-after-Free (CWE-416): Der Kernel arbeitet anschliessend mit bereits freigegebenem, potenziell neu belegtem Speicher.

Dass ein Fehler, der laut Tencent bis auf Kernel 2.6.25 (2008) zurückgeht, erst jetzt auffällt, hat weniger mit dem Alter des Codes zu tun als mit der Entdeckungsmethode: Tencents Zhuque Lab hat die Lücke nach eigenen Angaben mit einem KI-gestützten Analyse-Tool namens „Corvus AI“ gefunden — einem Werkzeug, das offenbar systematisch nach genau solchen Diskrepanzen zwischen Prüf- und Ausführungspfad in komplexem, seit Jahrzehnten gewachsenem Kernel-Code sucht. Das ist bemerkenswert, weil es zeigt, dass KI-gestützte Code-Analyse beginnt, Bugklassen zu finden, die klassisches Fuzzing und manuelle Audits über 18 Jahre lang übersehen haben.

Wer ist betroffen?

Die Tabelle zeigt die vier Kernel-Linien, in denen der Fix am 3. August 2026 veröffentlicht wurde. Wichtig: Viele Distributionen backporten Sicherheitsfixe, ohne die sichtbare Kernel-Versionsnummer entsprechend zu erhöhen — ein blosser Abgleich von uname -r gegen die vier Versionsnummern oben reicht deshalb nicht aus. Prüfen Sie stattdessen den Security-Tracker bzw. Changelog Ihrer Distribution.

Wer ist tatsächlich exponiert? Ausnutzung setzt laut bisherigen Berichten lokalen Zugriff auf das Zielsystem voraus, plus ein erreichbares bzw. aktiviertes SCTP — das ist explizit kein Remote-, kein unauthentifizierter Internet-Bug. Damit betrifft SCTPhantom in erster Linie: Multi-Tenant-Hosts, auf denen mehrere Kunden oder Teams denselben Kernel teilen; Kubernetes- und K3s-Nodes, auf denen fremde oder wenig vertrauenswürdige Workloads laufen (Shared Clusters, Plattform-Angebote, PaaS); CI/CD-Runner, die Fremdcode ausführen (Dependencies, PR-Branches); und generell jedes System, auf dem ein Angreifer bereits einen ersten Fuss in der Tür hat — etwa über eine kompromittierte Anwendung oder einen bösartigen Container. Reine Single-Tenant-Systeme mit vollständig vertrauenswürdigem Code sind dem geringsten Risiko ausgesetzt, aber angesichts des trivialen Mitigationsaufwands (Kernelmodul blacklisten) gibt es wenig Grund, das Risiko dort einzugehen.

Auswirkungen

Tencents Testergebnis — sechs von acht Versuchen mit vollem Root-Zugriff auf dem Host, ohne CAP_NET_ADMIN, CAP_SYS_ADMIN oder gelockertes Seccomp-Profil, getestet auf Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 und OpenCloudOS — wäre, sollte es sich bestätigen, ein vollwertiges Container-Escape-Primitiv: Ein einzelner kompromittierter Container oder Pod könnte die Isolation zum Host durchbrechen und potenziell alle anderen Workloads auf demselben Node kompromittieren — in Kubernetes-/K3s-Clustern also über einen einzigen bösartigen Pod hinaus wirken.

Diese Behauptung ist jedoch ausdrücklich unabhängig unbestätigt: Zum Zeitpunkt der Offenlegung lag keine Verifikation durch andere Sicherheitsforscher oder Hersteller vor, und andere Beobachter berichten bislang lediglich von Kernel-Panics bzw. Denial-of-Service als beobachtetem Effekt — nicht von erfolgreicher Rechteausweitung. Es ist plausibel, dass sich die Auswirkung je nach exakter Kernel-Konfiguration, Speicher-Allokator-Verhalten und Härtungsoptionen (z. B. KASLR, Slab-Härtung) unterscheidet, was erklären könnte, warum Tencent nicht in allen acht Versuchen erfolgreich war.

Unabhängig davon, wie sich die Root-/Escape-Frage klärt, bleibt der Denial-of-Service-Impact unbestritten: Ein Use-after-Free im Kernel-Netzwerkstack kann zuverlässig Kernel-Panics bzw. Systemabstürze auslösen — für produktive Multi-Tenant- oder Cluster-Umgebungen bereits für sich genommen ein ernstzunehmendes Verfügbarkeitsrisiko.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Ihr System einen SCTP-fähigen Kernel fährt und dabei fremde bzw. wenig vertrauenswürdige Workloads hostet — gemeinsam genutzte Kubernetes-/K3s-Nodes, CI-Runner, PaaS-Angebote.
• Mit Priorität prüfen, wenn … Ihre laufende Kernel-Version unterhalb der Fix-Versionen liegt und Sie den Backport-Status Ihrer Distribution nicht sicher kennen.
• Nur beobachten, wenn … das sctp-Kernelmodul bereits flottenweit geblacklistet bzw. nachweislich nicht geladen ist und der Kernel bereits auf oder über der Fix-Version liegt.

Schritt 1 — Prüfen, ob SCTP überhaupt aktiv ist

lsmod | grep sctp

Kein Treffer bedeutet nur, dass das Modul aktuell nicht geladen ist — ohne Blacklisting kann es trotzdem jederzeit on-demand nachgeladen werden, sobald ein Prozess einen SCTP-Socket öffnet.

Schritt 2 — Laufenden Kernel gegen die Fix-Versionen prüfen

# laufende Kernel-Version
uname -r
# Ziel: 7.1.6, 6.18.42, 6.12.101 oder 6.6.148 (bzw. neuer / entsprechender Distro-Backport)

# Debian/Ubuntu — installierte Kernel-Pakete
dpkg -l 'linux-image-*' | grep ^ii
apt list --installed 'linux-image-*' 2>/dev/null
# Changelog auf den CVE-Verweis prüfen
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i CVE-2026-64564

# RHEL/Rocky/AlmaLinux — installierte Kernel-Pakete
rpm -q kernel
dnf list installed kernel
# Changelog auf den CVE-Verweis prüfen
rpm -q --changelog kernel-$(uname -r) 2>/dev/null | grep -i CVE-2026-64564

Wichtig: Ein reiner Zahlenvergleich reicht wegen Distro-Backports nicht — prüfen Sie zusätzlich den Security-Tracker Ihrer Distribution.

Schritt 3 — sctp-Kernelmodul blacklisten (wenn nicht benötigt)

# aktives Modul entladen (nur falls geladen und nicht in Benutzung)
modprobe -r sctp

# Blacklist- und Install-Direktive setzen, damit es auch nicht
# on-demand nachgeladen wird
cat <<'EOF' > /etc/modprobe.d/blacklist-sctp.conf
blacklist sctp
install sctp /bin/false
EOF

# Wirksamkeit prüfen
lsmod | grep sctp
modprobe sctp; echo $?   # sollte fehlschlagen (Exit-Code ungleich 0)

Vorsicht: Nicht blindlings blacklisten, wenn ein Dienst tatsächlich SCTP benötigt (z. B. bestimmte Telekom-/Diameter-Workloads oder Multipath-Szenarien) — vorher prüfen, ob eine benutzte Anwendung davon abhängt.

Schritt 4 — Kubernetes/K3s: Kernel-Update sicher über die Node-Flotte rollen

# Kernel-Version je Node sichten
kubectl get nodes -o wide   # Spalte KERNEL-VERSION

# Node vor der Wartung sperren (keine neuen Pods mehr)
kubectl cordon <node>

# Node leeren — laufende Pods kontrolliert evakuieren
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data --grace-period=60

# Kernel-/Distro-Patch auf dem Node einspielen, anschliessend neu starten

# Node nach erfolgreichem Neustart wieder freigeben
kubectl uncordon <node>

--force ist immer die letzte Option — damit werden auch unverwaltete Pods hart gelöscht. Bei K3s gelten dieselben kubectl-Befehle gegen die K3s-API (bzw. k3s kubectl …); Node für Node vorgehen, nie die gesamte Node-Pool-Kapazität gleichzeitig aus dem Verkehr ziehen.

Optional — Seccomp als kompensierende Kontrolle

Für Workloads, die SCTP nachweislich nicht benötigen, lässt sich die Erstellung von AF_SCTP-Sockets (Adressfamilie 132 unter Linux) zusätzlich per Seccomp-Profil blockieren — als ergänzende, nicht ersetzende Schicht zum Standard-Seccomp-Profil der Container-Runtime:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [{ "index": 0, "value": 132, "op": "SCMP_CMP_EQ" }]
    }
  ]
}

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/block-af-sctp.json

Testen Sie ein solches Profil vor dem Rollout sorgfältig — ungetestete Syscall-Filter können Workloads unerwartet brechen.

Detection / Prüfung

Weder Tencent noch andere Quellen haben bislang öffentliche IOCs, Log-Signaturen oder ein spezifisches Erkennungswerkzeug für CVE-2026-64564 veröffentlicht — anders als bei Bugs mit aktiver Ausnutzung gibt es (Stand dieses Beitrags) keinen bekannten Exploit-Code und keine dokumentierten Angriffe, gegen die man gezielt suchen könnte. Die folgenden Prüfungen sind ein Ausgangspunkt, kein vollständiges forensisches Playbook.

Prüfen, ob SCTP aktiv ist

lsmod | grep sctp
cat /proc/net/sctp/assocs 2>/dev/null   # laufende SCTP-Assoziationen, falls vorhanden

Kernel-/Absturzprotokolle auf SCTP-Bezug prüfen

dmesg | grep -i sctp
journalctl -k | grep -i sctp
# Hinweise auf Use-after-Free (nur relevant bei KASAN/Kernel-Debug-Builds,
# in Produktion meist nicht aktiviert):
dmesg | grep -iE "use-after-free|KASAN"

Kernel-Paketversionen über die Flotte prüfen

# einfache Schleife als Ausgangspunkt — in der Praxis über Fleet-/Config-Management (Ansible, etc.)
for h in $(cat hosts.txt); do ssh "$h" 'uname -r'; done

Allgemeine Laufzeit-Indikatoren

Nicht SCTPhantom-spezifisch, aber ohnehin sinnvoll zu überwachen: unerwartete Root-Prozesse aus einem Container-Namespace heraus, ungewöhnliche Kernel-Panics/-Crashes auf Nodes mit aktiviertem SCTP, sowie Container-Prozesse mit Zugriff auf Host-Namespaces ausserhalb erwarteter Muster.

Betreiberempfehlung

Mid-Market

Prüfen Sie zunächst mit lsmod | grep sctp, ob SCTP auf Ihren Servern und Kubernetes-/K3s-Nodes überhaupt aktiv ist — in den meisten Fällen ist das Modul entweder gar nicht geladen oder wird nicht aktiv gebraucht. Blacklisten Sie es dort, wo es nicht benötigt wird; das ist in wenigen Minuten je Host erledigt und macht den Kernel-Patch selbst weniger dringend (aber nicht überflüssig — planen Sie ihn trotzdem für das nächste Wartungsfenster ein).

Enterprise

Inventarisieren Sie Kernel-Versionen über die gesamte Flotte, insbesondere auf gemeinsam genutzten Kubernetes-/K3s-Nodes, CI-Runnern und Multi-Tenant-Plattformen — genau dort ist die (umstrittene) Root-Behauptung am relevantesten, weil dort ein Angreifer realistisch bereits lokalen Zugriff über eine kompromittierte Workload hat. Rollen Sie das sctp-Blacklisting als Standard-Node-Härtung aus, wo SCTP nicht Teil des Betriebsmodells ist, und behandeln Sie den Kernel-Patch als reguläres, priorisiertes Patch-Fenster — unabhängig davon, ob sich die Container-Escape-Behauptung bestätigt, da der Denial-of-Service-Impact allein die Priorisierung rechtfertigt. Für Umgebungen mit echtem SCTP-Bedarf (z. B. Telekom-Signalisierung) ist Blacklisting keine Option — dort zählt der Kernel-Patch umso mehr.

Entscheidungsblock

• Patch sofort: Kernel auf 7.1.6/6.18.42/6.12.101/6.6.148 bzw. den distributionsspezifischen Fix aktualisieren, insbesondere auf Multi-Tenant- und Kubernetes-/K3s-Nodes.
• Kompensieren, wenn verzögert: sctp-Kernelmodul blacklisten, wo nicht benötigt; ergänzend Seccomp-Profil gegen AF_SCTP-Socket-Erstellung für Workloads ohne SCTP-Bedarf.
• Beobachten: Distributions-Tracker und NVD-Eintrag auf Score-/CWE-Vergabe sowie auf unabhängige Bestätigung (oder Widerlegung) der Root-/Container-Escape-Behauptung verfolgen.

Fazit

CVE-2026-64564 alias SCTPhantom ist in seinen unbestrittenen Fakten ein solider, patchbarer Kernel-Bug: eine 18 Jahre alte Use-after-Free-Lücke in der SCTP-ASCONF-Behandlung, mit vier klar benannten Fix-Versionen seit 3. August 2026 und einer trivialen, kostengünstigen Kompensationsmaßnahme für alle, die SCTP nicht brauchen — das sctp-Kernelmodul blacklisten. Unklar und ausdrücklich unbestätigt bleibt Tencents Behauptung, die Lücke erlaube in sechs von acht Fällen vollen Root-Zugriff samt Container-Escape; andere Beobachter sehen bislang nur Denial-of-Service. Für Betreiber ändert diese Unsicherheit wenig an der Handlungsempfehlung: Der DoS-Impact allein rechtfertigt priorisiertes Patchen auf Multi-Tenant- und Kubernetes-/K3s-Nodes, und das Blacklisting kostet praktisch nichts. Patchen bzw. mitigieren Sie unabhängig davon, wie sich der Streit um die Root-Behauptung auflöst.

Quellen

• The Hacker News — 18-Year-Old Linux SCTP Flaw Could Let Attackers Gain Root Access (07.08.2026)
• Tenable — CIS Debian Linux 12 Benchmark: 3.2.4 Ensure sctp kernel module is not available
• Red Hat Customer Portal — How do I prevent a kernel module from loading automatically?
• Plural — The kubectl drain node Command: A Complete Guide