Google moves Chrome to a 2‑week update cycle to narrow patch gap

ZDNET’s key takeaways

• Google moves Chrome to a 2-week update cycle to narrow the patch gap.
• The change comes in response to AI-enabled malicious actors and “fast-moving threats.”
• Google is mulling ways to dynamically patch Chrome without requiring a browser relaunch.

As a recent wave of unintended, agentic AI-enabled attacks has shown, the dawn of a new, perilous era in cybersecurity is now upon us. The latest large language models from various AI frontier companies (OpenAI, Anthropic, etc.) have been shown to possess extremely potent cyber capabilities — valuable to both threat actors and the cybersecurity experts charged with defending against them.

Among those cyber capabilities is the ability to discover and exploit the same sort of vulnerabilities within hours or days that previously required weeks or months of a threat actor’s time.

Even worse: To the extent that a social engineering step is part of a threat actor’s attack workflow, agentic AI can now be harnessed to scale a particularly pernicious and highly personalized form of phishing known as spearphishing. Before highly cybercapable agentic AI became available and affordable to threat actors, spearphishing was often viewed as too resource-intensive for most malicious endeavors. Not anymore.

(Disclosure: Ziff Davis, ZDNET’s parent company, filed an April 2025 lawsuit against OpenAI, alleging it infringed Ziff Davis copyrights in training and operating its AI systems.)

Mind the ‘patch gap’

In response to this new threat level, major software providers of all stripes (mobile apps, desktop software, operating systems, etc.) have been left with no choice but to rethink how to shorten and even close the so-called patch gap. That gap is the opportune window of time between the public disclosure of a vulnerability and the moment that systems are, via a security patch, inoculated against exploits of that vulnerability.

As Picus Security associate security research engineer Umut Bayram recently told ZDNET, in the current AI era, organizations can’t afford to respond to an attack that can unfold in minutes with defense processes that take days. The phrase “cybersecurity arms race” has perhaps never been more apt in capturing the essence of the battle defenders now face against their well-equipped adversaries.

One of those vendors is Google. Largely in response to the nature of that arms race, the company narrowed that window of opportunity when it announced last week that desktop and mobile versions of its Chrome web browser have moved to a two-week update cycle. Prior to the planned change, originally discussed in a Google blog post earlier this year, Chrome was on a four-week update cycle, with mid-cycle emergency security updates issued as needed.

Of particular note in the post, Google’s lead of Chrome browser release Ben Mason and distinguished engineer Deepak Ravichandran wrote: “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.”

The phrase “N-day” refers to the troublesome fact that there can be any number of days between when a vulnerability is publicly disclosed and when a system (let alone the entire user base of a popular product like Chrome) is patched for that vulnerability. To be clear, software vendors typically don’t turn the discovery of some vulnerability into a big public disclosure. But in the case of software like Chrome, whose Chromium open-source codebase is evolving daily, threat actors are examining every proposed change for evidence of new exploit opportunities. At that point, the race is on and, in shrinking Chrome’s update cycle from four to two weeks, Google is looking to cut “N” (on the longest side) from 28 to 14 days.

However, there is still one problem that’s out of every software vendor’s control. It’s one thing for a vendor to issue a patch. It’s another for the user to apply it. Software vendors can go to the greatest lengths to shrink “N”. But, for whatever reasons, “N” can go for months or even years (when you consider unattended kiosk computers) if a system’s owner doesn’t heed the nagging notification to update their system.

Balancing security and patch fatigue

We at ZDNET wondered how major software vendors strike the right balance between security and patch fatigue and, using Chrome as an example, asked Google’s Mason about the specifics of this new update cycle and how Google envisions it working for both users and businesses. His answers are not only great food for thought for any defender, but also a bit of a blueprint for how software companies must rethink their strategies to protect customers from AI-enabled threat actors.

David Berlind: I saw how your post says “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.”  Shrinking the N-day patch gap could be a double-edged sword. For example, one technique threat actors use to exploit systems is to run difs on versions of software (browsers, for example) to understand what was fixed and then use the resulting findings to exploit unpatched systems. What is Google’s thinking on that point?

Ben Mason: Once a security fix is checked into the public Chromium open-source repository, it is visible to everyone. If we delay shipping a fix to users, we only prolong the window during which they are vulnerable to exploits. Shorter release cycles simplify security patch management and get those fixes to users faster, shrinking the window of opportunity for attackers.

DB: What are Google’s findings with respect to threat actors using AI to discover and exploit N-day vulnerabilities? We’ve seen recent attacks in which the exploit occurs within seconds or minutes of the discovery of the zero-day vulnerability.  In Google’s eyes, is this an important defense against those activities? Given the new nature of threats, two weeks suddenly feels like an eternity. Is it even enough?

BM: We are seeing a major shift in software security where large language models (LLMs) are enabling automated, faster vulnerability discovery and exploit generation. In the face of these fast-moving, AI-powered attacks, our delivery cadence must accelerate. While the two-week major milestone cadence is a huge step forward, we are already piloting a shift to two security releases per week to stay ahead of these threats.

DB: There appear to be three main stages to a security patch: One, development of that patch (in which case, the fix can be viewed in the public open source as you stated earlier); two, the delivery of the patch to end users; and three, the software relaunch, which installs the patch.

If I understand this week’s announcement, it’s the second stage that’s changing. In other words, if upcoming fixes can be observed in the open source, threat actors now have less time to act on that information because the patch goes out to browsers within 2 weeks of that observable patch being written, as opposed to 4 weeks. Is that correct?

BM: Your understanding is entirely correct. Patching Chrome involves (1) writing the patch in open source, (2) delivering it to browsers, and (3) restarting the browser. The transition to the two-week release cycle specifically accelerates stage two. By reducing the time it takes to deliver stable patches to browsers from four weeks to two weeks, we dramatically reduce the time threat actors have to act on public open-source commits. As mentioned, our ongoing pilot for twice-weekly security releases aims to shrink this window even further.

DB: I realize that the security rationales are buried there with other reasons for a two-week cycle, but it seems to me like security is really the primary driver for this. Honestly, other features can wait. Is that the case?

BM: While a faster cadence definitely benefits developers and users by delivering features and performance enhancements more quickly, security is absolutely a primary driver. With automated AI discovery tools and community bug reports generating higher patch volumes, moving to a two-week cycle keeps the N-day patch gap as small as possible and ensures our defense velocity matches the speed of modern threats.

DB: Will other Chromium-based browsers be on the exact same schedule? If yes, does that coordination delay the window at all? If no, how far behind will they be?

BM: By shifting to a two-week cycle, we are setting a standard that other browsers in the web ecosystem are also adopting. Since Chromium is open source, other browsers consume upstream changes on their own schedules, but we are glad to see the industry moving toward tighter update windows to protect the web as a whole.

DB: A July post from Google’s Chrome Security Team talks about dynamic patching of Chrome without requiring a restart. Is Google working on that, and is there any idea of when that capability will be delivered?

BM: We are actively researching and developing dynamic patching capabilities to eliminate the need for full browser restarts in most cases. This is still in the early stages, and we will share more details and timing as this work progresses.

DB: The reason I ask that question is that the patch gap seems to be a particularly thorny issue. As that post pointed out, there are a lot of reasons people don’t apply patches immediately. It seems reasonable that moving to a two-week cycle might have the opposite effect: less frequent patch applications due to patch fatigue (which is where dynamic capability would be useful). If I get a patch today and do nothing with it, the clock is ticking. Could AI-enabled threat actors use AI to identify what was patched and then spear-phish unpatched systems?

BM: This is precisely why we are prioritizing seamless, background update mechanisms. Alongside dynamic patching, we are leveraging opportune restart windows (such as MacOS background restarts when all windows are closed) and improving local session restore state to make updates completely non-disruptive. Accelerating the backend release cadence to twice-weekly is designed to close the exploit window before AI-enabled threat actors can capitalize on unpatched systems.

Extended Stable Channel still realistic?

DB: The post talks about enterprises that prefer the 8-week Extended Stable Channel approach. But realistically, given the nature of the so-called “fast-moving threats” along with the extent to which enterprises are some of the juiciest targets out there (especially considering ransomware trends), is that extended window even practical anymore?

BM: The Extended Stable channel remains a practical and necessary tool for highly sensitive enterprise environments where software changes must be rigorously vetted. However, being on Extended Stable does not mean enterprises are left vulnerable to security threats for eight weeks. While major milestone feature updates only arrive every eight weeks on this channel, critical security fixes continue to be backported and released on the regular weekly schedule. This ensures that enterprises don’t have to trade security for stability.

DB: To the extent that the Extended Stable program makes time allowances for businesses that see the need to regression test and vet new updates against their existing applications and business processes, is it foolish of them to keep thinking about cybersecurity vs. application stability in this new era of speedy AI-enabled threat actors? After all, what’s worse for a business? An application that breaks or a ransomware attack?

BM: We understand the delicate balance businesses face between preventing application breakage and defending against ransomware. Not all security patches are active zero-day emergencies, but in the AI era, any unpatched vulnerability can be analyzed and targeted much faster. This is why we backport security updates weekly to Extended Stable — allowing organizations to keep their extensive regression testing pipelines for major milestone updates while still receiving weekly security protection. We also provide tools like the RelaunchNotification policy to help admins manage user restarts in a controlled, non-disruptive manner.