Im Linux-Kernel steckt seit zehn Jahren eine Lücke, die ein Angreifer aus der Ferne und ohne Anmeldung auslösen kann. Es genügt ein offener TCP-Port. Die Schwachstelle trägt die Kennung CVE-2026-98432, das Kernel-Sicherheitsteam bewertet sie mit CVSS 9,8 von 10. Am 27. Oktober 2026 hat Anthropic gezeigt, dass sich darüber Befehle mit Root-Rechten ausführen lassen. Seitdem bewegt sich bei den Distributionen einiges, aber nicht überall gleich schnell.

Für unsere Kunden vorab: Unsere eigenen Systeme und alle Linux-Server, die wir für Kunden verwalten, sind bereits auf dem abgesicherten Stand. Wer seine Linux-Systeme nicht von uns betreuen lässt, kann das Patchen trotzdem bei uns beauftragen. Wie das abläuft, steht am Ende des Beitrags.

Was ist passiert?

Der Fehler sitzt in dem Teil des Kernels, der neue IPv4-TCP-Verbindungen annimmt. Trägt das erste Paket einer Verbindung (SYN) bestimmte IP-Optionen, etwa Record Route oder Timestamp, legt der Kernel diese Optionen in einem kleinen Speicherbereich ab. Schickt der Angreifer dasselbe SYN noch einmal, während der Kernel die erste Anfrage gerade abschließt oder verwirft, können zwei Prozessorkerne gleichzeitig auf diesen Speicher zugreifen: Einer gibt ihn frei, der andere liest ihn noch. Fachleute nennen das Use-after-free. Im harmlosesten Fall stürzt der Server ab. Im schlimmsten Fall schreibt der Angreifer in den Kernel-Speicher.

Eingebaut wurde der Fehler im Januar 2016 mit Linux 4.4. Betroffen ist damit praktisch jeder Linux-Server, der seit zehn Jahren in Betrieb gegangen ist, ebenso Firewalls, NAS-Systeme und Hypervisoren mit Linux-Kernel. IPv6-Verbindungen sind von diesem Fehler nicht betroffen.

Gemeldet hat die Lücke der Anthropic-Forscher Xinyang Ge. Die Korrektur von Kernel-Entwickler Eric Dumazet wurde am 5. Oktober 2026 in den Kernel aufgenommen, die Kennung CVE-2026-98432 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.

Warum die Lücke so ernst ist

Lange galt der Fehler als Absturzrisiko. Red Hat stufte ihn zunächst mit 5,9 als „moderat“ ein, weil das Wettrennen zwischen den Prozessorkernen schwer zu gewinnen sei. Dann veröffentlichte Anthropic am 27. Oktober einen Bericht, nach dem ein internes, nicht veröffentlichtes KI-Modell einen funktionierenden Exploit gebaut hat. Der Ablauf in Kürze: Der Angreifer provoziert das Wettrennen so lange, bis der Kernel ihm versehentlich einige Bytes zu viel zurückschickt. Enthalten diese eine Kernel-Adresse, ist der Adressraum-Schutz KASLR ausgehebelt. Das dauerte im Test 48 Minuten. Danach überschreibt derselbe Fehler einen Funktionszeiger, und fünf Minuten später lief ein Befehl mit Root-Rechten. Ein verlorener Durchgang bringt den Server nicht zum Absturz, der Angreifer kann also beliebig oft nachsetzen.

Anthropic hat den Exploit-Code nicht veröffentlicht. Der Nachweis gelang auf einem Server mit einem Multipath-TCP-Listener (MPTCP). Das klingt exotisch, ist es aber nicht mehr: Seit Go 1.24 öffnen in Go geschriebene Dienste auf Linux standardmäßig MPTCP-fähige Listener, ohne dass Entwickler oder Betreiber davon wissen müssen. Viele Werkzeuge im Rechenzentrum sind in Go geschrieben. Wichtig ist aber: Der Fehler liegt im normalen IPv4-TCP-Code. Das Abschalten von MPTCP schließt die Lücke nicht, es erschwert nur den bisher gezeigten Weg zur Codeausführung.

Red Hat hat seine Bewertung inzwischen in zwei Schritten auf „kritisch“, 9,8 angehoben und am 30. Oktober eine eigene Sicherheitsmitteilung (RHSB-2026-016) veröffentlicht. Angriffe in freier Wildbahn sind bis Redaktionsschluss nicht bekannt, die Lücke steht auch noch nicht im KEV-Katalog der US-Behörde CISA. Der Druck ist trotzdem hoch, denn wo ein KI-Modell innerhalb einer Stunde zum Ziel kommt, werden es Angreifer auch schaffen.

Stand der Distributionen (31. Oktober 2026)

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

Für Geräte mit eingebautem Linux, etwa Firewalls, NAS oder Telefonanlagen, gilt wieder: Nur der Hersteller kann die Firmware liefern. Auch Hypervisoren wie Proxmox VE laufen auf einem Linux-Kernel und gehören auf die Prüfliste.

Was Sie jetzt tun sollten

  1. Kernel-Stand prüfen: uname -r zeigt den laufenden Kernel. Bei Debian, Ubuntu und Red Hat sagt die Versionsnummer allein wenig, weil die Korrektur zurückportiert wird. Maßgeblich ist das Sicherheitsbulletin der Distribution.
  2. Update einspielen und neu starten: Ein neuer Kernel wirkt erst nach dem Neustart. Wer keine Ausfallzeit will, nutzt Live-Patching wie Ubuntu Livepatch, kpatch oder KernelCare, sofern die Distribution dafür schon einen Patch liefert.
  3. Angriffsfläche verkleinern: Dienste, die nicht aus dem Internet erreichbar sein müssen, hinter VPN oder Firewall nehmen. Das gilt besonders für Verwaltungsoberflächen und SSH.
  4. Übergangsregel setzen, wenn noch kein Kernel da ist: Red Hat, AlmaLinux und CIQ empfehlen eine nftables-Regel, die eingehende IPv4-TCP-Pakete mit IP-Optionen verwirft, also alle 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 überlebt ohne Zusatzaufwand keinen Neustart. Netzwerke 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 aktiv 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 verringert das Risiko, schließt die Lücke aber nicht.
  6. Migrationspfad kontrollieren: net.ipv4.tcp_migrate_req sollte auf 0 stehen, das ist die Voreinstellung.
  7. Nach dem Update aufräumen: Übergangsregel entfernen, Kernel-Version dokumentieren.

Wir patchen auch Systeme, die wir nicht betreuen

Unsere eigenen Server und alle Linux-Systeme in unserer Betreuung sind bereits aktualisiert. Für Betriebe ohne eigenen Linux-Administrator übernehmen wir das Patchen auch einmalig: Wir prüfen den Kernel-Stand Ihrer Server, spielen die verfügbaren Updates ein, planen den Neustart mit Ihnen und richten dort, wo die Distribution noch keinen Kernel liefert, die Übergangsregel ein. Abgerechnet wird nach Aufwand zu 85 €* pro Stunde, in der Regel reicht eine Stunde pro Server. Wer das dauerhaft nicht mehr selbst im Blick behalten möchte, findet in unserer Server-Betreuung und der Betreuung für Virtualisierung feste Wartungsfenster und Überwachung zum Monatspreis.

Sie sind unsicher, ob Ihre Systeme betroffen sind?

Rufen Sie uns an unter 07724 82902-0 oder schreiben Sie uns über das Kontaktformular. Einen breiteren Blick auf Ihre IT gibt unser IT-Sicherheits-Check. Wie schnell aus einer bekannten Lücke ein Einbruch wird, haben wir zuletzt an PHP2Shell und Fragnesia beschrieben.

Quellen: CVE-2026-98432 (kernel.org CNA, 15.10.2026, Stand 31.10.2026) · Anthropic, Discovering vulnerabilities with Claude (27.10.2026) · Red Hat, Security Bulletin RHSB-2026-016 (30.10.2026) · Red Hat, CVE-2026-98432 · Debian Security Tracker · Ubuntu Security, CVE-2026-98432 · AlmaLinux, Patched kernels available in testing (30.10.2026) · CIQ, Mitigating CVE-2026-98432 on Rocky Linux (30.10.2026) · The Hacker News, 29./30.10.2026 · BleepingComputer, 30.10.2026 · TuxCare, Patch-Status und Mitigationen (30.10.2026)

* Alle Preise netto zzgl. der jeweils gültigen gesetzlichen Mehrwertsteuer.

KI-Hinweis: Dieser Beitrag wurde mit Unterstützung von KI verfasst und von der virtual gaps UG redaktionell geprüft.