CVE-2026-98432 und CVE-2026-106378: Fixes für Linux und Chrome

CVE-2026-98432 betrifft die IPv4-TCP-Verarbeitung des Linux-Kernels; CVE-2026-106378 betrifft die Sandbox von Chrome unter macOS vor Version 155.0.8059.39. Gleichen Sie Linux-Hosts mit dem Kernel-Sicherheitshinweis ihres Anbieters und Mac-Browser mit den Chrome-Update-Angaben ab. Prüfen Sie nach der Aktualisierung die aktive Version: Ein heruntergeladenes Update allein belegt bei keinem der beiden Produkte, dass die Korrektur bereits läuft.

Derek Ross warnte am 30. Oktober Server-, Node- und Relay-Betreiber vor dem Linux-Problem. PWN.AIs Beitrag vom 30. Oktober macht auf den separaten Ausbruch aus der GPU-Sandbox von Chrome aufmerksam. Für ein Startup-Team zählt jetzt, welche Rechner, Pakete und Browser-Installationen aktualisiert werden müssen.

Die Linux-CVE-Mitteilung stammt vom 15. Oktober; Googles Chrome-CVE-Eintrag wurde am 6. Oktober veröffentlicht. Die heutigen Beiträge lenken erneut Aufmerksamkeit auf bereits bekannte Schwachstellen und Korrekturen.

Stand: 30. Oktober 2026. Maßgeblich sind die unten verlinkten aktuellen Angaben der Anbieter. Die Verfügbarkeit von Paketen kann sich nach dieser Bestandsaufnahme ändern.

Was ist CVE-2026-98432, und ermöglicht die Schwachstelle eine Übernahme aus der Ferne?

Der bestätigte Fehler betrifft die Lebensdauer von Speicher während der Verarbeitung von TCP-Verbindungen. Nehmen Sie die Kernel-Schwachstelle ernst, trennen Sie aber Aussagen über eine zuverlässig mögliche Übernahme aus der Ferne vom dokumentierten Fehler.

Bei einem Use-after-free greift Code auf bereits freigegebenen Speicher zu. Hier können parallel ausgeführte Vorgänge noch IPv4-Socket-Optionen lesen, nachdem ein anderer Ausführungspfad sie freigegeben hat. Der Upstream-Patch ändert zwei Freigabepfade: Die Optionen werden erst nach Ablauf einer RCU-Schonfrist freigegeben. RCU steht für Read-Copy-Update. Der Kernel-Mechanismus lässt laufende Lesezugriffe enden, bevor der Speicher wiederverwendet wird.

Bei der Prüfung am 30. Oktober nennt Ubuntu einen CVSS-3.1-Wert von 9.8; Red Hats aktueller Sicherheitshinweis nennt vorläufig ebenfalls 9.8. Red Hat beschreibt mögliche Abstürze, Denial of Service oder Speicherbeschädigungen. Amazon Linux bewertet die Schwachstelle mit 8.1. Ordnen Sie jede Bewertung dem jeweiligen Anbieter und der verwendeten CVSS-Version zu. Ein Schweregrad belegt nicht, dass sich jede betroffene Installation zuverlässig übernehmen lässt.

Anthropics Forschungsbericht vom 27. Oktober beschreibt einen demonstrierten Exploit, der auf einem Linux-Server mit Multipath-TCP-Listener (MPTCP) Befehle als root ausführt, ohne Zugangsdaten oder Benutzerinteraktion. Das ist ein konkreter Nachweis von Codeausführung aus der Ferne unter einer benannten Konfiguration. Er belegt keine zuverlässige Ausnutzung auf jedem betroffenen Kernel und in jeder Installation.

Der Sicherheitshinweis des Go Security Teams vom 29. Oktober erklärt, warum solche Listener unerwartet vorhanden sein können: Seit Go 1.24 ist MPTCP für Linux-Listener standardmäßig aktiviert. Anwendung und Laufzeitkonfiguration können diese Vorgabe überschreiben. Das Team empfiehlt einen korrigierten Kernel und warnt: Das Deaktivieren von MPTCP unterbindet den demonstrierten Angriffspfad, behebt aber nicht den zugrunde liegenden IPv4-Fehler.

Halten Sie in Ihrer Vorfallsdokumentation drei Fragen auseinander: Ist der verwundbare Code vorhanden? Erreicht relevanter Netzwerkverkehr diesen Code? Welche Ausnutzung wurde für Ihre Umgebung nachgewiesen? Sie können Updates priorisieren, bevor alle Antworten vorliegen. Eine offene Frage belegt weder Sicherheit noch eine erfolgte Kompromittierung.

Welche Linux-Kernel-Versionen sind betroffen und korrigiert?

Upstream-Versionsnummern kennzeichnen Korrekturen in den Kernel-Entwicklungszweigen. Distributionspakete müssen Sie gesondert prüfen: Anbieter können einen Fix zurückportieren und dabei eine ältere Basisversion beibehalten.

Der aktuelle Linux-CNA-Eintrag führt den Fehler auf Linux 4.4 zurück und nennt diese ersten korrigierten Versionen, geprüft am 30. Oktober:

Verwenden Sie die neueste unterstützte Version des von Ihnen gepflegten Zweigs. Diese Grenzen gelten für Upstream-Zweige. Sie sind keine allgemeine Erkennungsregel für Ubuntu, Debian, RHEL oder ein Cloud-Image. Welche Distributionspakete die Korrektur enthalten, bestimmen die Sicherheitshinweise des Anbieters.

Ein Backport überträgt eine Korrektur auf einen weiterhin gepflegten älteren Codebestand. Deshalb kann ein Paket mit scheinbar niedrigerer Versionsnummer den Fix bereits enthalten. Ein rein numerischer Vergleich von uname -r mit einer Versionsnummer aus einem Social-Media-Beitrag kann einen Rechner falsch einstufen.

Erfassen Sie die vollständige Paketkennung: Distributionsversion, Kernel-Familie beziehungsweise Variante, Architektur und Paketrevision. Cloud-, Generic- und Hardware-Enablement-Kernel können innerhalb derselben Distribution unterschiedliche Aktualisierungspfade haben.

Laut Upstream-Beschreibung ist IPv6 vom ersten Fehler nicht betroffen. Gleichzeitig nennt sie ein verwandtes Problem bei der IPv6-Migration, das ein separater Patch beheben soll. Daraus folgt nicht, dass die Umstellung eines Dienstes auf IPv6 alle relevanten Kernel-Probleme beseitigt. Prüfen Sie den für Ihre Konfiguration geltenden Sicherheitshinweis.

Wie ist der Patch-Stand bei Ubuntu, Debian, RHEL und Cloud-Kerneln?

Der Stand der Behebung gilt jeweils für ein Produkt und eine Paketreihe. Die Tabelle hilft Ihnen, die passende Reihe zu finden. Sie belegt nicht den Zustand eines laufenden Hosts.

Quellen: Ubuntu-CVE-Tracker, Debian-Security-Tracker, Amazon-Linux-CVE-Tracker, Red-Hat-Sicherheitshinweis und Oracle-Linux-CVE-Verzeichnis.

Die Debian-Nummern sind hier Quellpaketversionen. Erwarten Sie diese Werte nicht unverändert in der Ausgabe von uname -r. Ubuntus Tracker enthält zahlreiche weitere Varianten. Die UEK-Errata von Oracle belegen nicht, dass jede Oracle-Kernel-Reihe korrigiert ist.

Fehlt Ihr genaues Paket in dieser Bestandsaufnahme, öffnen Sie den Tracker des Anbieters. Halten Sie den Status als unbekannt fest, bis Sie es zuordnen können. Dass ein Paket in einer kurzen Artikeltabelle fehlt, ist kein Sicherheitsnachweis.

Wie prüfen Sie, mit welchem Kernel Ihr Server tatsächlich läuft?

Ermitteln Sie zuerst Betriebssystem und laufende Kernel-Version. Ordnen Sie diese Angaben dann dem Paketeintrag des Anbieters zu.

Diese ausschließlich lesenden Befehle sind ein Ausgangspunkt auf einem Linux-Host:

cat /etc/os-release
uname -r

Speichern Sie die Ausgabe zusammen mit Host-Kennung und Prüfzeitpunkt. Führen Sie die Prüfung in der Umgebung aus, deren Kernel Sie ermitteln müssen, und klären Sie, wer für dessen Updates zuständig ist. Bei einem verwalteten Dienst brauchen Sie dafür gegebenenfalls eine Bestätigung des Anbieters statt Zugriff auf einen Paketmanager.

Ermitteln Sie anschließend mit den Paketwerkzeugen Ihrer Distribution die installierten Kernel-Pakete samt vollständiger Revision. Vergleichen Sie das passende Paket mit dem vom Anbieter genannten korrigierten Build. Ein erfolgreicher Lauf des Paketmanagers dokumentiert die Installation. Welcher Kernel aktiv ist, müssen Sie weiterhin feststellen.

Unterscheiden Sie diese Zustände:

Folgen Sie nach einem herkömmlichen Kernel-Update dem Neustartverfahren Ihres Anbieters und prüfen Sie die laufende Version erneut. Bei Live-Patching brauchen Sie einen ausdrücklichen Nachweis, dass der Anbieter diese CVE auf diesem Kernel abdeckt. Ein Live-Patching-Abonnement allein beantwortet die Frage nicht.

Übernehmen Sie diese Unterscheidung auch für Ersatzrechner. Prüfen Sie das Image oder die Vorlage für neue Hosts und anschließend eine neu gestartete Instanz. Sonst können die heutigen Server erfolgreich aktualisiert sein, während für den morgigen Ersatz kein Nachweis vorliegt.

Was können Sie tun, solange ein Anbieter-Fix aussteht?

Verringern Sie relevante Angriffsmöglichkeiten, legen Sie fest, wer die nächste Entscheidung trifft, und halten Sie den ungepatchten Zustand sichtbar. Übergangsmaßnahmen brauchen eine eigene Prüfung und einen Plan für ihre Aufhebung.

Beginnen Sie mit einer Bestandsaufnahme der Erreichbarkeit: Welche Hosts nehmen TCP-Verbindungen aus welchen Netzen und über welche Schutzmechanismen an? Erfassen Sie neben der öffentlichen Anwendung auch Verwaltungszugänge und Infrastrukturdienste. Ein Hostname allein beschreibt den Netzwerkpfad zum Rechner nicht.

Prüfen Sie, ob sich unnötige Dienste abschalten oder Zugriffe einschränken lassen, ohne den erforderlichen Betrieb zu stören. Beschreiben Sie das Ergebnis präzise: Welche Quellnetze erreichen weiterhin welchen Listener? Prüfen Sie dies von der jeweils relevanten Netzposition aus. Dokumentieren Sie die Maßnahme als Verringerung der Erreichbarkeit samt verbleibendem Risiko.

Laut Red-Hat-Sicherheitshinweis erfüllt derzeit keine Gegenmaßnahme die veröffentlichten Eignungskriterien. Das Linux-Kernel-CVE-Team empfiehlt ein Update auf eine unterstützte stabile Version und rät davon ab, einzelne Korrekturen herauszugreifen. Bevorzugen Sie den unterstützten Aktualisierungspfad Ihres Anbieters gegenüber einer selbst zusammengestellten Kernel-Änderung.

Die Warnung in den sozialen Medien erwähnt auch das Filtern von IPv4-Optionen und das Deaktivieren von Multipath TCP, kurz MPTCP. Der Go-Sicherheitshinweis bestätigt, warum Sie MPTCP-Listener prüfen sollten. Er warnt aber, dass eine Konfiguration für jedes einzelne Programm fehleranfällig ist und der zugrunde liegende Fehler nicht auf MPTCP beschränkt ist. Klären Sie vor einem Workaround, welchen Codepfad er betrifft, welcher Verkehr den Host weiterhin erreicht und ob Ihr Anbieter ihn für Ihre Konfiguration unterstützt.

Wenn Ihr Team Netzwerkschutzregeln ändert, sichern Sie den Zugang für die Wiederherstellung, testen Sie benötigte Verbindungen und dokumentieren Sie die Rücknahme. Eine kopierte Firewall-Regel kann Ihre bestehende Richtlinie und deren Abhängigkeiten nicht beurteilen. Lassen Sie die konkrete Änderung von der netzwerkverantwortlichen Person freigeben und ihre Wirkung prüfen.

Weisen Sie ausstehenden Fällen eine verantwortliche Person und einen Zeitpunkt für die nächste Prüfung der Sicherheitshinweise zu. Eskalieren Sie Entscheidungen, die Ausfallzeit, eine Anbieteraktion oder die befristete Akzeptanz eines Restrisikos erfordern. Unser Leitfaden zur Eskalation von Sicherheitskorrekturen erklärt, wie Sie diese Entscheidung ausdrücklich festhalten.

Was müssen Sie wegen Chrome-CVE-2026-106378 aktualisieren?

Aktualisieren Sie Chrome unter macOS auf die aktuelle unterstützte stabile Version und starten Sie den Browser neu. Googles CVE-Eintrag nennt Versionen vor 155.0.8059.39 als betroffen. Diese historische Versionsgrenze ist keine Empfehlung, auf einem alten Browserstand zu bleiben.

Google führte die Korrektur in seiner Chrome-155-Veröffentlichung vom 6. Oktober auf. PWN.AIs Beitrag vom 30. Oktober stellt eine spätere Untersuchung zu einer bereits veröffentlichten Korrektur vor.

In PWN.AIs Untersuchung konnte Code, der bereits im GPU-Prozess von Chrome lief, über den macOS WindowServer künstlich erzeugte Tastatureingaben senden. Die Demonstration öffnete Spotlight und startete die Rechner-App außerhalb der GPU-Sandbox. Die Forscher setzen ausdrücklich voraus, dass bereits nativer Code im GPU-Hilfsprozess ausgeführt wird. Ihr Test zeigt somit den Ausbruch aus der Sandbox; die anfängliche Kompromittierung des Browsers ist bereits vorausgesetzt.

Googles CVE-Beschreibung setzt einen bereits kompromittierten Renderer voraus und stuft das Problem nach Chromiums Schweregradsystem als Medium ein. Stellen Sie diese Anbieterbeschreibung dem konkreten Ausgangspunkt der Untersuchung im GPU-Prozess gegenüber. Weder die eine noch die andere Angabe rechtfertigt es, diesen einzelnen Fehler als vollständigen, überall funktionierenden Drive-by-Angriff zu beschreiben. Googles CVE-Eintrag.

Der Chromium-Fix betrifft geerbte Autorisierung im macOS-Datenschutzsystem TCC. Laut Beschreibung kann der direkte Start der ausführbaren Chromium-Datei durch einen anderen Prozess dessen Berechtigungen an Chromium und seine Kindprozesse weitergeben. Der GPU-Kindprozess sollte diese Autorisierung nicht erben. Für das beschriebene Verhalten sind der Startkontext und bereits vorhandene Berechtigungen relevant.

Benennen Sie eine für Browser-Updates verantwortliche Person und dokumentieren Sie die Nachweise:

Öffnen Sie in Chrome Hilfe → Über Google Chrome, lassen Sie das unterstützte Update abschließen und starten Sie den Browser neu, wenn Sie dazu aufgefordert werden. Prüfen Sie anschließend erneut die angezeigte Version. Googles Anleitung zum Aktualisieren von Chrome beschreibt das Vorgehen. Halten Sie die Browser-Prüfung vom Linux-Kernel-Update getrennt: Sie betreffen unterschiedliche Software und Aktivierungsschritte.

Welche Nachweise schließen die Behebung dieser CVEs ab?

Schließen Sie die Behebung für einen Host ab, wenn Sie dessen Kennung, passenden Fix, aktiven Kernel und Prüfergebnis zusammenführen können. Führen Sie Ausnahmen gesondert, damit ein abgeschlossener Update-Durchlauf keinen noch offenen Rechner verdeckt.

Füllen Sie für Chrome dieselben Felder aus: Mac, Browser-Installation, Sicherheitshinweis und Version nach dem Browser-Neustart. Ordnen Sie den Kernel-Neustart und den Browser-Neustart jeweils der passenden Aufgabe zu.

Verwenden Sie einen kurzen Eintrag wie diesen. Er ist eine Betriebsvorlage, keine Anbietervorgabe:

• Host und Zuständigkeit: beständige Maschinenkennung, Dienst, Umgebung und verantwortliche Person.
• Betroffenheit: Distribution, Kernel-Familie, vollständige Paketrevision und URL des Sicherheitshinweises.
• Maßnahme: Update oder freigegebene Übergangsmaßnahme samt Abschlusszeitpunkt.
• Aktivierung: laufende Version nach dem Neustart oder ausdrücklicher Nachweis einer unterstützten Live-Patch-Abdeckung.
• Verifikation: wer die Nachweise wann geprüft hat und ob die erforderlichen Dienste weiterhin ordnungsgemäß laufen.
• Offene Arbeit: zurückgestellte Hosts, Übergangsmaßnahmen, Ersatz-Images und nächster Prüfzeitpunkt.

Berichten Sie für eine Serverflotte auf Basis desselben Inventars über erledigte und offene Hosts. Die Aussage „Das Kernel-Update ist ausgebracht“ lässt zu viel Interpretationsspielraum. Nennen Sie die Rechner, auf denen der korrigierte Build läuft, die Rechner mit installiertem, aber inaktivem Fix und die weiterhin ausstehenden Rechner.

Nehmen wir eine hypothetische Anwendung mit drei Servern: Zwei starten mit dem korrigierten Kernel neu. Auf dem dritten ist das Paket installiert, doch das Wartungsfenster verstreicht ohne Neustart. Lassen Sie den Vorgang für diesen Rechner offen, benennen Sie die Zuständigkeit und legen Sie einen neuen Aktivierungszeitpunkt fest. Die Paketinstallation war erfolgreich. Derselbe Abschlussnachweis wie für die beiden anderen Hosts fehlt aber noch.

Hat ein Forscher die Angriffsfläche gemeldet, bestätigen Sie den Eingang und erklären Sie, was Sie geprüft haben, ohne unnötige Infrastrukturdetails offenzulegen. Unser Leitfaden zum Einrichten eines Programms zur Offenlegung von Schwachstellen beschreibt diesen Kommunikationsweg.

Häufige Fragen zu den Korrekturen für Linux und Chrome

Ist das Problem mit der Installation des neuesten Kernel-Pakets behoben?

Bestätigen Sie, dass das Paket die Korrektur des Anbieters enthält und der Host damit läuft. Befolgen Sie das unterstützte Neustart- oder Live-Patch-Verfahren und dokumentieren Sie anschließend den aktiven Zustand.

Ist jeder Server mit Amazon Linux 2023 gepatcht?

Aus dem Distributionsnamen allein folgt kein allgemeiner Befund. Im Stand vom 30. Oktober listet Amazons Tracker Fixes für kernel6.12 und kernel6.18, während die Standardreihe kernel weiterhin aussteht. Gleichen Sie die Paketfamilie Ihres Hosts mit dem aktuellen Amazon-Sicherheitshinweis ab.

Belegt eine scheinbar alte Kernel-Version die Verwundbarkeit?

Eine gepflegte Distribution kann einen Fix zurückportieren. Verwenden Sie die vollständige Paketrevision des Anbieters und die Zuordnung zum Sicherheitshinweis; prüfen Sie danach die Aktivierung. Ein alleiniger Vergleich mit der Upstream-Version reicht nicht aus.

Bedeutet die Warnung, dass mein Server kompromittiert wurde?

Die Schwachstellenwarnung gibt Anlass, die Erreichbarkeit zu prüfen und das Problem zu beheben. Für die Feststellung einer Kompromittierung brauchen Sie gesonderte Nachweise aus Ihrer Umgebung. Halten Sie Update-Maßnahmen und Vorfallsuntersuchung in Ihrer Dokumentation auseinander.

Belegt der Chrome-Ausbruch, dass eine Webseite jeden Mac übernehmen kann?

Die veröffentlichte GPU-Demonstration setzt voraus, dass bereits nativer Code ausgeführt wird. Auch Googles CVE-Beschreibung nennt eine vorherige Kompromittierung des Renderers. Aktualisieren Sie betroffene Browser und nennen Sie diese Voraussetzungen, wenn Sie die Untersuchung beschreiben.

Zuständigkeit und Verifikationsnachweise in Kit festhalten

Für eine klare Übergabe genügen wenige Angaben: eine verantwortliche Person, der passende Sicherheitshinweis, die Maßnahme und die geprüften Nachweise. Ihr Team untersucht und aktualisiert die Hosts. Die Falldokumentation macht die Entscheidung für die nächste zuständige Person nachvollziehbar.

Im CSIRT-Prozess von Kit können Sie eine Meldung zuweisen, Zuweisungs- und Statusverlauf festhalten und „Behoben“ von „Behebung verifiziert“ unterscheiden. Nach der Behebung können berechtigte Mitarbeitende die Korrektur als verifiziert markieren und eine optionale Notiz ergänzen. Diese kann auf Ihre Host-Nachweise verweisen. Der Statuswechsel selbst ist eine Bestätigung durch einen Menschen, kein automatisierter Kernel-Test.

Gehen Sie bei CVE-2026-98432 vom aktuellen Paketeintrag des Anbieters bis zum laufenden Kernel auf dem Host vor. Prüfen Sie bei CVE-2026-106378 die laufende Chrome-Version nach dem Browser-Neustart. Halten Sie ausstehende Rechner sichtbar, bis sie das jeweilige Abschlusskriterium erfüllen. Wenn Sie für die Bearbeitung von Schwachstellenmeldungen klare Zuständigkeiten und einen gemeinsamen Verifikationsverlauf brauchen, können Sie Kit ausprobieren.