AI Helped Google Chrome Fix 1000+ Security Bugs

Google says artificial intelligence is reshaping how it secures Chrome, helping its engineers identify and address 1,072 security bugs across Chrome 149 and Chrome 150—more than the combined number fixed during the previous 23 major browser releases.

The figure represents a dramatic increase in Chrome’s vulnerability-processing capacity and illustrates how large language models are moving beyond experimental security research into routine software development, triage and patching.

Google is now using AI across almost every stage of Chrome’s vulnerability lifecycle. Models help search for weaknesses, validate reports, reproduce proof-of-concept exploits, determine severity, identify the responsible component, propose patches and generate regression tests.

The company is also integrating security-focused AI agents directly into Chrome’s continuous integration infrastructure, allowing code changes to be examined for vulnerabilities before they reach production.

Google said the expanded automation should not be interpreted as evidence that Chrome has suddenly become less secure. Instead, the surge reflects its ability to uncover and process weaknesses—including long-standing defects that conventional tools and human reviewers had previously missed—at a scale that would have been difficult to manage manually.

According to the Chrome Security Team, large language models generated candidate fixes for most of the vulnerabilities addressed in the two releases. Human developers, however, remain responsible for reviewing proposed changes and deciding whether they should be accepted.

AI expands Chrome’s vulnerability-discovery operation

Google’s latest system is the result of several years of work combining large language models with established security-testing techniques.

The company began experimenting with LLM-enhanced fuzzing in 2023. Fuzzing repeatedly feeds malformed, unexpected or randomly generated data into software to trigger crashes and abnormal behavior that may indicate an exploitable vulnerability.

Traditional fuzzers can execute enormous numbers of tests, but they may struggle to generate the structured inputs or complex sequences needed to reach deeply buried code. Language models can assist by understanding source code, file formats and program behavior, allowing them to produce more targeted tests and explore execution paths that generic mutations might not reach.

Google extended this work in 2024 through Naptime, a Project Zero research framework that gave AI models access to specialized tools used by vulnerability researchers. These included a debugger, a code browser and a Python environment for constructing and testing potential exploits.

Rather than asking a model to inspect a large source file and return a speculative answer, Naptime placed the model in an agent loop. It could form a hypothesis, examine the relevant code, run a program, inspect a crash and revise its approach based on the results.

That tool-assisted structure was important because one of the persistent weaknesses of general-purpose language models is their tendency to identify theoretical problems that cannot be reproduced or exploited. Giving models direct access to testing and debugging tools allowed them to gather evidence before reporting a vulnerability.

Google DeepMind and Project Zero subsequently developed Big Sleep, an AI vulnerability-research agent that found security defects in Chrome’s V8 JavaScript engine and graphics stack. The project demonstrated that models could move beyond detecting obvious coding mistakes and reason about more complicated security boundaries and program behavior.

In early 2026, Google expanded the approach with a Gemini-powered agent harness designed to search a broader portion of the Chrome codebase while producing fewer false positives.

Gemini uncovers a 13-year-old sandbox weakness

One of the most significant findings from the Gemini-powered system was a sandbox escape that had survived in Chrome’s codebase for more than 13 years.

Chrome’s sandbox is a central part of the browser’s defensive architecture. Web content is processed inside restricted renderer processes that are intended to have limited access to the underlying operating system. If an attacker exploits a memory-corruption or logic vulnerability inside a renderer, the sandbox is designed to prevent that initial compromise from becoming full access to the device.

Escaping that boundary can therefore transform a renderer vulnerability into a much more serious attack chain.

Google said the long-standing flaw could have allowed an already-compromised renderer to manipulate the browser into reading local files. The company has not publicly released sufficient technical detail to enable exploitation, which is common while security updates are still reaching the wider Chrome population.

The discovery is particularly notable because the defective code had been exposed to years of conventional testing, code review and security research. Its detection suggests AI-assisted analysis may be effective at revisiting old assumptions and identifying weaknesses that do not necessarily manifest as a simple crash.

Google has built a vulnerability knowledge base containing Chrome’s Git history and previously identified CVEs to give its models access to information extending beyond their original training data. Models can therefore compare current code with earlier security fixes, recognize recurring vulnerability patterns and understand how Chrome’s architecture has changed over time.

The company is also encouraging developers to create SECURITY.md files for individual components. These documents describe trust boundaries, threat models and security-sensitive operations that may not be obvious from the code alone.

A separate “critic” agent can consume that contextual information while assessing a finding or proposed patch. This helps the system distinguish between behavior that merely looks unusual and an operation that crosses a genuine security boundary.

Google also runs models across the codebase more than once. Because generative models are non-deterministic, separate passes may produce different findings. Repeated analysis can uncover issues missed during an earlier run and allows Google to revisit the same code as the underlying models improve.

AI does not replace fuzzing or human review

Despite the rapid increase in AI-generated findings, Google said it is not abandoning established techniques such as fuzzing, static analysis, code review and testing.

Fuzzing remains particularly effective when a vulnerability depends on a long sequence of operations or interactions between otherwise unrelated parts of the browser. Traditional tools also provide deterministic, reproducible results that are essential when verifying whether a security fix is complete.

The model-driven systems instead provide an additional analytical layer. They can reason about intent, interpret comments and documentation, correlate distant pieces of code and suggest which operations deserve closer examination.

Google’s workflow also keeps engineers in the approval process. AI agents can produce candidate patches and tests, but developers review the proposed changes before they are merged.

This distinction matters because automatically generated security patches can introduce regressions, address only the visible symptom of a vulnerability or create a different weakness elsewhere. Chrome must operate across numerous combinations of operating systems, processor architectures, hardware configurations and enterprise policies, making broad testing essential.

Google said its test-writing agents can generate regression tests and validate fixes across supported platforms and configurations before presenting the results to a developer. In some cases, the company estimates that this can eliminate weeks of manual engineering work.

Multi-agent system proposes and reviews patches

Once a vulnerability has been confirmed, Google uses a multi-agent workflow resembling a conventional engineering review.

A fixing agent receives the issue and relevant technical context before generating several possible patches. A separate critic agent then evaluates those candidates, identifies potential problems and produces supporting material for developers.

The fixing and critic agents can operate in a loop, refining the code until it meets Chromium’s functionality, style and local development requirements. Test-writing agents then create checks intended to demonstrate that the vulnerability is fixed and prevent the same defect from being reintroduced later.

Google said the systems are now integrated with its continuous integration and commit-queue infrastructure. The company runs DeepMind and Project Zero technology, including Big Sleep and CodeMender, every 24 hours across code changes.

In May 2026 alone, the automated checks reportedly prevented more than 20 vulnerabilities from entering production. One was classified as an S1+ issue, Google’s designation for a critical security problem.

The company is also using models at code-submission time to flag dangling pointers, unsafe numerical operations and opportunities to replace raw pointer-and-length constructs with safer std::span abstractions.

This earlier intervention is important because scanning an entire codebase periodically may not keep pace with Chrome’s development activity. An otherwise safe component can become exploitable after a small and apparently unrelated change elsewhere in the browser. Semantic analysis of individual code changes may help identify these compound risks before the code is merged.

Automated triage saves hundreds of engineering hours

Finding more vulnerabilities creates its own operational problem: each report must be validated, prioritized, assigned and eventually fixed.

Google said the volume of Chrome security reports rose sharply during early 2026. By March, the company had received more reports than it had during the entirety of 2025.

Historically, triaging an individual report could consume between five and 30 minutes—or longer—of an experienced engineer’s time. Multiplied across thousands of submissions, duplicates and low-quality reports can absorb a substantial portion of a security team’s capacity.

Google’s automated triage pipeline initially determines whether an incoming submission is spam, a duplicate or outside the Chrome security program’s acceptance criteria. It then examines any supplied proof of concept and attempts to reproduce the behavior using the affected browser and operating-system versions.

When reproduction is successful, the system can add stack traces and other diagnostic information. It also attempts to identify when the bug entered the codebase, assign a severity rating and route the issue to the appropriate Chrome component and developer.

Engineers can override an automated severity decision when they believe the system has misunderstood a security boundary or the practical impact of the flaw.

Google estimates that the combined triage system saves hundreds of developer hours every month. That time can be redirected toward complex investigations, architectural improvements and vulnerabilities for which automated tools cannot produce a reliable conclusion.

Chrome reward programme adjusts to AI-generated volume

The rise in AI-assisted vulnerability research is also changing Google’s relationship with outside security researchers.

Chrome’s Vulnerability Reward Program has historically paid researchers who privately disclose qualifying browser vulnerabilities. External researchers remain valuable because they may approach the browser differently, combine weaknesses into realistic attack chains or identify logic errors that automated systems do not recognize.

However, the rapid growth in model-generated reports creates challenges. Multiple researchers may submit the same AI-discovered bug, while some reports may contain speculative findings without a working proof of concept or clear security impact.

Google has consequently revised its Chrome VRP guidance to prioritize submissions that add value beyond what its internal automation is already discovering and that can be processed efficiently by the new triage systems.

This does not mean human researchers are being removed from the programme. Instead, Google is attempting to direct them toward more difficult, impactful and creative research—areas where specialist knowledge and adversarial thinking still provide a significant advantage.

Finding bugs faster makes the patch gap more dangerous

The ability to discover and fix vulnerabilities more quickly addresses only part of the problem. Users remain exposed until the corrected software is delivered and activated on their devices.

Chromium is an open-source project. Once Google commits a security fix to the public repository, attackers can compare the new and old code, infer the underlying vulnerability and attempt to build an exploit. If the patch has not yet reached the stable version—or has been downloaded but not activated—the affected user remains vulnerable to an “N-day” attack.

This interval is known as the patch gap.

Chrome’s main development tree has historically been several weeks ahead of the stable release used by most people. Google can merge high-severity fixes directly into the active stable branch, but every accelerated update must still be tested to avoid crashes and compatibility problems.

The company is transitioning Chrome to a two-week major milestone schedule accompanied by weekly security updates. It is also piloting two security releases per week as it prepares for attackers to use AI to analyze patches and develop exploits more rapidly.

Google is separately working to automate the creation of security release notes and CVE descriptions. Automating this administrative work could remove another bottleneck between confirming a vulnerability, deploying the correction and publishing an appropriate disclosure.

Dynamic patching could reduce dependence on browser restarts

Chrome has downloaded and staged updates silently in the background since its launch in 2008. However, the new version normally becomes active only after the browser restarts.

For many users, Chrome remains open for days or weeks. They may maintain dozens of tabs, active web applications or unsaved work and therefore postpone a restart even when an update notification appears.

Google said this delay can now represent a significant proportion of the exposure window. If a vulnerability can be identified, triaged, fixed, tested and released within one or two days, waiting several more days for the browser to restart undermines some of that improvement.

The company is therefore developing “dynamic patching,” which would apply many Chrome updates without requiring a complete restart.

The design takes advantage of Chrome’s multi-process architecture. Rather than replacing the entire running browser at once, Chrome could progressively terminate background child processes—such as renderer and GPU processes—and launch replacements using the updated binaries.

Dynamic patching remains under development and may not be suitable for every type of update. Changes affecting the central browser process, persistent state or incompatible internal interfaces could still require a full restart.

Google is also working on more comprehensive session restoration so that, when a restart is unavoidable, open tabs and other browser state can be recovered with minimal interruption.

Chrome 150 on macOS introduces an early version of opportunistic restarting. macOS applications can continue running in the background after their last visible window has been closed. If Chrome detects a pending update while it is in this windowless state, it can automatically restart and activate the update without interrupting an open browsing session.

Google’s longer-term objective is a browser that remains continuously updated through a combination of dynamic process replacement, improved session restoration and carefully timed automatic restarts.

Google details safeguards for its security agents

Expanding AI’s role in vulnerability research also creates security concerns of its own. Models analyzing exploit paths or generating patches may interact with sensitive code, create proof-of-concept material or behave in ways their operators did not anticipate.

Google said its Chrome-scanning models examine source code at rest inside locked-down machines without general internet access. Network requests are intercepted and checked against allowlists based on the originating application and intended destination.

The company said it does not run the models in an unrestricted mode. Subagents are also prevented from modifying the underlying system or reading files outside specifically designated source-code directories.

Those controls are intended to limit the consequences of unexpected agent behavior while still giving the models enough access to analyze and test Chrome code.

Bug totals require careful interpretation

The 1,072 figure demonstrates the scale of Google’s new workflow, but it should not be treated as 1,072 independently exploitable critical vulnerabilities.

Security-bug counts can include defects with widely different impacts, levels of reachability and exploitation requirements. Some may be defense-in-depth improvements, low-severity weaknesses, related instances of the same underlying coding pattern or flaws prevented from ever reaching a production build.

Google has not published a complete severity breakdown for all 1,072 issues in the announcement.

The total nevertheless shows that AI has changed the economics of large-scale vulnerability remediation. Google is no longer using models only to search for isolated high-profile flaws. It is applying them throughout the operational pipeline required to convert a finding into tested code and deliver that code to users.

The next challenge will be maintaining accuracy as the volume continues to increase. A security operation capable of producing thousands of findings must also control false positives, avoid incomplete patches, prevent regressions and ensure that critical vulnerabilities are not buried among lower-risk defects.

What organisations should do

For enterprises, Google’s announcement does not remove the need for disciplined browser-update management. Faster releases provide little protection if endpoints remain on older versions or users repeatedly postpone restarts.

Administrators should monitor installed Chrome versions across their fleets, enforce an appropriate relaunch deadline and investigate devices that fail to update. Google recommends its RelaunchNotification policy, which can progress from a reminder to a forced restart within an administrator-defined period.

Highly sensitive organisations that require additional testing can use Chrome’s Extended Stable Channel, although the trade-off between compatibility validation and exposure to newly disclosed vulnerabilities must be evaluated carefully.

The broader significance extends beyond Chrome. Google says Chromium and related projects—including V8, BoringSSL, Skia, ANGLE and Dawn—contain more than 2,300 third-party dependencies, roughly 1,700 of which reach users through Chrome and other products. AI-assisted discovery can expose weaknesses across this enormous supply chain, but the benefits depend on maintainers having the resources and processes required to validate and deploy the resulting fixes.

Google’s announcement suggests vulnerability discovery is entering a period in which finding flaws may no longer be the principal constraint. The harder problem could increasingly be processing reports, designing safe patches, testing them across complex environments and delivering updates before attackers can exploit the disclosure gap.

For Chrome users, the immediate message remains straightforward: enable automatic updates and restart the browser promptly when an update is waiting. AI may help Google find and repair vulnerabilities faster, but protection is not complete until the patched code is actually running.