Google fixed 1,072 Chrome bugs with AI: the bottleneck is now you

Google fixed 1,072 security bugs across two Chrome releases, more than in the previous twenty-three releases combined. The headline is spectacular and, for your company, almost irrelevant: hardly any of those bugs were being exploited by anyone. What does affect you is the rate at which updates are about to start landing on you — Chrome is piloting two security releases a week, and from September it ships a milestone every two weeks. That is not a story about artificial intelligence. It is a story about your calendar.

The numbers came out on 30 July on Google's blog. Chrome 149 and Chrome 150, both from June, added up to 1,072 fixed bugs; TechCrunch puts the previous twenty-three milestones at 1,036, spread over two years. With Chrome 151 on top, the last three releases add up to 1,442 fixes, and the year is already past 1,800. The curve did not go up: it changed shape.

The machine combing the code

This is not a product or a trade-show announcement: it is a toolchain wired into the engineering process. Google has been using language models in security research since 2023, but what pushed the number, by its own account, is an agent built in early 2026 on top of Gemini, trained on a knowledge base of previous CVEs and on Chrome's entire Git history. Add Naptime (2024, with Project Zero), Big Sleep (with DeepMind and Project Zero, focused on the V8 JavaScript engine and graphics) and CodeMender, which lives inside the continuous integration system. The models do not just search: they reproduce the bug, assign severity, route it to a team, generate a candidate patch and write the test.

The figure that best explains the shift is not 1,072, it is this one: in May alone that system blocked more than twenty vulnerabilities before they reached production, one of them critical. And the headline find is a sandbox escape that let a compromised renderer trick the browser into reading local files, and that had been sitting in the codebase for more than thirteen years. SecurityWeek identifies it as CVE-2026-3545, CVSS 9.8, fixed in early May in Chrome 145.

Thirteen years. That bug survived Project Zero, a bounty programme that pays well, audits from half the industry and more eyes than any other open-source project gets. Worth saying without the epic tone: the interesting part is not that the machine is clever, it is that the human bar was far lower than we like to believe. And there is a knock-on effect already visible across the ecosystem: by March, Google had received more security reports than in all of 2025, and has had to refocus its bounty programme on submissions that are additive to what its own tooling already finds. The human bug hunter now competes with something that never sleeps and knows where to look.

"By applying models like Gemini, we are preemptively fixing vulnerabilities, outpacing our adversaries and making Chrome safer with every update." — Doug Turner, Chrome's director of engineering.

1,072 is not a measure of risk

Fixing 1,072 bugs does not mean last week's Chrome was 1,072 times more dangerous. The vast majority of those bugs were not being exploited by anyone, and many were not exploitable on their own. What went up is not risk: it is the ability to find. Those are two different charts, and they have been drawn on top of each other for weeks.

The practical consequence is awkward for anyone who writes reports: counting CVEs no longer measures anything. Two weeks ago we counted 622 Microsoft patches in a single Tuesday, an absolute record, and even then the raw number said nothing about whether your company was better or worse off. Now the noise floor rises again. If your security dashboard has a "vulnerabilities this month" chart, that chart no longer informs: it decorates.

Two things do still measure something, and neither appears in the press release: whether a bug is actually being exploited — that is what CISA's KEV catalogue is for, and why we prioritise by exploitation rather than CVSS — and how long you take to move the patch from announcement to machine. Google has just sped up its half of that equation. The second one is yours, and no agent is coming to help.

The number that does change your calendar

It is worth being honest about the chronology, because a good deal of the coverage has blurred it. The two-week cadence was not announced on 30 July: it was announced on 3 March and starts with Chrome 153, on 8 September 2026. And weekly security updates have existed since 2023. What is genuinely new in this announcement is something else, and it points exactly where an administrator cares: Google is piloting two security releases a week to narrow the window between a bug being fixed and you having the fix installed. For a home user all of this is transparent: the browser updates itself and that is that. For anyone managing a fleet of two hundred desktops, it is not.

Because a browser update in a company does not end when the binary downloads: it ends when the user restarts. And users do not restart. They have forty tabs open, the ERP in one of them and a half-finished order. There is a Chrome Enterprise policy to force it, RelaunchNotification, and in most of the fleets that reach us from elsewhere it is simply not configured, which leaves the browser patched on disk and unpatched in memory. That nuance, which sounds like an admin detail, is literally the difference between being protected and believing you are.

And here Google deserves its due, because this is the least reported part of the announcement: they are attacking that half too. From Chrome 150 on macOS, the browser can restart itself to apply a pending update when it has been sitting in the background with no windows open. And the stated goal goes further: dynamic patching — applying updates without restarting the browser at all, plus better session restoration. If they pull it off, the restart problem is over. Inside Chrome. Which is exactly where the favour ends: nobody is going to dynamically patch your ERP, your VPN client or your access point firmware.

Google also offers the Extended Stable channel, designed for sensitive environments that need to move more slowly, and which keeps its eight-week cycle even after September. That contrast sums up the dilemma better than any paragraph: eight weeks on one side, two security releases a week on the other. It is a legitimate tool when it is needed. But it is worth saying what it is for and what it is not: it is a "go slower" button, not a "do not update me" button. If you turn it on because you have an internal application that only works with one specific browser version, you have not solved a security problem: you have postponed a development problem, and given it an expiry date. And if your policy is "the browser gets reviewed at the quarterly maintenance visit", with two security releases a week that is no longer a policy: it is debt with interest.

The asymmetry nobody will fix for you

Here is, in our view, the part actually worth taking away. Google can afford a fleet of agents reviewing its own code, with its own continuous integration, its history of nearly two decades and its CVE knowledge base. It is one of the very few companies in the world that can. The software holding up your business cannot.

The vertical ERP your sector runs on, maintained by four people. The production machine vendor's software, updated whenever the technician visits. The scanner viewer, the CRM plugin, the time-clock app, the label printer firmware. Nobody is going to point a Gemini-powered agent at that code. The security bar is rising, fast, exactly where it was already high — browsers, operating systems, hyperscaler cloud — and it is not moving a millimetre where it was low. Your risk does not go down: it moves.

And one detail from the announcement itself sums it up better than any metaphor: Chrome carries more than 2,300 third-party dependencies, roughly 1,700 of which ship to users. Not even Google runs only Google code. A good share of those libraries also live inside your applications, packaged by your vendors, and there is no fleet of agents looking at those.

We wrote the other side of this a week ago: the attacker has the same tools. Neither they nor Google invented new bug classes; both compressed time. If the time to find compresses on both sides, the time to apply has to compress too — and that is the only one of the three that depends on you.

The boring work that actually changes the outcome

None of this is glamorous and most of it fits into one well-spent afternoon. It is what we do on the fleets we maintain, and it is literally the job of IT maintenance when it is done properly rather than reactively.

• An inventory that is not a spreadsheet. What software runs on every desktop and server, with versions. Without it, "are we affected?" can only be answered with a shrug.
• Auto-update on by default for browsers and clients. At this cadence, letting it update itself is the conservative choice; holding it back to "keep control" is the risky one. That flipped, and plenty of internal policies have not noticed.
• Force the restart. RelaunchNotification set to required, with RelaunchNotificationPeriod tuned — the default is seven days, which at this cadence is too long — and RelaunchWindow so the forced relaunch lands overnight rather than mid-morning. A patch waiting for the user to close the browser on Friday is a patch that does not exist Monday to Thursday.
• Exceptions with a date and an owner. Every machine that cannot be updated needs both written down. An exception without a date is a permanent decision taken by accident.
• Prioritise by exploitation, not by volume. CISA's KEV catalogue first, the rest by maintenance window. Trying to cover everything is the most reliable way to miss what matters.
• Measure time, not count. The useful metric is how many days pass between vendor release and fleet deployment — and above all the tail: the handful of machines always left behind. Incidents live in the tail, never in the median.
• Compensate for what cannot be patched. The workshop PC running a Windows nobody touches because it drives a six-figure production machine exists in almost every company. You do not patch it: you isolate it in its own VLAN, restrict what it can talk to and watch it with EDR/MDR. That part you can do today.

And four things we do not do

• Turning off auto-update to "control changes". With milestones every two weeks, that is not control: it is stacking versions until the jump is big enough to be scary.
• Measuring security by CVE count. In either direction. A month with 1,072 fixes may be the safest month of the year.
• Buying something because of a headline. No tool sold this week with "AI" in front of it will shrink the time between a patch shipping and you having it installed. That is process, not product.
• Confusing "the vendor fixed it" with "it is fixed at my company". The distance between those two sentences, measured in days, is your real attack surface.

The patch exists from minute zero

We like this story, and not because of the number. We like it because it shows something we have been saying for years with less data behind it: the patching problem was never a shortage of patches. Patches exist from minute zero. Risk lives in the days between existing and being installed, and those days are not set by the vendor — they are set by you. If your share is still "we will look at it next month", the net effect of all this technological marvel inside your company is exactly zero.

And if, reading this, you do not know how many days a patch takes to reach the last machine in your company, that is the question we would start with. It does not take a new tool to answer; it takes looking. If you want us to look at it with you, you know where we are.

Sources (verified): the fix counts (1,072 in Chrome 149 and 150, more than the previous 23 milestones combined), the tooling (Naptime with Project Zero in 2024, Big Sleep with DeepMind, the Gemini-based agent from early 2026, CodeMender in continuous integration), the 20-plus vulnerabilities blocked before production in May, the 13-year-old sandbox escape, the bounty programme change, the 2,300-plus third-party dependencies (around 1,700 shipped) and the new cadence of milestones every two weeks with the two-security-releases-a-week pilot, all from Google's announcement "Chrome: stronger with every update" (blog.google, 30 July 2026). The comparison with the previous 23 milestones (1,036 bugs over two years), the Chrome 149 and 150 dates and the Doug Turner quote, from TechCrunch (30 July 2026). The identification of the sandbox escape as CVE-2026-3545 (CVSS 9.8, fixed in Chrome 145 in early May) and the 1,800-plus running total for 2026, from SecurityWeek. The 1,442 total across the last three releases, from The Hacker News. The 622 Microsoft July patches are from the bulletin we covered at the time. We have not independently verified Google's internal counts.