Chrome 153 Puts the Whole Web on a Two-Week Clock

Google shipped Chrome 153 on September 8, 2026, the first stable build on a two-week release cycle instead of four. The same drop covers desktop, Android, and iOS, with Chrome 154 due on September 22.

The faster clock shrinks the time between a public Chromium fix and a patched user, a gap AI-assisted attackers now work in days. Feature notes for 153 are thin. The load is the patch pipeline.

Chrome 153 Starts the Two-Week Clock

Ben Mason, a senior technical program manager, and Deepak Ravichandran, a distinguished engineer and senior director, laid out a two-week release cycle for Chrome 153 on March 3, 2026, and the September 8 stable drop is that plan landing. A new beta and a new stable now ship every two weeks. Dev and Canary do not change.

Each milestone is supposed to carry a smaller set of changes, which Google says makes breakage easier to isolate after a release. A Chrome Beta for each version still ships three weeks before stable, which is the window developers get to catch site-breaking shifts. Desktop, Android, and iOS moved together, so the same train now carries the Chrome work that halved Android scroll jank.

CHROME 153 AND 154 STABLE DATES

Under the old calendar, 153 would still have been two weeks away on September 8. Under the new one, 154 is already the next stop. Mason and Ravichandran also said Microsoft, Mozilla, and Brave are moving onto the same two-week standard, which is the part of the launch that reaches past Chrome users.

The N-Day Gap Inside Chromium’s Public Tree

Chromium is open source. Once a fix lands on the public main tree, anyone can diff it. The Chrome Security Team described the follow-on risk in a July 30, 2026 post: attackers reverse-engineer that commit and build an exploit before the patched binary reaches Stable, which is what most people actually run. Google calls those N-day attacks, and the wait is the patch gap.

Shrinking the window between landing a fix in the public codebase and delivering it to end users keeps the ‘N-day’ patch gap as small as possible, helping us protect against fast-moving threats.

Ben Mason, Senior Technical Program Manager, and Deepak Ravichandran, Distinguished Engineer, Chrome for Developers

Fixes for serious bugs already merge from main into the live Stable branch, and weekly security updates have been part of that path since 2023. Even then, the team said commits on main can take weeks to show up in Stable. In the same July post, Google said it is piloting two security releases per week because AI-powered attacks move faster than a weekly drop.

The public tree is also huge. Chrome carries more than 2,300 third-party dependencies across Chromium and satellite projects such as V8, BoringSSL, Skia, ANGLE, and Dawn, and about 1,700 of those ship to users. A fix in any of those libraries becomes a public signal the moment it hits the repo, which is why a shorter milestone clock is only half of the delivery problem.

1,072 Security Bugs in Two Chrome Releases

The two-week schedule is a reaction to volume. Google now runs Gemini-based agents over the Chrome tree, with a critic agent, test-writing agents, and a knowledge base of past CVEs and Git history. LLMs, the company said, now generate candidate fixes for most vulnerabilities. In May, that CI loop blocked over 20 bugs from reaching production, including a critical S1+ issue.

One find was a sandbox escape that let a compromised renderer trick the browser into reading local files, a bug Google said had sat in the codebase for more than 13 years. Human review missed it. The agent harness did not. That is the new shape of Chrome security work: machines proposing patches at a rate the old four-week train could not clear.

THE PATCH VOLUME GOOGLE IS NOW RACING

• Two milestones: Chrome 149 and 150 fixed 1,072 security bugs in two milestones, more than the prior 23 milestones combined.
• Report surge: By March 2026 the Chrome Vulnerability Reward Program was taking in more bug reports than it had in all of 2025.
• Old triage time: A single security report used to take 5 to 30 or more minutes of human triage before the new automated pipeline.
• Chrome 153 itself: The beta notes swap several XML parsing paths to a memory-safe Rust engine, a class of fix aimed at memory bugs rather than a user-facing feature.

Outside researchers still get paid through the VRP, but Google changed the rules so submissions have to add something the internal agents are not already finding, and so the reports fit the new automated intake. Higher patch volume, in Mason and Ravichandran’s words, is why a shorter release cycle makes security fixes simpler to manage. It is also why a four-week wait after a public commit is a worse bet than it was in 2021.

Why Enterprises Still Get an Eight-Week Channel

Google introduced Extended Stable in 2021 for IT admins and Chromium embedders who need more time to test. That channel still ships a new milestone every eight weeks. Weekly security fixes still land on it. Larger, riskier security work, including some architectural defenses, may not be backported, which is why Google keeps telling fleets that two-week Stable is the more secure choice.

Twice as many stables means twice as many restart prompts, twice as many extension and policy checks, and a test window that no longer looks like a month. Power users will see the update badge more often. Managed fleets that still batch browser changes on a monthly change Friday will fall behind the public tree on purpose. Extended Stable exists because Google knows that, and because it still wants those fleets on a supported channel rather than a pinned, stale build.

GOOGLE’S ADVICE FOR IT ADMINS

• RelaunchNotification: A policy that nags users to restart Chrome for a pending update, then forces the restart after a set time.
• Extended Stable: The eight-week feature channel for sensitive environments that must vet software changes, with security fixes still arriving in between.
• Enterprise dashboards: Chrome Enterprise Core or Premium, which track fleet versions and let admins steer updates by organizational unit.

Chromebooks still get extra platform testing before a new Chrome build rolls out, and Google said it is adapting those device channels to the two-week browser cycle. For Windows and Mac fleets, the choice is now blunt: take smaller drops every two weeks, or accept an eight-week feature lag and a longer N-day window on anything too sharp to backport.

Edge, Firefox, and WebView2 Inherit Chrome’s Clock

Microsoft did not wait for September. The Edge team moved Stable to two weeks with Edge 152 on August 27, 12 days before Chrome 153. Each Edge release is supposed to carry about half as much new content as a four-week drop, delivered twice as often. Edge Extended Stable stays on eight weeks and now lines up with every fourth Stable, versions such as 156, 160, and 164.

Because Edge is built on Chromium, Google’s tree sets the security clock Microsoft has to chase. A fix that is already public in Chrome and still unshipped in Edge is an open N-day on Edge users. The two-week move closes that lag to a maximum of 14 days in the milestone calendar, which is the same math Chrome is now using.

The quieter follow-on is the runtime inside other people’s apps. Microsoft said the WebView2 Runtime on a two-week cadence starts with version 153 in the week of September 10, after 152 closed out the four-week rhythm in the week of August 27. Evergreen WebView2 clients pick that up on their own. Apps that ship a Fixed Version runtime stay in control of when they update, and they fall behind on security the moment they pause.

WHO ELSE IS ON A TWO-WEEK CLOCK

Brave is on Google’s list of browsers adopting the two-week standard, without a public first-version date in Chrome’s own post. For Windows ISVs, WebView2 is the sharper change than Edge itself, because a payroll tool or an intranet wrapper now inherits Chromium’s security tempo whether the vendor wanted a browser roadmap or not.

Closed Mac Windows Now Restart Chrome Automatically

Shipping a build is not the same as applying it. Chrome has downloaded updates in the background since 2008, then waited for a restart. The Security Team said triage, fix, test, and release can now take one to two days, so the time a user leaves a patched binary sitting on disk is a large share of N-day risk.

People delay that restart because it kills tabs and because it is never the task in front of them. Google is working on dynamic patching that would replace child processes such as the renderer and GPU with new binaries without a full browser restart. That work is not the September 8 ship. Until it is, the company is hunting quieter moments to bounce the process.

Chrome 150 added one of those moments on macOS. If Chrome is still running with no windows open, which is common on a Mac after the red button closes the last window, a pending update now triggers an automatic restart. Session restore is supposed to make that bounce feel cheap. On Windows and Linux, the nag in the toolbar is still the main prompt, and enterprise RelaunchNotification is still the hammer.

A two-week milestone clock without a restart is just a file on disk. That is the part of the N-day problem Google cannot schedule away, and it is why the company is willing to bounce a windowless Mac copy of Chrome without asking.

Chrome’s Release Calendar Keeps Getting Shorter

Chrome has been cutting this interval for years. The company set a predictable release cadence in 2010, moved Stable to four weeks in 2021, added weekly security updates and an early-stable ring in 2023, and announced the two-week plan on March 3, 2026. September 8 is that sequence arriving in the default browser, not a one-off emergency drop.

CHROME’S RELEASE CADENCE

1. 2010: Chrome sets a predictable, rapid release cadence after years of slower browser trains.
2. 2021: Stable moves to a four-week milestone, and Extended Stable is added at eight weeks.
3. 2023: Weekly security updates and an early stable ring are added to cut the patch gap and catch regressions sooner.
4. March 3, 2026: Mason and Ravichandran announce that Chrome 153 on September 8 will start a two-week Stable cycle.
5. July 30, 2026: The Chrome Security Team says 149 and 150 fixed 1,072 security bugs and that it is piloting two security releases per week.
6. August 27, 2026: Edge 152 becomes the first major Chromium browser on a two-week Stable cycle.
7. September 1, 2026: Firefox 155 ships as Mozilla’s first two-week desktop and Android release.
8. September 8, 2026: Chrome 153 reaches Stable on desktop, Android, and iOS.

Mozilla is the odd one out in that list, because it does not ship Chromium. Sylvestre Ledru, Mozilla’s director of engineering, called the Firefox cadence experiment starting in September a trial, not a permanent rule, and said work that is not ready should not be rushed. Firefox 154 on August 18 was the last four-week desktop and Android release. Apple, which still ties a lot of Safari work to OS trains, said in June that it had sped security updates because AI tools can turn a bug into an exploit much faster than before.

Chrome 154 is scheduled for September 22, 2026. Google is still piloting two security releases a week on top of that milestone clock. Fleets that stay on Extended Stable will get feature drops later, and they will remain in the N-day window longer.