Chrome wechselt auf einen Zwei-Wochen-Rhythmus

Chrome halbiert den Abstand zwischen seinen großen Releases. Google erklärt, es stelle um auf einen Zwei-Wochen-Rhythmus für große Chrome-Meilensteine, vorher vier Wochen, beginnend mit Chrome 153 am 8. September 2026. Als Grund nennt es, dass maschinelles Lernen Sicherheitslücken schneller findet, als ein Vier-Wochen-Zug die Korrekturen ausliefern kann.

Zwei Zahlen erklären die Entscheidung. Chrome 149 und 150 haben zusammen 1.072 Sicherheitslücken behoben. Das ist mehr als die Summe der vorherigen 23 Meilensteine.

Was sich ändert und was nicht

Die zwei Wochen gelten für große Meilensteine. Das sind die nummerierten Releases, die neue Funktionen bringen. Es ist nicht der Zeitplan für Sicherheitspatches, und dieser Unterschied geht leicht verloren.

Bereich	Zeitplan
Große Meilensteine	Alle zwei Wochen, ab Chrome 153
Sicherheitsupdates	Wöchentlich
Sicherheitsupdates (Pilot)	Zweimal pro Woche

"Wir stellen gerade auf einen Zwei-Wochen-Rhythmus für große Chrome-Meilensteine um, mit wöchentlichen Sicherheitsupdates", schrieb Googles Chrome-Sicherheitsteam. Getrennt davon testet es zwei Sicherheitsreleases pro Woche.

Die Änderung gilt für Desktop, iOS und Android. TechCrunch berichtet, dass Mozilla, Microsoft Edge und Brave bereits auf denselben Zwei-Wochen-Takt umgestellt haben.

Warum die Zahl der Fehler sprang

Das Sicherheitsteam benennt die Ursache direkt. Große Sprachmodelle sind die Software hinter Chatbots, und man kann sie auf Quellcode richten, um Schwachstellen zu suchen.

"Große Sprachmodelle (LLMs) erschließen bisher unerreichte Fähigkeiten zur automatisierten Entdeckung von Schwachstellen", schrieb das Team. Das gehe weit über die Grenzen menschlicher Sicherheitsexpertise hinaus und verlange neue Ansätze, um Angreifern voraus zu bleiben.

Das wirkt in beide Richtungen, und dieser Teil verdient Aufmerksamkeit. Dieselben Werkzeuge helfen Angreifern. Googles erklärtes Ziel ist es, die N-Day-Lücke zu verkleinern. Damit ist das Fenster gemeint zwischen dem Landen einer Korrektur im öffentlichen Code und ihrer Ankunft bei den Nutzern. Chromium ist Open Source, also ist jede veröffentlichte Korrektur auch eine öffentliche Beschreibung des Fehlers, den sie behebt.

Allein im Mai 2026 hätten automatisierte Systeme mehr als 20 Schwachstellen davon abgehalten, in die Produktion zu gelangen, so Google. Eine davon war als S1+ eingestuft, der schwersten Kategorie.

Was das für Entwickler bedeutet

Ihre Annahmen zum Testen brauchen einen Blick. Wenn Ihr Releaseprozess eine Chrome-Version festschreibt oder eine Browsermatrix durchläuft, bewegt sich diese Matrix nun doppelt so oft. Eine vierteljährliche Prüfung gegen "das aktuelle Chrome" ist nicht mehr dasselbe wie im August.

Für alles, was Sie nicht alle zwei Wochen neu qualifizieren können, verweist Google auf den Chrome Extended Stable Channel, den es für Unternehmen und sensible Umgebungen empfiehlt. Dieser Kanal tauscht Aktualität der Funktionen gegen einen langsameren, planbaren Zyklus. Für regulierte Installationen ist er die richtige Vorgabe.

Offen bleiben die Fristen für Abkündigungen. Keine der Quellen sagt, ob Entfernungen und Origin Trials ihre bisherige Zählung in Meilensteinen behalten. War eine Abkündigung in Meilensteinen statt in Daten geplant, ist ihr Kalenderdatum nun näher gerückt. Prüfen Sie daher alles, worauf Sie sich verlassen und was schon zur Entfernung markiert ist. Erweiterungsentwickler hatten diesen Monat bereits eine harte Frist, nachdem Google am 1. September alle Manifest-V2-Erweiterungen aus dem Chrome Web Store entfernt hat.

Lesen Sie die 1.072 nicht als Zeichen, dass Chrome unsicherer wird. Das passiert, wenn man automatisierte Suche auf eine große Codebasis richtet, und einen Fehler zu finden ist der Schritt vor dem Beheben. Die Zahl, auf die es ankommt, ist, wie schnell Patches die Nutzer erreichen, nicht wie viele Fehler gezählt werden.

Der größere Punkt für die Webplattform: Funktionen landen künftig in kleineren Schritten und häufiger im Stable. Das begünstigt Teams, die laufend testen, und benachteiligt lange manuelle QA-Zyklen. Google steht hier auch unter Wettbewerbsdruck, denn KI-gestützte Entwicklung habe die Kosten gesenkt, überhaupt einen Browser zu bauen.