Chrome Switches to a Two-Week Update Cycle: With Security on the Clock

Google pushed Chrome 153 to the Stable channel on September 8, 2026, and with it switched the world's most-used browser from a four-week release cycle to a two-week one. The change, announced in March and activated this week, means a new Beta and a new Stable version every fortnight across desktop, Android and iOS. Chrome 154 is already in beta ahead of a Stable release pencilled in for September 22.

Related reading: Microsoft's Project Zenith Wants Windows to Be Ready-to-Code. Developers Aren't Convinced · React 19.3 Makes View Transitions Stable: Plus Fragment Refs and a First-Class browser() API.

The timing is not incidental. Google is framing the faster cadence as a security measure as much as a features one, and Chrome 153 makes the point bluntly: the release bundles 230 security fixes, five of them rated critical, and one zero-day that attackers were already exploiting. Faster releases, Google argues, mean a smaller window between a fix landing in public code and reaching users.

What actually changed

Chrome has shipped on a four-week milestone cycle since 2021, and on a six-week cycle before that. From Chrome 153 onward, the interval halves:

• A new Stable milestone every two weeks. Chrome 153 arrived on September 8; Chrome 154 is scheduled for September 22.
• A new Beta every two weeks as well. Beta builds now land about three weeks before the matching Stable release.
• Every platform. The two-week cadence covers desktop, Android and iOS.
• Dev and Canary are unchanged. Google kept its weekly Dev and daily Canary channels as they were.
• Smaller releases. Each milestone carries fewer changes, which Google says makes regressions easier to isolate.

The machinery behind the schedule is an "early stable" release: a candidate ships about a day after the branch is cut, so Google can watch for breakage before the full roll-out. Under the new calendar, Chrome 153 was cut for Stable on August 25 and reached users on September 8, a shorter stabilisation window than the old plan allowed.

The cadence, in plain terms

The phrase to understand is the "no-release week". It does not mean a week without patches. Since 2023, Chrome has run a separate weekly security channel that backports fixes to the current Stable version between milestones. A no-release week is simply a week in which the browser's version number does not move: no new features, no milestone, but still the regular security refresh.

Under the old monthly rhythm, a milestone landed roughly once every four weeks, leaving two quieter weeks in between. On a two-week cycle those gaps are gone: one week tends to bring a milestone, the next a security refresh or the start of the next Beta. For most users the practical effect is smaller, more frequent feature drops and more frequent "Relaunch to update" prompts. For enterprises, it means a version jump on managed devices twice as often.

Nothing about the change touches Chrome's update mechanics. Chrome still downloads updates in the background and applies them only after a restart, and Google still stages the roll-out over days rather than delivering it to every machine at once. On Chromebooks, the company has said new versions will continue to arrive after dedicated platform testing, with more detail promised for managed devices later.

Why Google says it is speeding up

Google's own explanation points at AI. "With automated AI discovery tools and community bug reports generating higher patch volume, shorter release cycles make managing security fixes significantly simpler," the Chrome team wrote. Shrinking the gap between a fix landing in the public Chromium codebase and reaching end users, the post continues, keeps the "N-day" patch gap as small as possible.

The N-day gap is a real problem, not a slogan. Once a patch appears in Chromium's public source tree, anyone watching the repository can study it and work backwards toward an exploit for the unpatched version. In principle, every day between a public fix and its delivery to users is a day an attacker can use. Google told TechCrunch that automated tools and community reports have pushed up patch volume, and Engadget reported that the effort leans on Gemini-powered tooling to find vulnerabilities faster.

The advisory for Chrome 153 shows the AI trend in black and white. Among the high-severity bugs credited are findings attributed to "Google BigSleep@Grape" and to "OpenAI Codex Security", two automated systems that are now filing the same reports human researchers do. There is also a competitive motive: faster releases let Chrome ship web-platform features ahead of rivals, and Google notes that Microsoft, Mozilla and Brave are all moving in the same direction.

A busy first release

Chrome 153 shows what the new cadence will look like in practice. The Stable channel advisory lists 230 security fixes, including five critical bugs, four memory-safety flaws in WebGL and one in the Cast component.

Only one of those made headlines: CVE-2026-87491, an out-of-bounds write in V8, Chrome's JavaScript and WebAssembly engine. Google rates it "medium", but the advisory adds the line that matters: "Google is aware that an exploit for CVE-2026-87491 exists in the wild." SecurityWeek counted it as the seventh actively exploited Chrome zero-day of 2026, and the US cybersecurity agency CISA added it to its Known Exploited Vulnerabilities catalogue on September 9, with a remediation deadline of September 23.

The patched builds are 153.0.8010.36/.37 for Windows and macOS and 153.0.8010.36 for Linux. Google says the update rolls out "over the coming days and weeks", and on Android it arrives through Google Play. Chrome on iOS is not affected by this particular flaw, according to the vendor.

Is the security gain as large as it sounds?

Not by itself. Chrome's weekly security channel (introduced with Chrome 116 in 2023) already delivered fixes on a seven-day rhythm. Halving the milestone interval from 28 days to 14 sits on top of a mechanism that was already running at half that. The largest reductions in Chrome's patch latency came in 2020 and 2023, not now.

The report dates in the Chrome 153 advisory underline the point. Many of the bugs patched on September 8 were reported in March, April and May 2026, months, not weeks, before they shipped. The time from discovery to delivery is dominated by triage, reproduction, fix development and review, and a faster release train only compresses the final segment of that chain. What the two-week cycle genuinely changes is the latency of fixes that ride a milestone, and the overall pace at which the browser as a product moves. It is a real improvement, but an incremental one layered on existing practice.

The trade-offs are also real. More frequent milestones mean more testing and more forced restarts, and smaller releases are not automatically safer. A faster train leaves less time to catch a bad build before it reaches everyone, which is why the early-stable step exists. Whether two weeks proves to be the right interval, or one that trades stability for velocity, is the experiment Google has just begun.

What it means for enterprises

Google's guidance is unusually direct. For enterprises and Chromium embedders, the company says the two-week Stable channel "becomes the most secure choice" and should be used by most organisations. Extended Stable remains for those that cannot absorb a release every fortnight.

Extended Stable is where the arithmetic gets uncomfortable. Its eight-week interval has not changed, but the number of milestones inside it has doubled: it now spans four Stable releases rather than two, with major feature updates arriving every eight weeks, Chrome 156, then Chrome 160. A fleet on Extended Stable can therefore sit up to three milestone versions behind Stable, where it once sat one.

Google says it continues to backport security fixes to Extended Stable weekly, which softens the risk. But its own Chromium release documentation notes that complex or risky fixes, and larger security features, may not be viable to backport and land only on the mainstream Stable channel. Extended Stable is offered on Windows and macOS; Linux fleets have no equivalent option and take the two-week cadence whether they want it or not.

The operational load also grows. Beta now ships every two weeks and reaches users about three weeks before Stable, so a team that validates against Beta faces roughly four test rounds inside a single eight-week Extended Stable cycle instead of two. The testing recommendation has not changed; the work behind it has doubled.

Seven years of acceleration

Chrome's release history is a steady compression of the interval between updates. In 2010 the team adopted a "release early, release often" philosophy. In 2021 it moved from six weeks to four. In 2023 it added weekly security updates and the early-stable release. The jump to two weeks in 2026 is the shortest milestone cycle the browser has ever run, and, at roughly 26 Stable releases a year instead of 13, it doubles the number of times IT has to touch managed machines.

What to watch

Three things will show whether the change delivers. The first is Chrome 154 on September 22: a smooth landing would validate the compressed schedule, while an early regression would reopen the argument about how fast is too fast. The second is whether the industry follows as Google predicts; Microsoft Edge moved to a two-week major cycle in late August, and Mozilla and Brave have signalled similar plans. The third is the enterprise documentation, which as of this week still described the old cadence in places.

For ordinary users the advice is simple and unchanged: keep Chrome updated, and restart it when asked. The browser is now on a faster clock, but the security fix that matters most in any given week still only counts once it has been installed.