Chrome wechselt zum Zwei-Wochen-Updatezyklus: mit der Sicherheit auf der Uhr

Google hat Chrome 153 am 8. September 2026 in den Stable-Kanal überführt und damit den meistgenutzten Browser der Welt von einem vierwöchigen auf einen zweiwöchigen Veröffentlichungszyklus umgestellt. Die Änderung, im März angekündigt und diese Woche aktiviert, bedeutet alle zwei Wochen eine neue Beta- und eine neue Stable-Version für Desktop, Android und iOS. Chrome 154 befindet sich bereits in der Beta und soll am 22. September als Stable erscheinen.

Zum Weiterlesen: Microsofts Project Zenith will Windows 'ready-to-code' machen. Entwickler sind nicht überzeugt · ServiceNows Aktie fiel um 27 Prozent, als die KI-Furcht die Softwareaktien erfasste.

Der Zeitpunkt ist kein Zufall. Google rahmt den schnelleren Takt ebenso als Sicherheitsmaßnahme wie als Funktionsoffensive, und Chrome 153 macht das unmissverständlich deutlich: Die Version bündelt 230 Sicherheitskorrekturen, fünf davon als kritisch eingestuft, sowie einen Zero-Day, den Angreifer bereits ausnutzten. Schnellere Veröffentlichungen, so das Argument, verkleinern das Zeitfenster zwischen einer im öffentlichen Code gelandeten Korrektur und ihrer Auslieferung an die Nutzer.

Was sich tatsächlich ändert

Chrome folgte seit 2021 einem vierwöchigen Meilenstein-Zyklus, davor einem sechswöchigen. Ab Chrome 153 halbiert sich das Intervall:

• Alle zwei Wochen ein neuer Stable-Meilenstein. Chrome 153 erschien am 8. September, Chrome 154 ist für den 22. September geplant.
• Auch alle zwei Wochen eine neue Beta. Beta-Builds landen nun rund drei Wochen vor der zugehörigen Stable-Version.
• Alle Plattformen. Der Zwei-Wochen-Takt gilt für Desktop, Android und iOS.
• Dev und Canary bleiben unverändert. Google behält den wöchentlichen Dev- und den täglichen Canary-Kanal bei.
• Kleinere Releases. Jeder Meilenstein enthält weniger Änderungen, was laut Google Regressionen leichter isolierbar macht.

Das dahinterliegende Verfahren ist eine „Early-Stable“-Veröffentlichung: Ein Kandidat erscheint etwa einen Tag nach dem Branch-Cut, damit Google vor dem breiten Roll-out nach Fehlern Ausschau halten kann. Nach dem neuen Kalender wurde Chrome 153 am 25. August für Stable geschnitten und erreichte die Nutzer am 8. September, ein kürzeres Stabilisierungsfenster, als der alte Plan erlaubte.

Der Takt, einfach erklärt

Der entscheidende Begriff ist die „ereignisfreie Woche“ (no-release week). Sie bedeutet nicht eine Woche ohne Patches. Seit 2023 betreibt Chrome einen separaten wöchentlichen Sicherheitskanal, der Korrekturen zwischen den Meilensteinen in die aktuelle Stable-Version zurückportiert. Eine ereignisfreie Woche ist schlicht eine Woche, in der sich die Versionsnummer des Browsers nicht bewegt: keine neuen Funktionen, kein Meilenstein, aber weiterhin das reguläre Sicherheits-Refresh.

Nach dem alten Monatsrhythmus erschien etwa alle vier Wochen ein Meilenstein, dazwischen lagen zwei ruhigere Wochen. Im Zwei-Wochen-Zyklus verschwinden diese Lücken: Eine Woche bringt tendenziell einen Meilenstein, die nächste ein Sicherheits-Refresh oder den Start der nächsten Beta. Für die meisten Nutzer bedeutet das kleinere, häufigere Funktionsaktualisierungen und häufigere Aufforderungen, zum Aktualisieren neu zu starten. Für Unternehmen bedeutet es einen Versionssprung auf verwalteten Geräten doppelt so oft.

Am Update-Mechanismus selbst ändert sich nichts. Chrome lädt Aktualisierungen weiterhin im Hintergrund herunter und wendet sie erst nach einem Neustart an, und Google verteilt den Roll-out weiterhin über Tage statt an alle Geräte gleichzeitig. Auf Chromebooks werden neue Versionen laut Unternehmen weiterhin erst nach dedizierten Plattformtests ausgeliefert; Details für verwaltete Geräte wurden für später angekündigt.

Warum Google das Tempo erhöht

Googles eigene Erklärung verweist auf KI. „Da automatisierte KI-Werkzeuge zur Entdeckung und Community-Fehlerberichte ein höheres Patch-Volumen erzeugen, machen kürzere Release-Zyklen die Verwaltung von Sicherheitskorrekturen deutlich einfacher“, schrieb das Chrome-Team. Die Verkürzung des Abstands zwischen einer im öffentlichen Chromium-Code landenden Korrektur und ihrer Auslieferung an die Endnutzer, so der Beitrag weiter, halte die „N-Day“-Patch-Lücke so klein wie möglich.

Die N-Day-Lücke ist ein reales Problem, kein Slogan. Sobald ein Patch im öffentlichen Quellbaum von Chromium auftaucht, kann ihn jeder, der das Repository beobachtet, studieren und daraus einen Exploit für die ungepatchte Version ableiten. Grundsätzlich gilt: Jeder Tag zwischen einer öffentlichen Korrektur und ihrer Auslieferung an die Nutzer ist ein Tag, den ein Angreifer nutzen kann. Google sagte gegenüber TechCrunch, dass automatisierte Werkzeuge und Community-Berichte das Patch-Volumen erhöht haben, und Engadget berichtete, dass die Bemühungen auf Gemini-gestützte Werkzeuge setzen, um Schwachstellen schneller zu finden.

Der Advisory zu Chrome 153 zeigt den KI-Trend in Schwarz auf Weiß. Unter den als hoch eingestuften Fehlern sind Funde, die „Google BigSleep@Grape“ und „OpenAI Codex Security“ zugeschrieben werden, zwei automatisierte Systeme, die inzwischen dieselben Berichte einreichen wie menschliche Forschende. Hinzu kommt ein Wettbewerbsmotiv: Schnellere Releases erlauben es Chrome, Webplattform-Funktionen vor der Konkurrenz auszuliefern, und Google merkt an, dass Microsoft, Mozilla und Brave sich in dieselbe Richtung bewegen.

Eine ereignisreiche erste Version

Chrome 153 zeigt, wie der neue Takt in der Praxis aussehen wird. Der Stable-Channel-Advisory listet 230 Sicherheitskorrekturen auf, darunter fünf kritische Fehler, vier Speichersicherheitsprobleme in WebGL und eines in der Cast-Komponente.

Nur einer davon machte Schlagzeilen: CVE-2026-87491, ein Out-of-Bounds-Write in V8, Chromes JavaScript- und WebAssembly-Engine. Google stuft ihn als mittelschwer ein, doch der Advisory enthält den entscheidenden Satz: „Google ist bekannt, dass ein Exploit für CVE-2026-87491 im Umlauf ist.“ SecurityWeek zählte ihn als siebten aktiv ausgenutzten Chrome-Zero-Day des Jahres 2026, und die US-Cybersicherheitsbehörde CISA nahm ihn am 9. September in ihren Katalog bekannter ausgenutzter Schwachstellen auf, mit einer Frist zur Behebung bis zum 23. September.

Die gepatchten Builds sind 153.0.8010.36/.37 für Windows und macOS und 153.0.8010.36 für Linux. Google zufolge rollt das Update über die kommenden Tage und Wochen aus, auf Android erscheint es im Google Play Store. Chrome unter iOS ist von dieser speziellen Schwachstelle laut Hersteller nicht betroffen.

Ist der Sicherheitsgewinn so groß, wie es klingt?

Nicht für sich genommen. Chromes wöchentlicher Sicherheitskanal (2023 mit Chrome 116 eingeführt) lieferte bereits Korrekturen im Sieben-Tage-Rhythmus. Die Halbierung des Meilenstein-Intervalls von 28 auf 14 Tage setzt auf einem Mechanismus auf, der schon mit der Hälfte lief. Die größten Verkürzungen der Patch-Latenz bei Chrome kamen 2020 und 2023, nicht jetzt.

Die Meldedaten im Advisory zu Chrome 153 unterstreichen das. Viele der am 8. September gepatchten Fehler wurden im März, April und Mai 2026 gemeldet, Monate, nicht Wochen, vor ihrer Auslieferung. Die Zeit von der Entdeckung bis zur Auslieferung wird von Triage, Reproduktion, Fix-Entwicklung und Review dominiert, und ein schnellerer Release-Zug komprimiert nur das letzte Segment dieser Kette. Was der Zwei-Wochen-Zyklus tatsächlich ändert, ist die Latenz von Korrekturen, die auf einem Meilenstein mitfahren, und das Gesamttempo, in dem sich der Browser als Produkt bewegt. Es ist eine echte Verbesserung, aber eine inkrementelle, die auf bestehender Praxis aufsetzt.

Auch die Kompromisse sind real. Häufigere Meilensteine bedeuten mehr Tests und mehr erzwungene Neustarts, und kleinere Releases sind nicht automatisch sicherer. Ein schnellerer Zug lässt weniger Zeit, einen schlechten Build zu erkennen, bevor er alle erreicht, genau deshalb gibt es den Early-Stable-Schritt. Ob zwei Wochen das richtige Intervall sind oder eines, das Stabilität gegen Geschwindigkeit tauscht, ist das Experiment, das Google gerade begonnen hat.

Was das für Unternehmen bedeutet

Googles Empfehlung ist ungewöhnlich direkt. Für Unternehmen und Chromium-Einbetter sei der Zwei-Wochen-Stable-Kanal die sicherste Wahl und solle von den meisten Organisationen genutzt werden. Extended Stable bleibt für jene, die nicht alle zwei Wochen ein Release verkraften.

Bei Extended Stable wird die Rechnung unangenehm. Das Acht-Wochen-Intervall hat sich nicht geändert, doch die Zahl der darin enthaltenen Meilensteine hat sich verdoppelt: Es umfasst nun vier Stable-Releases statt zwei, wobei größere Funktionsupdates alle acht Wochen erscheinen, Chrome 156, dann Chrome 160. Eine Flotte auf Extended Stable kann damit bis zu drei Meilensteinversionen hinter Stable liegen, wo sie früher um eine zurücklag.

Google zufolge werden Sicherheitskorrekturen weiterhin wöchentlich nach Extended Stable zurückportiert, was das Risiko mildert. Die eigene Chromium-Release-Dokumentation weist jedoch darauf hin, dass komplexe oder riskante Korrekturen und größere Sicherheitsfunktionen möglicherweise nicht portierbar sind und nur im regulären Stable-Kanal landen. Extended Stable gibt es für Windows und macOS; Linux-Flotten haben keine entsprechende Option und erhalten den Zwei-Wochen-Takt, ob sie wollen oder nicht.

Auch die operative Last wächst. Beta erscheint nun alle zwei Wochen und erreicht die Nutzer etwa drei Wochen vor Stable, sodass ein Team, das gegen Beta validiert, innerhalb eines einzigen achtwöchigen Extended-Stable-Zyklus statt zwei nun rund vier Testrunden absolviert. Die Testempfehlung hat sich nicht geändert; der Aufwand dahinter hat sich verdoppelt.

Sieben Jahre Beschleunigung

Chromes Veröffentlichungshistorie ist eine stetige Verdichtung des Abstands zwischen Updates. 2010 übernahm das Team die Philosophie „früh veröffentlichen, oft veröffentlichen“. 2021 wechselte es von sechs auf vier Wochen. 2023 kamen wöchentliche Sicherheitsupdates und die Early-Stable-Veröffentlichung hinzu. Der Sprung auf zwei Wochen im Jahr 2026 ist der kürzeste Meilenstein-Zyklus, den der Browser je gefahren hat, und mit rund 26 Stable-Releases pro Jahr statt 13 verdoppelt er die Zahl der Male, die die IT verwaltete Rechner anfassen muss.

Was zu beobachten ist

Drei Dinge werden zeigen, ob die Änderung liefert. Erstens Chrome 154 am 22. September: Eine reibungslose Landung würde den verdichteten Zeitplan bestätigen, eine frühe Regression die Debatte darüber neu entfachen, wie schnell zu schnell ist. Zweitens, ob die Branche wie von Google vorhergesagt folgt; Microsoft Edge wechselte Ende August auf einen zweiwöchigen Hauptzyklus, und Mozilla und Brave haben ähnliche Pläne signalisiert. Drittens die Unternehmensdokumentation, die diese Woche stellenweise noch den alten Takt beschrieb.

Für normale Nutzer ist der Rat einfach und unverändert: Chrome aktuell halten und bei Aufforderung neu starten. Der Browser läuft nun auf einer schnelleren Uhr, aber die wichtigste Sicherheitskorrektur einer jeden Woche zählt erst, wenn sie installiert ist.