Chromes nächster Zero-Day geht nach Brüssel

Sechs Zero-Days in acht Monaten, ein Kopfgeld von tausend Dollar

Googles Chrome-Team veröffentlichte am 3. und 4. September 2026 die Builds 152.0.7977.82 und .83 für Windows und macOS sowie 152.0.7977.82 für Linux und behob damit CVE-2026-85046, einen Type-Confusion-Fehler in der V8-JavaScript- und WebAssembly-Engine, den Google als bereits aktiv ausgenutzt bestätigte. Der Fehler ermöglicht es einer präparierten Webseite, den Compiler von V8 dazu zu bringen, einem Angreifer beliebigen Lese- und Schreibzugriff auf den Heap des Browsers zu gewähren, was einen Weg zur Remotecodeausführung innerhalb der Chrome-Sandbox eröffnet. Der Forscher Salvatore Gulizia meldete den Fehler am 4. August 2026 und erhielt dafür ein Kopfgeld von 1.000 Dollar; Google hielt technische Details zurück, bis der Fix die meisten Nutzer erreicht hatte, ein Standardverfahren bei einem aktiv ausgenutzten Fehler. Dies ist der sechste aktiv ausgenutzte Chrome-Zero-Day, der 2026 gepatcht wurde, und jeder einzelne erreichte einen CVSS-Wert von 8,8 und erforderte einen Notfall-Patch außerhalb des regulären Chrome-Release-Zyklus.

Acht Tage, bevor die Uhr zu laufen begann

Googles eigener Zeitplan zeigt die entscheidende Lücke: Das Unternehmen deckte CVE-2026-85046 am 3. und 4. September auf und patchte es, acht Tage bevor die Durchsetzungsfrist des Artikels im EU Cyber Resilience Act beginnt, nach der genau ein Ereignis dieser Art formell hätte gemeldet werden müssen. Ab dem 11. September 2026 behandelt Artikel 14 Software wie Chrome als Produkt mit digitalen Elementen, und sobald ein Hersteller erfährt, dass eine Schwachstelle aktiv ausgenutzt wird, muss er innerhalb von 24 Stunden eine Frühwarnung an eine nationale Kontaktstelle und an ENISA, die Cybersicherheitsagentur der EU, senden, innerhalb von 72 Stunden eine ausführlichere Meldung und innerhalb von 14 Tagen nach Verfügbarkeit des Fixes einen Abschlussbericht. Hätte Google denselben Fehler am 12. statt am 3. September entdeckt und offengelegt, wäre dieselbe Abfolge - ein Forscher meldet einen V8-Fehler, Google bestätigt die Ausnutzung in freier Wildbahn und Google liefert einen Notfall-Patch - zum ersten echten Testfall des Cyber Resilience Act geworden statt zu einer Routinewarnung. Sechs ausgenutzte Chrome-Zero-Days innerhalb von acht Monaten im Jahr 2026 machen einen siebten, der nach Inkrafttreten der Zähne des Gesetzes eintrifft, zu einer Frage des Wann statt des Ob.

Die Entscheidungsregel für alle, die die Patch-Richtlinie verantworten

Die praktische Lehre für jedes EU-Unternehmen lautet nicht, auf eine behördliche Meldung zu warten, um vom nächsten Chrome-Zero-Day zu erfahren, denn Googles eigene Release-Notes besagten, dass die gepatchten Builds auch nach Existenz des Patches noch über die kommenden Tage und Wochen ausgerollt würden - das bedeutet, dass die Geschwindigkeit der automatischen Aktualisierung und nicht die Geschwindigkeit der Offenlegung darüber entscheidet, wie lange eine Flotte von Laptops exponiert bleibt. Wer auch immer die Endpoint-Richtlinie verantwortet, sollte den sechsten Zero-Day dieses Jahres als Grundrate behandeln, nicht als Anomalie: Bei sechs Vorfällen, die 2026 etwa alle sechs bis sieben Wochen auftraten, besteht die richtige Haltung in einem festen Prozess, der die installierten Chrome-Versionen wöchentlich mit dem aktuellen stabilen Build abgleicht, statt darauf zu vertrauen, dass sich jede Maschine planmäßig selbst aktualisiert. Sobald die Uhr des Cyber Resilience Act läuft, gewinnt ein IT-Team mit Sitz in der EU zudem ein neues Signal, das sich zu beobachten lohnt: Die ENISA-Meldehistorie eines Herstellers wird zu einem groben Indikator dafür, wie oft dessen Produkte tatsächlich aktiv angegriffen werden - konkreter als eine Marketingaussage über Enterprise-Grade-Sicherheit und es wert, vor einer Vertragsverlängerung geprüft zu werden, nicht erst nach einem Vorfall.

Weiterlesen: SonicWall SMA1000: Lücken werden jetzt ausgenutzt  |  EU-Sicherheitsteams Ohne Mitspracherecht Bei Astra