Maintaining web browser security has entered a new phase. Google's Chrome security team fixed a combined 1,072 security bugs across Chrome 149 and 150, released between June and July 2026. This figure exceeds the total number of vulnerabilities fixed across the previous 23 major releases combined.

This dramatic increase in fixes isn't just due to more reports from security researchers. The biggest factor is the evolution of AI-powered vulnerability discovery tools inside Google. Google has trained large language models on the complete history of past vulnerabilities (CVEs) and the massive changelog of Chromium's source code. Traditional fuzzing—a testing method that feeds massive amounts of random data to trigger crashes—could find syntax bugs and memory corruption. However, it couldn't detect logical flaws stemming from developers' unconscious assumptions.

AI has broken through this barrier. By having language models read code's abstract syntax trees (ASTs) and bug tracker discussion histories, AI can pinpoint the blind spots that human programmers are prone to. For example, it can identify boundary condition checks that are grammatically correct but semantically break down only under specific states—paths that fuzzing would miss. Even vulnerabilities buried in old code for years are now being uncovered at lightning speed. In fact, a serious bug that had lurked in Chrome's codebase for 13 years has been discovered this way. AI has become a trump card for the defensive side.

Automated bug discovery through AI is a powerful weapon for Google as the defender. But this isn't the whole story. Malicious attackers are also using similar AI models to search for unknown vulnerabilities and enhance their exploitation capabilities. As the pace of this arms race accelerates, Google has been forced to push the delivery speed of security patches to unprecedented levels.

AD

The Dangerous Window Called the "Patch Gap"

Even as the speed of finding vulnerabilities and developing fixes increases, this alone isn't enough to fully protect users. A time lag exists between when Google commits a fix to the codebase and when it reaches the Stable channel used by most users. This window is known as the "patch gap."

Chromium is an open-source project. The moment Google publishes a fix to the repository, the modified source code becomes visible to the entire world. Attackers feed that diff (the commit) into AI to perform reverse engineering. By working backward from the fix, they can identify what vulnerability existed and how to exploit it within hours. This creates the danger of "N-day attacks" targeting users who haven't yet applied the patch. Ironically, speeding up patch development has also increased the speed at which hints are handed to attackers.

To close the patch gap, Google is accelerating Chrome's release cycle to the extreme. Starting with Chrome 153, scheduled for release in September 2026, major releases will shift from a four-week interval to a two-week interval. Google is also piloting a test to increase the frequency of security updates delivered between major releases from once a week to twice a week.

However, increasing update frequency places a different burden on users. Under the current system, even after downloading a new update, installation isn't complete until the user manually restarts the browser. Restarting the browser in the middle of work is a hassle for many users and tends to get postponed. As a result, a dangerous state persists where the patch is available but not yet applied.

Competing browsers face this same dilemma. Microsoft's Edge closely integrates with Windows' background update mechanism and Group Policy, increasing the certainty of patch application, especially in enterprise environments. However, user frustration with OS restarts and forced shutdowns remains persistent. Meanwhile, Apple's Safari depends heavily on the update cycles of macOS and iOS. Updates to the core WebKit engine often involve OS-level changes, and in emergencies, Apple attempts to minimize restarts through minor updates using "Rapid Security Response." Yet no platform has achieved the ideal update experience that is self-contained within the browser alone and never interrupts the user's work.

Dynamic Patching Technology That Makes Browser Restarts a Thing of the Past

To resolve this contradiction, Google is investing in technology to keep users' security posture up to date without imposing any burden on them. For Chrome, which supports a wide range of environments including Windows, macOS, Linux, and Android, developing its own seamless update mechanism independent of OS features has become an urgent priority.

As a first step, Chrome 150 introduced a feature called "Zero window restart" for macOS. On macOS, applications continue running in the background even after all windows are closed. Leveraging this characteristic, when Chrome detects that an update is pending while all windows are closed, it automatically restarts in the background. The next time the user launches Chrome, the update will already be complete.

Google is also pursuing a more fundamental, OS-agnostic solution called "Dynamic patching." Chrome employs a multi-process architecture that splits rendering, GPU processing, and other functions into multiple independent background processes. Dynamic patching leverages this structure to sequentially swap running background processes with updated binaries, without restarting the entire browser.

However, swapping out running processes like a heat exchanger is no easy feat. When a tab is playing video or a form has text being entered, screen flickering and crashes must be prevented while swapping out the GPU process or renderer process. Achieving this requires serializing the state of frames being rendered, the in-memory DOM (Document Object Model) state, and the JavaScript heap in an extremely short time, then accurately transferring this data to the new process via inter-process communication (IPC).

Google is currently testing an approach in which old and new processes run in parallel for milliseconds at a time. Once the new binary is confirmed to be running stably, the communication path is switched over without the user noticing. Even the slightest failure would trigger the "Aw, Snap!" error screen, making this an extraordinarily difficult engineering challenge.

The general availability timeline for dynamic patching remains undetermined, but Google's ultimate vision is a browser that always stays up to date and secure without the user ever having to think about it. The inflation in vulnerability discovery brought about by AI is, ironically, pushing the very architecture of web browsers to evolve into a more sophisticated, self-updating system. How close to zero Google can bring the "friction" of restarts remains a development to watch closely.