Chrome 153 starts a two-week milestone cycle, but security fixes follow several clocks

Google has moved Chrome Stable to a two-week milestone cycle with the release of Chrome 153, accelerating one part of the browser’s update pipeline without replacing its separate security release mechanisms.

The change, which took effect on 8 September 2026, means major Chrome releases now arrive twice as often as they did under the previous four-week schedule. Google’s March announcement said the two-week cadence would apply to Chrome Stable and Beta across desktop, Android and iOS. Dev and Canary remain unchanged.

That faster rhythm can deliver features, performance improvements, bug fixes and security improvements sooner. It does not mean Chrome now waits two weeks between all security fixes, nor does it guarantee protection against attacks involving artificial intelligence.

Milestones are only one release clock

Chrome’s milestone number marks a major product release, but its security patch schedule already operated more frequently. Google introduced planned weekly security updates in 2023. Chromium documentation also says unscheduled releases can be issued for critical security issues, known in-the-wild exploitation and high-impact functional bugs.

Google is separately piloting two security releases per week. That experiment sits alongside weekly security updates and the new two-week milestone cycle, rather than forming part of a single replacement schedule.

The practical result is a patch system with several routes. A routine improvement may travel with a milestone, while some security fixes can arrive through weekly refreshes or an unscheduled release. Google has not published a comprehensive rule showing which vulnerabilities follow each route, and it has not announced whether its twice-weekly pilot will become permanent.

This distinction corrects the simplified idea that moving from four-week to two-week milestones automatically cuts every vulnerability’s delivery time from 28 days to 14. Some security updates were already reaching users outside the milestone cycle.

The patch gap continues after a fix is written

Faster releases address only part of the delay between repairing a vulnerability and protecting a browser. Google describes an N-day patch gap as the period after a security fix becomes visible in the public Chromium codebase but before the corrected release reaches users. During that period, the code change may provide clues that help attackers understand the underlying flaw.

Distribution is not the final step. Chrome can automatically download and stage new binaries in the background, but Google says an update is normally applied when the browser next restarts. Leaving Chrome running can therefore extend exposure even after the corrected build has reached a device.

Google has started addressing that application bottleneck in limited ways. Chrome 150 on macOS can restart automatically when all browser windows are closed and an update is waiting. Prompt relaunching therefore remains important when Chrome indicates that an update is ready.

A more ambitious approach remains experimental. Google is researching dynamic patching that would replace child processes, including renderers and the GPU process, without restarting the entire browser. Ben Mason of Google told ZDNET that the project is at an early stage. Google has not disclosed a launch date, supported platform list or evidence showing how much it would reduce exploitation.

Google reports more AI-assisted fixes, but attack claims remain uncertain

Google has increasingly linked its security strategy to AI-assisted vulnerability work. The company reported that Chrome 149 and 150 fixed 1,072 security bugs, more than the previous 23 milestones combined. It also said large language models now generate candidate fixes for most vulnerabilities.

Those vendor-reported figures indicate a sharp increase in discovery and remediation throughput. They do not show that Chrome suddenly became less secure, because the totals do not independently measure severity, exploitability or successful compromise.

Ben Mason of Google told ZDNET that security was the main driver of the faster cadence and that AI can accelerate both vulnerability detection and exploit generation. However, the available evidence does not establish a specific AI-led campaign against Chrome users or substantiate ZDNET’s claim that attackers are turning public fixes into working attacks within minutes.

Google’s public explanation has also evolved. Its 3 March announcement framed the shorter cycle broadly as a way to deliver smaller batches of features, fixes, performance changes and security improvements. Later statements placed greater emphasis on AI-driven patch volume and fast-moving security risks. The available record does not establish that malicious AI was the sole cause of the schedule change.

Enterprise and mobile differences remain

Organisations using the normal Stable channel now receive smaller milestones more frequently, which can change testing and deployment routines. The available material does not quantify the additional validation workload.

Chrome Extended Stable remains available on an eight-week milestone cycle. That does not mean participating organisations wait eight weeks for security repairs: Google says it continues to backport security fixes weekly. The channel separates a slower feature rhythm from a faster security rhythm.

Chrome on iOS has another important limitation. It uses Apple’s WebKit engine, so underlying WebKit security fixes arrive through iOS updates. Google can still issue Chrome-specific fixes or mitigations, but the new Chrome milestone schedule does not give it sole control over engine-level patch delivery on Apple devices.

The move also forms part of a wider browser release shift. Microsoft announced a two-week Stable cycle beginning with Edge 152, while Mozilla announced a two-week Firefox desktop and Android experiment starting in September 2026.

For Chrome users and administrators, the useful distinction is between producing a fix, distributing the corrected build and applying it. The new milestone cadence accelerates distribution for some changes, while weekly and urgent security releases handle others. Prompt relaunching and managed update compliance remain necessary because a staged update does not protect a running browser until it takes effect.

The gap between a browser fix being prepared and actually taking effect shows why update delivery is better understood as a process, not a single event. To examine the wider technical foundations for yourself, consider The Hack Academy’s online cybersecurity training programme, with self-paced learning and practical exercises alongside theory in cybersecurity fundamentals, networking and internet vulnerabilities.