Linux-Kernel-Lücke CVE-2026-98432: Updates einplanen, Neustart nicht vergessen

Seit Mitte Oktober ist eine Schwachstelle im TCP-Netzwerkstack des Linux-Kernels bekannt, die sich aus der Ferne und ohne Anmeldung ansprechen lässt. Inzwischen liefern die ersten Linux-Distributionen korrigierte Kernel aus, andere – darunter Ubuntu für seine Langzeitversionen – stecken noch in der Abschlussprüfung. Für Unternehmen ist jetzt der richtige Zeitpunkt, betroffene Systeme zu erfassen, Updates einzuplanen und den nötigen Neustart fest in den Wartungsplan aufzunehmen.

Worum es geht

CVE-2026-98432 betrifft die Verarbeitung eingehender IPv4-TCP-Verbindungsanfragen. Trifft eine wiederholte Verbindungsanfrage zeitgleich auf den Abschluss des Verbindungsaufbaus, kann der Kernel auf bereits freigegebenen Speicher zugreifen – ein sogenannter Use-after-free. Ausgelöst wird der Fehler über Verbindungsanfragen mit IPv4-Optionen. Laut Red Hat kann ein nicht angemeldeter Angreifer über das Netzwerk einen Systemabsturz, Speicherkorruption oder im ungünstigsten Fall die Ausführung von Code verursachen. Eine Mitwirkung von Nutzern ist nicht nötig, allerdings verlangt der Angriff ein präzises Timing der Netzwerkanfragen.

Laut Akamai steckt der Fehler seit Kernel-Version 4.4 im Code. Betroffen ist damit praktisch jedes Linux-System, das Dienste über IPv4-TCP anbietet: klassische Server, virtuelle Maschinen in der Cloud oder im Rechenzentrum, Container-Hosts, aber auch Geräte, bei denen man Linux nicht sofort vor Augen hat – Firewalls und andere Appliances, NAS-Systeme oder Thin Clients. Das CERT-Bund des BSI hat in seine Sicherheitswarnung inzwischen Hinweise mehrerer Hersteller solcher Produkte aufgenommen, darunter IGEL, Citrix und Google.

Behoben ist die Lücke in den gepflegten Kernel-Zweigen 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 und 7.2.10. In der Praxis zählt aber das Kernel-Paket Ihrer Distribution beziehungsweise das Firmware-Update des Geräteherstellers; deren Versionsnummern weichen von diesen Angaben ab.

Wie ist die Lage einzuordnen?

Das CERT-Bund des BSI stuft die Schwachstellen in seiner Warnung WID-SEC-W-2026-4008 („Linux Kernel: Mehrere Schwachstellen“) als „hoch“ ein. Die Hersteller und die Cybersicherheitsagentur Baden-Württemberg bewerten strenger: Red Hat und Ubuntu führen die Lücke als „Critical“ mit einem CVSS-Wert von 9.8, die CSBW spricht von einer kritischen Sicherheitslücke, ebenfalls mit CVSS 9.8.

Eine aktive Ausnutzung ist bislang nicht bestätigt. Die US-Behörde CISA führt CVE-2026-98432 nicht in ihrem Katalog bekannter, ausgenutzter Schwachstellen (Stand 05.11.2026). Nach Angaben von Akamai hat der Sicherheitsforscher, der die Lücke gemeldet hat, zwar einen funktionierenden Angriff beschrieben, ihn aber nicht veröffentlicht; ein öffentlich verfügbarer Exploit ist nicht bekannt.

Beim Stand der Updates gibt es Unterschiede. Red Hat, SUSE, Debian und Oracle Linux haben für mehrere Versionen bereits korrigierte Kernel bereitgestellt. Ubuntu bietet die Korrekturen für 22.04, 24.04 und 26.04 derzeit nur im freiwilligen Testkanal „-proposed“ an; im regulären Security-Kanal sind sie noch nicht freigegeben (Stand 05.11.2026). Für Ubuntu 20.04 und ältere Versionen nennt Ubuntu noch keinen Fix.

Unsere Einordnung: Die BSI-Einstufung „hoch“ ist kein Grund zur Entwarnung. Die Lücke ist ohne Anmeldung aus dem Netz erreichbar und betrifft eine sehr breite Basis an Systemen. Gleichzeitig gibt es keinen Anlass für überstürzte Eingriffe am Produktivsystem. Sinnvoll ist ein geordnetes, aber zügiges Vorgehen – beginnend mit den Systemen, die aus dem Internet erreichbar sind.

Was Sie jetzt konkret tun können

1. Bestand erfassen. Listen Sie alle Linux-Systeme auf: Server, virtuelle Maschinen, Container-Hosts und Testsysteme. Beziehen Sie Appliances, Firewalls, NAS-Systeme und Thin Clients ein, und verfolgen Sie dort die Sicherheitshinweise der Hersteller. Priorisieren Sie Systeme, die aus dem Internet erreichbar sind.
2. Kernel-Updates einspielen und neu starten. Installieren Sie die korrigierten Kernel-Pakete Ihrer Distribution, sobald sie im regulären Update-Kanal verfügbar sind. Ein neuer Kernel wirkt erst nach einem Neustart oder, wo vorhanden, über ein Live-Patching-Verfahren. Planen Sie dafür ein Wartungsfenster ein.
3. Bei Ubuntu bewusst entscheiden. Der Kanal „-proposed“ dient der Erprobung und ist nicht für den ungeprüften Produktiveinsatz gedacht. Nutzen Sie ihn nur nach eigener Abnahme auf einem Testsystem – oder warten Sie auf die reguläre Freigabe und prüfen Sie den Stand in den nächsten Tagen regelmäßig.
4. Zwischenlösung mit Bedacht einsetzen. Ubuntu und Red Hat beschreiben eine Filterregel mit nftables, die eingehende IPv4-TCP-Pakete mit IP-Optionen verwirft. Sie senkt das Risiko, verhindert eine Ausnutzung laut Ubuntu aber nicht vollständig und kann Anwendungen stören, die auf IP-Optionen angewiesen sind. Das Abschalten von Multipath-TCP (MPTCP) wird ebenfalls empfohlen, ersetzt den Patch aber ausdrücklich nicht. Wer Netzwerkzugriffe betreut absichern lassen möchte, findet in Society Ocean Pier betreute Netzwerksicherheit und Firewall.
5. Altsysteme abschotten oder ablösen. Systeme, für die kein Fix in Sicht ist, etwa nicht mehr unterstützte Distributionsversionen, sollten vom Internet getrennt, auf das Nötigste beschränkt und zeitnah ersetzt werden.
6. Nach dem Neustart kontrollieren. Prüfen Sie, ob tatsächlich der aktualisierte Kernel läuft, zum Beispiel mit uname -r, und gleichen Sie die Version mit dem Sicherheitshinweis Ihrer Distribution ab. Ein installiertes, aber nicht aktives Update schützt nicht.

Lehren für den Regelbetrieb

Aus unserer Sicht zeigt dieser Fall erneut, wie wichtig zwei Dinge sind: ein vollständiges Verzeichnis aller Systeme, auf denen Linux läuft – auch in Geräten –, und ein eingeübter Ablauf für Kernel-Updates mit Neustart. Gerade Neustarts werden bei Servern gern verschoben, weil Dienste kurz ausfallen. Wer feste Wartungsfenster und eine Reihenfolge für abhängige Systeme vereinbart hat, kann auch kurzfristige Updates ohne Hektik umsetzen.

Wenn Sie dabei Unterstützung suchen: Server-Support und Linux-Kernel-Updates bedient Society Solutions im Rahmen der Spezialisten-Services (Managed Services). Die Betreuung von Servern und Systemen finden Sie im IT-Service-Portfolio. Wer eigene Linux-VMs in Society Ocean Habitat betreibt, kann Update-Planung und Wartungsfenster gern mit uns abstimmen. Für betreute Netzwerksicherheit und Firewall steht Society Ocean Pier bereit. Für die organisatorische Seite – Risikobewertung und Vorbereitung auf den Ernstfall – gibt es im ISM-Code die Bereiche Sicherheitsanalysen und Notfallmanagement. Was zu Ihrer Umgebung passt, klären wir am besten in einem Gespräch über Ihre Ausgangslage.