Google hat Chrome 155 (Versionen 155.0.8059.39/.40 für Windows und macOS, 155.0.8059.39 für Linux) mit 247 Sicherheitslücken veröffentlicht – mehr als das Doppelte der vorherigen Desktop-Version (108 in Chrome 154). Über dies berichtete SecurityWeek am 7. Oktober 2026. Darunter befinden sich vier kritische Use-after-Free-Fehler:
- CVE-2026-106382 (Chromecast)
- CVE-2026-106197 (Browser)
- CVE-2026-106358 (Navigation)
- CVE-2026-106347 (Track)
Google gibt keine bekannten In-the-Wild-Exploits an, doch vier kritische Lücken – darunter mehrere, die möglicherweise die Sandbox-Grenzen betreffen – erfordern eine schnelle Aktualisierung der Flotte und einen Neustart.
Die Verteilung der CVE-Schweregrade liegt bei etwa 4 Kritisch, 53 Hoch, 122 Mittel und 68 Gering. Häufige Fehlerklassen sind:
- Falsche Autorisierung (41)
- Use-after-Free (34)
- Fehlende Autorisierung (34)
- UI-Fälschung (20)
- Informationsleak (17)
- Uninitialisierte Ressourcen (16)
Externe Forscher meldeten 62 der Bugs; Google zahlte für die bereits veröffentlichte Portion etwa 33.000 US-Dollar an Bug-Bounties, während die Beträge für fast 50 Meldungen noch ausstehen.
Ein bemerkenswerter Punkt: Die Forscherin Xinyang Ge (Anthropic) verfasste zahlreiche High/Critical-Berichte, und mehrere Credit Lines nennen „assisted by Claude“. Zwei der vier kritischen Berichte (Navigation und Track) wurden mit KI-Unterstützung erstellt. Das spiegelt eine breitere Tendenz wider, bei der KI-gestützte Sicherheitsforschung (Agentic AI Security) die Entdeckung von Schwachstellen beschleunigt – in derselben Woche dominieren LMCache- und Atlassian-Proof-of-Concepts die Nachrichtenlage.
Für Nutzer und IT: Das Update wird „über die kommenden Tage/Wochen“ ausgerollt, daher kann ein manueller Check über `chrome://settings/help` nötig sein. Bei verwalteten Flotten reicht das Herunterladen nicht aus – die Browser müssen neu gestartet werden. Edge und andere Chromium-basierte Browser folgen oft nach; führen Sie separate Inventuren durch. Selbst ohne gemeldete Wildabnutzung zeigt die Geschichte, dass Chrome-Criticals schnell zu Zielen werden, sobald Details bekannt werden.
Die Lieferung von 247 CVEs in einem einzigen Batch belastet auch die Patch-Kommunikation: Viele Organisationen priorisieren nur „Zero-Days in the Wild“. Hier fehlt zwar das Signal aus der Wildnis, aber die hohe Anzahl plus vier Kritischen UAFs – darunter Navigation/Browser – rechtfertigt es, Chrome 155 als verpflichtendes Sicherheitsfenster für dieselbe Woche zu behandeln. KI-gestützte Erkenntnisse verändern zudem die Zeitachse: Forscher können schneller mehr High- oder Kritische Probleme identifizieren, was häufige schnelle Updates wichtiger macht als vierteljährliche Neubauten von Images.
Für Forensik- und IR-Teams bleibt der Browser ein häufiger anfänglicher Angriffsvektor über Drive-by-Angriffe und schädliche Dokumente. Eine Flotte, die auf Version 154 feststeckt, nachdem 155 veröffentlicht wurde, hinterlässt unnötzige Angriffsflächen – gerade während Atlassian- und Lieferketten-Stories die gleiche Aufmerksamkeit des SOC beanspruchen. Koordinieren Sie die Browser-Patches mit anderen kritischen Maßnahmen, damit „nur Chrome“ nicht auf das Wochenende verschoben wird.
**Was IT- und Sicherheitsverantwortliche jetzt tun sollten**
Aktualisieren Sie Chrome auf ≥155.0.8059.39 (Windows/Mac auch .40) und überprüfen Sie den Neustart auf jedem Client. In Intune/GPO/Jamf: Überwachen Sie die Einhaltung und blockieren Sie ältere Builds. Prüfen Sie Chromium-basierte Nebenprodukte.
Priorisieren Sie Maschinen, die unvertrauenswürdige Seiten besuchen oder hohe Privilegien besitzen. Informieren Sie die Nutzer, den Browser vollständig zu beenden und neu zu öffnen – andernfalls bleiben kritische UAFs im Speicher. Fügen Sie eine wöchentliche Überprüfung hinzu: Anteil der Clients mit Version 155+ innerhalb von 72 Stunden.
Behandeln Sie einen fehlenden Neustart wie ein fehlendes Patch in der Compliance-Berichterstattung. Bestätigen Sie, dass die Automatische Aktualisierung für unmanaged Endpoints aktiviert ist, wo die Richtlinie dies erlaubt.
Setzen Sie eine 72-Stunden-SLA für kritische Browser-Patches in den SOC-Runbooks und folgen Sie den Ausreißer-OUs nach. Überprüfen Sie, dass auch Chromebooks und VDI-Pools denselben Build erhalten – nicht nur physische Windows-Clients.