Technik & Sicherheit · · 7 Min. Lesezeit · Von Alexander
Kritische Linux-TCP-Lücke: Was müssen Website-Betreiber jetzt tun?
CVE-2026-98432 betrifft die TCP-Verarbeitung im Linux-Kernel, dem Betriebssystemkern. Linux-CNA und Red Hat bewerten die Lücke nach CVSS 3.1 mit 9,8 von 10 Punkten als kritisch. Lassen Sie Ihren Hoster den korrigierten Paketstand und die Aktivierung im laufenden Kernel bestätigen. Recherchestand: 3. November 2026.
Was ist bei Linux passiert?
CVE-2026-98432 ist eine Use-after-free-Schwachstelle: Der Kernel kann Speicher für bestimmte IPv4-Optionen zu früh freigeben, während ein anderer Ablauf noch darauf zugreift. Betroffen ist der TCP-Verbindungsaufbau. Die Upstream-Korrektur stammt vom 5. Oktober 2026; der Linux-CNA-Datensatz wurde am 15. Oktober veröffentlicht und am 3. November aktualisiert.
Erforderlich sind ein erreichbarer, auf Verbindungen wartender IPv4-TCP-Dienst und speziell gestaltete SYN-Pakete mit IPv4-Record-Route- oder Timestamp-Optionen. Diese IP-Optionen sind keine gewöhnlichen TCP-Timestamps. Die Ausnutzung beruht auf konkurrierenden Verbindungs- und Wiederübertragungsabläufen. Eine Anmeldung, lokale Rechte oder ein Klick des Betreibers sind nicht erforderlich: Die Verarbeitung erfolgt im Kernel vor der Anwendungsauthentifizierung. Ein normaler Websitebesuch ist kein belegter Auslösemechanismus.
„StackWarp“ bezeichnet ein anderes Forschungsprojekt zu AMD-SEV-Virtualisierung und CVE-2025-29943. Verwenden Sie für die hier behandelte TCP-Lücke die Kennung CVE-2026-98432.
Wie gefährlich ist CVE-2026-98432 wirklich?
Mögliche Folgen sind Kernel-Absturz, Informationsabfluss und unter geeigneten Bedingungen fremder Code im Kernel-Kontext, also mit höchsten Systemrechten. Eine zuverlässige Remote-Code-Ausführung (RCE) setzt weitere Ausnutzungsbedingungen voraus. Die Bewertung 9,8 stammt von Linux-CNA und Red Hat. SUSE bewertet dieselbe CVE nach CVSS 3.1 mit 8,1 bei höher angesetzter Angriffskomplexität und zusätzlich nach CVSS 4.0 mit 9,2. Versionen und Bewertungsannahmen sind auseinanderzuhalten.
Anthropic dokumentierte am 27. Oktober eine erfolgreiche RCE mit Root-Rechten in einem Forschungsaufbau mit einem MPTCP-Listener. Die zugrunde liegende Lücke besteht laut Red Hat auch ohne MPTCP. Der Forschungsnachweis belegt keinen zuverlässigen Angriff auf jeden normalen Webserver. Auch ein Scan oder Angriffsversuch allein belegt keinen erfolgreichen Einbruch.
In den ausgewerteten Primärquellen ist zum 3. November 2026 keine aktive Ausnutzung belastbar bestätigt. Die CVE fehlt im geprüften CISA-Katalog bekanntermaßen ausgenutzter Schwachstellen, Version vom 30. Oktober 2026. Diese Befunde beweisen weder die Abwesenheit von Angriffen noch den Schutz Ihres Servers.
Welche Kernel-Versionen beheben diese Lücke?
Die folgende Liste nennt die ersten korrigierten Upstream-Versionen laut Linux-CNA. Sie lässt sich nicht direkt auf Distributionskernel übertragen: Hersteller können Korrekturen in Pakete mit älterer Basisversionsnummer übernehmen. Maßgeblich sind Produktzweig, vollständiger Paketstand und Hersteller-Advisory.
Red Hat veröffentlichte am 1. November korrigierte Pakete: für RHEL 8.10 `kernel-4.18.0-553.182.1.el8_10`, für RHEL 9.8 `kernel-5.14.0-687.64.1.el9_8` und für RHEL 10.2 `kernel-6.12.0-211.72.1.el10_2`. RHEL 7 ist laut Red Hat mangels verwundbaren Codes nicht betroffen; das besagt nichts über dessen allgemeinen Sicherheitszustand.
Debian bestätigt Sicherheitsupdates für Debian 12 (`linux`: `6.1.190-1`; `linux-6.12`: `6.12.113-1~deb12u1`) und Debian 13 (`linux`: erste Korrektur `6.12.113-1`). Für Ubuntu 22.04, 24.04 und 26.04 sind bei generischen Kerneln Zielpakete im Testkanal `-proposed` belegt, aber keine hier bestätigte allgemeine stabile Freigabe. Für Ubuntu 26.10 bleibt der Widerspruch zwischen Blog und neuerem Tracker offen. Lassen Sie den konkreten Paketnamen und Zweig prüfen.
- Upstream 5.10: korrigiert ab 5.10.272
- Upstream 5.15: korrigiert ab 5.15.223
- Upstream 6.1: korrigiert ab 6.1.190
- Upstream 6.6: korrigiert ab 6.6.159
- Upstream 6.12: korrigiert ab 6.12.113
- Upstream 6.18: korrigiert ab 6.18.56
- Upstream 7.2: korrigiert ab 7.2.10; Mainline-Korrektur in 7.3
Fehlende Nennung älterer Upstream-Reihen ist keine Entwarnung; deren Versorgung benötigt einen gesonderten Herstellernachweis. Cloud-, Echtzeit-, HWE-, FIPS- und andere Sonderkernel müssen separat geprüft werden.
Wie prüfen Sie, ob Ihre Website betroffen ist?
Entscheidend ist der Kernel unter der Website. AWS nennt ausdrücklich auch WordPress-, LAMP- und Plesk-Images als zu prüfende Fälle. Ein Versionscheck von WordPress, Plugins, nginx oder Apache ersetzt die Kernelprüfung nicht.
Bei Shared oder Managed Hosting bitten Sie den Anbieter, Betriebssystem und Wartungsstand zuzuordnen. Bei selbstverwalteten VPS oder Cloud-Servern müssen Sie beziehungsweise Ihr Administrator die Prüfung übernehmen. Docker-Container teilen den Hostkernel; ein neuer Container korrigiert ihn nicht. Virtuelle Maschinen haben eigene Kernel: Host und Gast sind gegebenenfalls getrennt zu prüfen.
Mit `uname -r` ermitteln Administratoren den laufenden Kernel. Dazu müssen sie den vollständigen Paketstand ermitteln: bei Debian/Ubuntu mit `dpkg-query`, bei RPM-Systemen mit `rpm -q`. Bei Debian hilft zusätzlich die Quellpaketversion beim Advisory-Abgleich. Bewahren Sie Distributionssuffix und Paketnamen auf; ein fehlender Pakettreffer ist keine Entwarnung. Ein installiertes Paket allein belegt keine aktive Korrektur.
Plesks Systemupdate-Funktion schließt Kernelpakete aus. „Aktuell“ im Panel genügt deshalb nicht. Auch cPanels allgemeiner Security Advisor ist kein CVE-spezifischer Nachweis. Beziehen Sie bei eingeschränkten Rechten den Anbieter ein.
Was müssen Sie Ihrem Hoster schreiben?
Ergänzen Sie Domain oder Kundennummer und senden Sie diese Anfrage:
„Guten Tag, ist der Linux-Kernel meines Hostings beziehungsweise Servers von CVE-2026-98432 betroffen? Bitte nennen Sie Distribution, Kernel-Zweig, vollständigen korrigierten Paketstand, tatsächlich laufenden Kernel und das passende Hersteller-Advisory. Ist die Korrektur durch Neustart oder einen für diese CVE passenden und geladenen Livepatch aktiv? Berücksichtigen Sie gegebenenfalls Virtualisierungshost, VM-Gast und Container-Hostkernel. Falls die Behebung aussteht: Welche vom Hersteller dokumentierte Zwischenmaßnahme ist aktiv, welche Einschränkungen hat sie, und wann erfolgen Update und erforderliches Wartungsfenster? Bitte antworten Sie mit Prüfdatum.“
Red Hat, SUSE, Canonical und AlmaLinux nennen für die beschriebenen Kernelupdates einen Neustart. Ein Livepatch wäre nur mit Nachweis für diese CVE und den laufenden Kernel eine Alternative. In der Recherche ist kein entsprechender Ubuntu-Livepatch- oder Red-Hat-kpatch-Nachweis bestätigt; ein grüner Dienststatus reicht nicht.
Was tun, wenn das Kernel-Update nicht sofort geht?
Das freigegebene Herstellerupdate hat Vorrang. Vereinbaren Sie ein Wartungsfenster. Lassen Sie das passende Paket installieren und nach dem erforderlichen Neustart den laufenden Kernel erneut prüfen und dem korrigierten Paket zuordnen.
Red Hat dokumentiert einen Filter gegen TCP-Verkehr mit IPv4-Optionen. Er verringert die Angriffsfläche, verhindert Angriffe aber ausdrücklich nicht vollständig. Netzwerk-Namensräume, Container und tatsächliche Paketpfade können die Wirkung begrenzen. Ein Administrator muss die Herstellerregel passend zur Umgebung testen; sie ersetzt kein Update. MPTCP allein abzuschalten genügt laut Canonical nicht.
Für Cloudflare oder eine Web Application Firewall (WAF) ist in den ausgewerteten Primärquellen kein umfassender Schutz gegen diese CVE belegt. Der Fehler betrifft die Netzwerk- und Kernel-Ebene. Sind weder Update noch wirksame Begrenzung der Erreichbarkeit möglich, bleibt vorübergehende Isolation oder Abschaltung als letzte, mit dem Betreiber abzustimmende Maßnahme.
Häufige Fragen zur Linux-TCP-Sicherheitslücke
Reichen aktuelle WordPress-Plugins aus?
Nein. Plugin-Updates belegen keinen korrigierten laufenden Kernel. Lassen Sie dessen Status für CVE-2026-98432 bestätigen.
Schützt Cloudflare Ihre Website?
Ein umfassender Schutz gegen diese CVE ist in den ausgewerteten Quellen nicht belegt. Lassen Sie den Kernel prüfen und bei Betroffenheit aktualisieren.
Betrifft die Lücke auch eine statische Website?
Wenn sie auf einem verwundbaren Linux-System mit erreichbarem IPv4-TCP-Dienst liegt, ist auch dort eine Kernelprüfung erforderlich. Die ausgelieferten Inhalte entscheiden nicht über die Betroffenheit.
Beweist CVSS 3.1 mit 9,8 einen Einbruch?
Nein. Der Wert beschreibt die technische Schwere unter Bewertungsannahmen. Forschungs-RCE und mögliche Ausnutzbarkeit belegen keinen Einbruch auf Ihrem Server.
Ist ein installierter neuer Kernel automatisch aktiv?
Nein. Bestätigen lassen müssen Sie die Aktivierung durch den erforderlichen Neustart oder einen nachweislich für diese CVE passenden, geladenen Livepatch.
Müssen Sie selbst Serverbefehle ausführen?
Bei Shared oder Managed Hosting senden Sie die Hoster-Anfrage. Bei selbstverwalteten Servern sollten Sie einen Administrator mit dem Abgleich von Paketstand, laufendem Kernel und Hersteller-Advisory beauftragen.