Chrome 151 Fixes 370 Security Flaws at Once: CVE-2026-17650 and More

On July 29, 2026, Google shipped Chrome 151 (151.0.7922.71/.72) to the desktop stable channel, patching 370 security flaws in a single release. The official announcement states plainly: "This update includes 370 security fixes."

The number looks alarming, but not one of the 370 has been reported as used in a real attack. All you need to do is open Chrome, update from the menu, and restart. This article walks through the update steps, what the 370 actually consist of, and why a figure of "382 flaws fixed in Chrome 151" is circulating online.

What to do first: update and restart, that's it

This takes three minutes. The steps in Google's official help page are as follows.

Open Chrome, click "More" (the three vertical dots at the top right), then Help > About Google Chrome. If an update is available, the download starts automatically, and you then press the "Relaunch" button that appears. Until you press it, the fixes are not applied even though the download has finished. When you see "Chrome is up to date," you are done.

Your open tabs and windows reopen automatically after the relaunch, but as the help page spells out, Incognito windows are the one thing that will not come back. If you are in the middle of something in an Incognito window, save the URLs before you relaunch.

On phones, Android users update through the Play Store profile menu under "Manage apps & device," and iPhone users through the App Store profile under "Updates." Google explicitly notes that Chrome 151 for Android contains the same security fixes as the desktop release.

Edge, Brave, Vivaldi and Opera all run on the same foundation (Chromium) and therefore carry the same holes. Each vendor takes anywhere from a few days to two weeks to ship a matching build, so if you use one of those, check for its update too.

Who actually wants a hole like this

Two kinds of actors want browser flaws. One is fraud crews that buy ad inventory and slip malicious ads into it. The other is the commercial surveillance industry that sells targeting tools to government agencies to go after specific journalists, activists and executives. Both see the browser as a route that reaches many people at once, quietly.

What they do is the same in either case: get you to load a crafted page and then break out from inside the browser. Chrome confines the part that renders web pages inside a cage called the sandbox, so it cannot touch files on the machine itself. Most of the holes closed in this release are hairline cracks in the walls of that cage. Chain a few of them and you get outside.

Once outside, an individual loses saved passwords and login state (cookies), which turns into hijacked email, banking and social accounts. For a company it is worse: a single ad an employee loads during work becomes an entry point into the corporate network. Ransomware post-mortems routinely trace the first step back to a browser. The cost of leaving the update for a week is exactly that: a week with the door propped open.

What the 370 contain. Only 7 are rated most severe

Google grades flaws on its own four-step scale: Critical, High, Medium and Low. Counting the 370 in this release gives the following breakdown.

Medium and Low dominate at 292 combined, close to 80 percent of the total. That is the reality behind the headline figure of 370. The seven Critical entries, by contrast, were all found inside Google, and their report dates cluster between May 18 and June 14. Here are all seven.

CVE-2026-17650: use-after-free in the compositing layer

A use-after-free in Compositing, the component that stacks layers to paint the screen. If an attacker can place their own data in the freed region, stepping on it lets them redirect program flow. Details remain restricted even in the NVD entry. Reported May 18, 2026.

CVE-2026-17651: insufficient input validation in Dawn, the WebGPU backend

Dawn underpins WebGPU, the feature that lets a web page drive the machine's graphics hardware directly. Validation of untrusted input is insufficient, so unexpected values break it. Chrome's WebGPU surface is an area with a track record of real-world exploitation in 2026, which is why Google weights it heavily. Reported May 28.

CVE-2026-17652: use-after-free in Views, the window drawing layer

Views draws the browser's own UI: tabs, buttons and so on. It sits outside the part that renders web pages, meaning outside the cage, so a hole here has a more direct impact. Views picked up several fixes this cycle, including the High-severity CVE-2026-17670 and CVE-2026-17699. Reported June 2.

CVE-2026-17653: use-after-free in the Skia graphics library

Skia is the shared rendering engine Chrome and Android use to draw shapes and text. It is embedded in products well beyond Chrome, which makes the blast radius of this class of bug hard to trace. Reported June 5.

CVE-2026-17654: race condition in the auto-updater itself

The Updater, the resident process that keeps Chrome current, has a race condition that breaks when operations arrive out of order. Update machinery usually runs with near-administrator privileges, so hitting it leads to privilege escalation. Of the seven Critical entries, this is the only one that can matter without opening a web page at all. Reported June 10.

CVE-2026-17655: insufficient input validation in ANGLE

ANGLE translates OpenGL calls from web pages into DirectX and other native graphics APIs. Thirty of the 370 fixes are ANGLE-related, the second largest group by component. Translation layers handle externally supplied values constantly, which is exactly where validation gaps appear. Reported June 11.

CVE-2026-17656: use-after-free in Ozone, the Linux display layer

Ozone is the abstraction layer that handles windows and displays, primarily on Linux. Linux desktops and Chromium-based environments including ChromeOS are in scope. Reported June 14.

By component, the largest group is not what you would guess: Chrome for iOS, with 35 fixes. Then ANGLE at 30, DevTools at 18, password handling at 16, extensions at 14 and the V8 JavaScript engine at 11. By bug class, "Inappropriate implementation" leads with 128, followed by insufficient input validation at 70 and use-after-free at 49.

One of the 370 comes from a third-party open source component: CVE-2026-17705, an integer overflow in libxml, reported by ebassi of Igalia. If you want to know which outside components your own software is carrying, browser or otherwise, we also run a scanner where you paste your dependency file and get an answer.

Why looking these up returns no severity score

If you searched CVE-2026-17650 and found no severity number, that is not a mistake on your end.

Vulnerabilities normally carry a CVSS score from 0.0 to 10.0. Google Chrome, however, does not assign CVSS to the CVE IDs it issues. All you get is the in-house four-step Critical/High/Medium/Low rating, and all 370 entries sit in the US National Vulnerability Database with an empty score field. NVD sometimes scores things later on its own, but at this volume that is not realistic.

So "no CVSS" does not mean safe, and it does not mean the assessment is pending. It simply reflects how Google chooses to publish. The four-step rating is enough to act on. Separately, flaws confirmed to be under active attack are published by the US agency CISA in a list called KEV, and past Chrome zero-days appear there. You can check it through our searchable KEV dashboard; none of today's 370 are listed at the time of writing.

Why one update fixes 370 things: Google has AI doing the hunting

Of the 370, 349 are credited to "Reported by Google," meaning they were found in-house. Only 21 came from outside researchers, bounties were paid on 8 of them, and the total payout is $58,500 (the largest being $36,000 for CVE-2026-17657, a navigation bug). Fixing hundreds of flaws while paying out that little says the discovery work has moved almost entirely inside the company.

Google explains why itself. The Chrome Security 2026 Q2 update published by the Chromium project contains this line.

The same report explains the bug bounty overhaul by pointing to "the volume of reports being discovered and fixed using internal AI tooling." It also says of Big Sleep, the vulnerability-hunting agent built jointly by Project Zero and DeepMind, that "the Big Sleep agent now operates as a fully automated pipeline, helping secure V8."

Worth being precise here: Google says AI is why the counts went up, but it has never said that AI found these particular 370. Every one of the 370 in the release notes is rolled up as "Reported by Google," with no breakdown of what came from AI. Counting across 377 Chrome release announcements from August 2024 onward, the name "Google Big Sleep" is credited only in a handful of posts clustered in 2025, and not once in any 2026 release note.

Oddly enough, the only AI tool named anywhere in the Chrome 151 announcement belongs to someone else. The reporter field for CVE-2026-17658 (a use-after-free in V8, $1,000 bounty) reads "Duc Nguyen of Calif.io in collaboration with OpenAI Codex Security." The boilerplate acknowledgement at the end of the announcement still lists only conventional tooling such as AddressSanitizer and libFuzzer, with no mention of AI at all.

There is a second factor inflating the visible count: Google changed how it writes up internally found bugs. Through the announcement of September 30, 2025, in-house findings were collapsed into a single line reading "Various fixes from internal audits, fuzzing and other initiatives," without CVE IDs at all. That line disappears entirely from announcements after October 2025, and internal bugs now each receive their own CVE ID. Fix the same volume of bugs, change only the write-up, and the count jumps.

Google itself notes in the quarterly report that "there is ongoing work to also improve our CVE and release notes issuance processes to scale appropriately with the increased volume we are observing." AI-driven discovery and a change in accounting. How much of "370" each contributes cannot be separated from the outside, because there is no official breakdown.

The "382 flaws in Chrome 151" figure going around is about 150

Search around and you will find plenty of articles and posts claiming "Chrome 151 fixes 382 vulnerabilities, 15 of them Critical." That is a different release, and both the number and the version are wrong.

The mistake started with Google. The build shipped on June 30, 2026 was Chrome 150, but the announcement initially gave the version as "151" and the count as "382." Google corrected both afterwards; the accurate figure is 433 fixes in Chrome 150. SecurityWeek's article still carries the correction note at the bottom.

The problem is that aggregator sites which copied the pre-correction snapshot still say "Chrome 151 = 382." It spread into Japanese too, in posts like this one from June 30.

That is not the poster's fault. Google's own announcement said so, which made it accurate at the time. The trouble is that anyone searching for "Chrome 151 vulnerability" today lands on these and never reaches the announcement for the 370 that actually shipped.

There is a reason the Japanese press has not covered the count either. Impress Watch published its Chrome 151 story at 9:40 a.m. on July 30, covering the switch to a Rust-based XML parser and other changes, and stated that "this version's release notes contain no description of security-related fixes; we will wait for details to be published." The security section did not exist when Google first posted the announcement, and the list of 370 was appended later. GIGAZINE's release story likewise says nothing about the count.

One more confusing overlap: headlines reading "151 vulnerabilities in Chrome" are not about version 151. They refer to Chrome 148, reported by Security NEXT on May 29, which happened to fix 151 flaws. The version number and the count collided, so those stories rank high for "Chrome 151." Always check the version number written in the article.

429, then 433, then 370. The trend is not simply upward

An impression is forming that every release now carries 400-odd fixes. Here is the actual movement, with every figure counted from the text of Google's own announcements.

The total fell about 15 percent from 433 to 370, and the most severe tier went 22, then 20, then down to 7. Three months of triple-digit counts is real, but this is not a straight climb. Smaller emergency releases sit in between: the July 14 update carried 15 fixes, and July 23 carried 4. The triple-digit drops land on major version bumps, where a month's worth appears to be booked at once.

How the counts look will shift again in September. Google has announced that starting with Chrome 153 on September 8, releases move from a four-week to a two-week cadence. Per-release counts should roughly halve.

If this is a managed work machine

In Japan, Chrome holds 65.4 percent of desktop browser share (StatCounter, June 2026), below the global 72.24 percent, with Edge taking 22.2 percent, more than double the global average. That is the signature of a market full of corporate-issued Windows machines, and since Edge shares the same foundation, IT teams have to watch both.

Enterprises get a separate track called Extended Stable. Per Google Chrome Enterprise help, regular Stable updates every two weeks while Extended Stable runs on an eight-week cycle, holding back feature churn while still taking security fixes on a short interval.

Two caveats. First, Extended Stable exists only for even-numbered milestones, so 151 is not in scope at all; as of July 30 the rollout is staged across 150.0.7871.187 and 150.0.7871.212. Second, Google has confirmed that Extended Stable stays on eight weeks even after Stable moves to two weeks in September, so the gap between the two widens.

From an IT operations standpoint, nothing in these 370 demands emergency handling. There is no confirmed exploitation, and the Critical entries are seven in-house findings. Rolling it into the normal update cycle is enough. What does warrant breaking the cycle is a case like June's V8 zero-day, where real attacks were confirmed, and a forced update is the right call.

Administrator release notes are published separately from the main announcement and go into more detail on this release.

Once a monthly flood of fixes becomes normal, the raw count stops being useful as a decision input. What matters is how many are Critical, and whether there is any sign of real-world exploitation. Here those answers are seven, and none. Update calmly, and press relaunch.

Sources

• ▸ Chrome Releases - Stable Channel Update for Desktop (Chrome 151, full list of 370) (July 29, 2026)
• ▸ Chrome Releases - Chrome for Android Update (July 29, 2026)
• ▸ The Chromium Projects - Chrome Security 2026 Q2 Update
• ▸ SecurityWeek - Google Patches 382 Chrome Vulnerabilities (with correction note to 433 / Chrome 150) (July 1, 2026)
• ▸ Impress Watch - Google Chrome 151 released, XML parser moves to memory-safe Rust (July 30, 2026)
• ▸ Chrome for Developers - Chrome moves to a two-week release cycle
• ▸ Google Chrome Help - Update Google Chrome
• ▸ Google Chrome Enterprise Help - Chrome release channels
• ▸ StatCounter - Desktop Browser Market Share Japan (June 2026)
• ▸ Security NEXT - 151 vulnerabilities in Chrome, 22 rated Critical (May 29, 2026)