Im Linux-Kernel liegt seit Januar 2016 ein Fehler, den ein Angreifer über das Netz und ohne Anmeldung auslösen kann. Es reicht ein erreichbarer TCP-Port mit IPv4. Die Kennung ist CVE-2026-98432, die Bewertung des Kernel-Sicherheitsteams liegt bei CVSS 9,8. Am 27. Oktober 2026 hat Anthropic gezeigt, dass sich darüber Befehle mit Root-Rechten ausführen lassen. Die Distributionen liefern Updates, aber nicht alle gleich schnell.

Für Server, die wir betreuen, gehören Kernel-Updates zur Administration. Ob diese Lücke auf einer konkreten Maschine schon geschlossen ist, hängt von der Distribution und davon ab, ob nach dem Update neu gestartet wurde. Wer das prüfen lassen möchte, erreicht uns über die Kontaktseite oder unter 0800 389 0 389.

Was passiert ist

Der Fehler sitzt in dem Teil des Kernels, der neue IPv4-TCP-Verbindungen annimmt. Trägt das erste Paket einer Verbindung, das SYN, bestimmte IP-Optionen wie Record Route oder Timestamp, merkt sich der Kernel diese Optionen in einem kleinen Speicherbereich. Kommt dasselbe SYN noch einmal, während die erste Anfrage gerade abgeschlossen oder verworfen wird, können zwei Prozessorkerne gleichzeitig auf diesen Bereich zugreifen: Einer gibt ihn frei, der andere liest noch. Das nennt sich Use-after-free. Im glimpflichen Fall stürzt der Server ab. Im schlimmen Fall schreibt der Angreifer in den Kernel-Speicher.

Eingebaut wurde der Fehler mit Linux 4.4. Betroffen sind damit die allermeisten Linux-Server der letzten zehn Jahre, außerdem Firewalls, NAS-Systeme und Hypervisoren, die auf einem Linux-Kernel laufen. IPv6-Verbindungen löst dieser Fehler nicht aus.

Gemeldet hat die Lücke Xinyang Ge von Anthropic. Die Korrektur von Eric Dumazet ging am 5. Oktober 2026 in den Kernel, die CVE-Nummer folgte am 15. Oktober, die Einstufung 9,8 am 24. Oktober. Abgesichert sind die stabilen Kernel 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3. Bei Debian, Ubuntu und Red Hat sagt die reine Versionsnummer aus uname -r oft wenig, weil die Korrektur zurückportiert wird. Maßgeblich ist das Sicherheitsbulletin der Distribution.

Warum die Lücke so ernst ist

Lange galt der Fehler vor allem als Absturzrisiko. Red Hat stufte ihn zuerst mit 5,9 als moderat ein, weil das Wettrennen der Prozessorkerne schwer zu gewinnen sei. Am 27. Oktober veröffentlichte Anthropic einen Bericht: Ein internes, nicht veröffentlichtes Modell hat einen funktionierenden Exploit gebaut. Der Angreifer wiederholt das Wettrennen, bis der Kernel ein paar Bytes zu viel zurückschickt. Steckt darin eine Kernel-Adresse, ist der Zufallsschutz KASLR ausgehebelt. Im Test dauerte das 48 Minuten. Danach überschreibt derselbe Fehler einen Funktionszeiger, und wenige Minuten später lief ein Befehl mit Root-Rechten. Ein misslungener Versuch bringt den Server nicht zum Absturz, der Angreifer kann also nachsetzen.

Den Exploit-Code hat Anthropic nicht veröffentlicht. Der Nachweis lief auf einem Server mit Multipath-TCP, kurz MPTCP. Das ist weniger exotisch, als es klingt: Seit Go 1.24 öffnen in Go geschriebene Dienste auf Linux standardmäßig einen MPTCP-fähigen Listener, ohne dass das jemand extra eingeschaltet hat. Viele Werkzeuge im Rechenzentrum sind in Go geschrieben. Der Fehler selbst liegt im normalen IPv4-TCP-Code. MPTCP abzuschalten schließt die Lücke nicht. Es erschwert nur den bisher gezeigten Weg zur Codeausführung.

Red Hat hat die Bewertung in zwei Schritten auf kritisch, 9,8, angehoben und am 30. Oktober die Mitteilung RHSB-2026-016 veröffentlicht. Angriffe in freier Wildbahn waren zum 31. Oktober nicht bekannt, die Lücke stand auch nicht im KEV-Katalog der US-Behörde CISA. Der Druck bleibt: Wo ein Modell innerhalb einer Stunde zum Ziel kommt, werden andere den Weg nachbauen.

Stand der Distributionen

Stand 31. Oktober 2026. Danach kann ein Paket schon im Repository liegen, das hier noch fehlt. Vor dem Update das Bulletin der eigenen Distribution lesen, nicht nur diese Liste.

• Debian: behoben. Debian 12 ab Kernel 6.1.190-1 (DLA-4841-1), Debian 13 ab 6.12.113-1 (DSA-6568-1).
• Ubuntu: zum Stichtag kein Update. Für 22.04, 24.04, 26.04 und 26.10 waren die Kernel in Arbeit, 20.04 und älter ohne Korrektur.
• Red Hat Enterprise Linux 8, 9 und 10: betroffen, Fix angekündigt, zum Stichtag nicht ausgeliefert. RHEL 7 ist wegen des älteren Kernels nicht betroffen.
• AlmaLinux 8, 9 und 10: gepatchte Kernel seit 30. Oktober im Testing-Repository.
• Rocky Linux: betroffen, zum Stichtag noch kein Kernel.
• SUSE: die meisten Versionen behoben, SLES 15 SP7 noch offen.
• Oracle Linux (UEK): seit 16. Oktober behoben.
• Amazon Linux 2023: kernel6.12 und kernel6.18 behoben, Standardkernel und Amazon Linux 2 offen.

Geräte mit fest eingebautem Linux, also viele Firewalls, NAS-Systeme und Telefonanlagen, bekommen den Fix nur über eine Firmware des Herstellers. Hypervisoren wie Proxmox VE laufen auf einem Linux-Kernel und gehören auf dieselbe Prüfliste.

Was Sie jetzt tun sollten

1. Kernel-Stand feststellen. uname -r zeigt, was gerade läuft. Entscheidend ist das Bulletin, nicht die Zahl allein.
2. Update einspielen und neu starten. Ein neuer Kernel gilt erst nach dem Neustart. Wer keine Ausfallzeit einplanen kann, prüft Live-Patching der Distribution, etwa Ubuntu Livepatch, kpatch oder KernelCare, sofern dafür schon ein Patch existiert.
3. Erreichbarkeit verkleinern. Dienste, die nicht aus dem Internet kommen müssen, hinter VPN oder Firewall legen. Das gilt besonders für Verwaltungsoberflächen und SSH. Ein geschlossener Port ist hier der schnellste Schutz, weil der Fehler einen offenen TCP-Port braucht.
4. Übergang, solange kein Kernel da ist. Red Hat, AlmaLinux und CIQ empfehlen eine nftables-Regel, die eingehende IPv4-TCP-Pakete mit IP-Optionen verwirft, also Pakete mit einem IP-Header länger als 20 Byte: ip protocol tcp ip hdrlength > 5 counter drop. Normaler Verkehr nutzt solche Optionen praktisch nie. Die Regel ist kein vollständiger Schutz, sie ersetzt das Update nicht, und ohne extra Aufwand übersteht sie keinen Neustart. Netze mit CIPSO-Labels und Verkehr zwischen Containern auf demselben Host sind Sonderfälle.
5. MPTCP prüfen. sysctl net.mptcp.enabled zeigt, ob Multipath TCP an ist. ss -lnMp listet offene MPTCP-Listener. Wird es nicht gebraucht, abschalten. Go-Dienste lassen sich mit der Umgebungsvariable GODEBUG=multipathtcp=0 auf klassisches TCP zurücksetzen. Das senkt das Risiko des bisher gezeigten Wegs und schließt die Lücke nicht.
6. Migration von Verbindungen. net.ipv4.tcp_migrate_req sollte auf 0 stehen. Das ist die Voreinstellung.
7. Nach dem Update aufräumen. Übergangsregel entfernen und die laufende Kernel-Version notieren, inklusive Neustart.

Wenn niemand im Haus den Kernel anfasst

Viele Betriebe haben Linux-Server, aber keinen Admin, der ein Kernel-Update gegen die Anwendungen testet. Genau diese Zwischenzeit haben wir in der Patchokalypse beschrieben: Die Lücke ist schneller öffentlich, als ein sauberer Test fertig ist. ServerGuard zeigt, welche Server ein betroffenes Paket noch laufen haben, und kann vorübergehende Schutzregeln setzen. Das ersetzt den neuen Kernel nicht.

Wer die Prüfung und das Einspielen nicht selbst machen will, beauftragt unsere Serveradministration. Wir sehen uns den Kernel-Stand an, spielen das verfügbare Update ein, stimmen den Neustart ab und setzen dort, wo die Distribution noch keinen Kernel liefert, die Übergangsregel. Abgerechnet wird in angefangenen 15 Minuten nach der gültigen Preisliste.

Klartext

CVE-2026-98432 ist kein theoretisches Absturzrisiko mehr. Ein offener IPv4-TCP-Port reicht, eine Anmeldung ist nicht nötig, und ein funktionierender Weg zu Root-Rechten ist nachgewiesen, auch wenn der Exploit-Code nicht öffentlich ist. Patchen und neu starten ist die Lösung. Alles davor kauft nur Zeit.

Quellen, Stand 31. Oktober 2026: CVE-2026-98432 (kernel.org), Anthropic, Discovering vulnerabilities with Claude (27. Oktober 2026), Red Hat RHSB-2026-016 (30. Oktober 2026), Debian Security Tracker, Ubuntu Security, AlmaLinux, CIQ zu Rocky Linux, Berichte von The Hacker News, BleepingComputer und TuxCare. Den tagesaktuellen Paketstand liefert das Bulletin der eigenen Distribution.