Chrome Fixes 41 Flaws, Six Critical and Four Android-Only

On August 6, 2026, Google shipped a Chrome update (151.0.7922.108/.109) that fixes 41 security flaws. It lands just one week after the release that fixed 370 at once.

Of those 41, six carry Google's highest rating, "Critical." The previous batch of 370 contained seven Criticals, so even though the total dropped to a ninth of what it was, the number of genuinely dangerous items barely moved. And four of the six affect the Android version of Chrome only.

As of August 7 there is no report of any of them being used in a real attack. All you have to do is update and restart. This article covers the 41 first, then keeps the July 29 story about the 370 below it.

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

This takes three minutes. Here is the procedure from Google's official help page.

Open Chrome, click the "More" icon (three vertical dots) at the top right, then choose "Help" → "About Google Chrome." If an update is available the download starts automatically, and then you press the "Relaunch" button. Until you press it, the fix is not applied even though the download has finished. You are done when it says "Chrome is up to date."

Relaunching reopens your tabs and windows, but as the help page states, Incognito windows are not restored. If you are in the middle of something in an Incognito window, note the URLs before relaunching.

Android is the main target this time, so do not leave your phone for later. On Android, update from the Play Store profile under "Manage apps & device"; on iPhone, from the App Store profile under "Update." The Android release note states that "Android releases contain the same security fixes as their corresponding Desktop releases."

Do not worry about whether your build ends in ".108" or ".109." Google ships the same content under several numbers in a staged rollout, and Chrome updates itself if you leave it alone. The only thing to check is whether you are on the latest 151 build, on the "About Google Chrome" screen.

Edge, Brave, Vivaldi and Opera all run on the same Chromium base, so they carry the same holes. It takes each vendor a few days to two weeks to ship a matching build, so check those updates too.

Who wants a hole like this

The first buyers for bugs that skew toward the phone browser are not people who resell stolen handsets. They are vendors of surveillance tooling that plants itself on a device and records everything its owner does. A phone holds call logs, location history, photos and authenticator codes — it is far closer to "the person" than a laptop is. That is why, for the same class of bug, the ones that work on Android command a much higher price.

The method is remarkably plain: get someone to open one link, slipped into a direct message or an ad. That alone can be enough to step over the wall of the "sandbox," the cage in which the browser confines web pages. That is what these six Criticals are. No suspicious download, no password prompt.

What follows depends on who you are. For an individual, saved passwords and login state (cookies) get lifted, and someone walks straight into your social accounts and online banking. Two-factor authentication helps less than you would hope if the authenticator app lives on the same device. For a company, if staff reach internal systems from personal phones, that one handset becomes the door into the network. So the "later" in "I'll update later" is exactly the length of time that door stays open.

The six most dangerous of the 41

Google rates flaws on its own four-step scale: Critical, High, Medium and Low. This batch is 6 Critical and 35 High, with no Medium and no Low at all. That is a completely different shape from the 370, which was padded out with 170 Medium and 122 Low.

Among the six Criticals, pay closest attention to the three with no precondition. Google's descriptions come in two forms. Where it says "a remote attacker who had compromised the renderer process," the bug does not work on its own — it needs to be chained with another. Where that clause is absent, it means getting you to open a crafted page may be enough to reach outside the cage. Three of the six are the latter.

CVE-2026-19170: WebGL on Android, out of the cage just by opening a page

WebGL is the mechanism that lets a web page drive the device's graphics hardware directly for 3D rendering. A use-after-free was found there — memory that had been released gets used again. The NVD entry carries no precondition clause, meaning a crafted page alone may be enough to escape the sandbox. Android only.

It was reported by Muhammad Alifa Ramdhan, Pan ZhenPeng and Billy Jheng Bing Jhong of STAR Labs SG, a Singapore-based security research team that has won Master of Pwn at Pwn2Own. Reported July 22, fixed August 6 — 15 days. The fastest turnaround of the six.

CVE-2026-19157: Out-of-bounds write in ANGLE on Android

ANGLE is the layer that translates graphics calls from web pages into each operating system's own drawing API. This is an out-of-bounds write, and it too carries no precondition. ANGLE was also where 30 of the previous 370 clustered; because it handles values that come straight from the outside, validation gaps are easy to leave behind. Found in-house at Google on July 14. Android only.

CVE-2026-19149: Aura on Linux, out of the cage just by opening a page

Aura is the layer that handles windows, menus and other UI surfaces on Linux and similar platforms. This is a sandbox escape with no precondition, and if you run Chrome on Linux this is the heaviest single item in the batch. Found in-house on June 17. CVE-2026-19147, rated High, was fixed in the same component at the same time.

CVE-2026-19137: A second WebGL bug on Android, four months in the making

Same component and same bug class as CVE-2026-19170, but this one assumes an attacker who has already compromised the renderer. It does not work alone. What stands out is the timeline: reported April 5, 2026, fixed August 6 — four months. The reporter is anonymous and the bounty field still reads "TBD."

CVE-2026-19154: Skia, the drawing library, on Android

Skia is the shared rendering engine that Chrome and Android itself use to draw shapes and text. Because it is embedded in products beyond Chrome, this class of bug is hard to trace from outside. This one requires a compromised renderer, and was found in-house on July 9. Skia accounts for five of the 41, tied for the most of any component.

CVE-2026-19172: Views, the browser's own chrome, on every platform

Views draws the browser's own interface — tabs, buttons and so on. It sits outside the part that renders web pages, which is to say outside the cage to begin with, so a hole here has direct consequences. It is the only one of the six that affects every operating system. It requires a compromised renderer, and was found in-house on July 22. CVE-2026-19142, CVE-2026-19158 and CVE-2026-19159, all High, were fixed in Views at the same time.

Reading this as "370 down to 41" gets it wrong

Set against last week's 370, forty-one looks like a ninth as much. It looks calm. But the picture changes once you compare like with like.

Add Critical and High together and you get 78 on July 29 against 41 on August 6. That is only about half as many. The total looks nine times smaller only because the Medium and Low items that hung off the previous release are entirely absent this time.

Google published nothing below High for these 41 and gave no reason. It may be that the scope of what gets listed differs between the monthly major release (370) and the fixes shipped in between (41). Either way, putting two raw counts side by side tells you nothing — that is the practical lesson here. What matters is how many Criticals there are and whether anything has been used in a real attack. This time: six, and none.

The bug classes skew too. Twenty-one of the 41 are use-after-free, exactly half. That is the kind of bug that comes with managing memory by hand in C++, and it is why Google replaced Chrome 151's XML parser with a Rust implementation.

The dangerous places differ between phone and desktop

Split the 41 by platform and the character of this release becomes obvious.

Four of the six Criticals are Android-only and one is Linux-only. Not a single Critical is Windows-only. Windows-only items number just four in total, so if you look only at desktops you will read this release as a non-event.

The concentration of graphics code (WebGL, Skia, ANGLE, GPU) on the Android side is no accident. Phones combine GPU vendors and drivers in a different mix on every model, which makes them harder to test than desktops. Bugs survive longer there, which is why attackers dig in that direction first — the same reason the WebGPU code has a track record of being used in real attacks.

One piece of good news: Chrome for Android ships through Google Play rather than through the handset maker, so even devices that no longer receive OS updates can still run the latest Chrome. "My phone is too old" is not a reason to give up here.

Why you cannot find a severity score for these

If you looked up CVE-2026-19170 and found no numeric severity, that is normal.

Vulnerabilities usually carry a CVSS score from 0.0 to 10.0. But Google Chrome does not assign CVSS to the CVE IDs it issues. All you get is Google's own four-step scale, and all 41 entries in the US government's National Vulnerability Database (NVD) are published with the score field empty. NVD sometimes scores them later on its own: for the previous batch, CVE-2026-17650 received a CVSS of 8.3 on August 6. So the numbers can arrive months after the fact — that is all.

"No CVSS" does not mean "safe" or "not yet assessed." It just means this is how Google publishes. Google's four-step scale is enough to decide on. Vulnerabilities confirmed to be under active attack are published by the US government's CISA in a list called KEV, and past Chrome zero-days appear there. You can search it through our Japanese-language KEV dashboard; we checked the August 6 catalog (1,661 entries) and none of the 41 appear. The most recent Chromium entry in KEV is CVE-2026-11645 (V8), added June 9.

Who found them. An AI company's name appears on its own

The biggest change in this batch is in the reporter column. Twenty-nine were found inside Google and twelve came from outside — 29% external. In the previous 370, only 21 were external (5.7%), so the share is five times higher.

Two of those twelve external reporters are not human.

The first is CVE-2026-19168 (V8, High), credited as "Reported by XBOW and triaged by Andrés Luksenberg." XBOW sells an AI that runs penetration tests without human direction, and is known for reaching number one on HackerOne's US leaderboard in June 2025, ahead of every human. HackerOne subsequently split the human and machine rankings. The bounty was $500.

The second is CVE-2026-19162 (V8, High), credited as "Reported by OpenAI Codex Security (amyb)" — the code-review agent OpenAI launched in March 2026. This is the difference from last time. The same name appeared in the 370 on July 29, but as "Duc Nguyen of Calif.io in collaboration with OpenAI Codex Security" — jointly credited with a human researcher. This time the human collaborator is gone, leaving only the company name and a handle.

Until now, whenever anyone said "an AI found this vulnerability," a person was standing next to it. This is the first time that person's name is absent from a Chrome release note.

The other ten are human. Seunghyun Lee (@0x10n), who reported the V8 bug CVE-2026-19174, was the top-ranked Chrome bounty researcher in both 2024 and 2025 and holds more than 20 CVEs in V8 alone; he filed this one under the audit firm QED Audit. The largest payout, $5,000, went to CVE-2026-19169 (Contextual Tasks, High), reported by Sven Dysthe.

Bounties are now a tenth of what they were

Look at the amounts and the drop is plain. Only two bounties are stated in this release — $5,000 and $500 — and all six Criticals read either "N/A" (found in-house, not eligible) or "TBD."

This is not a coincidence; the program changed. In April 2026 Google revised its Chrome and Android reward programs, resetting the base payout for memory-safety bugs to $500, with multipliers applied for reachability and exploitability. According to SecurityWeek, researchers say some Chrome bug rewards are now ten times smaller than before. The same revision raised the top Android device payout from $1 million to $1.5 million: browser bugs cheaper, device takeover dearer.

The reason Google gives is AI. The Chromium project's 2026 Q2 report puts it this way.

The logic being: if internal AI finds it first, there is no reason to pay for the same thing brought in from outside. Google has also put conditions on how reports are written. AI has made it effortless to produce long, detailed write-ups, the company notes, but its internal tooling can now explain and suggest fixes automatically — so it now asks for a reproducer and the minimum artifacts needed to validate the issue. The thick report the AI wrote gets read by an AI and thrown away. That is the door we are walking through.

What the 370 on July 29 actually were

From here on, the story of a week earlier. On July 29, 2026 Google shipped Chrome 151 (151.0.7922.71/.72) for desktop, fixing 370 vulnerabilities in one go. Windows and Linux got .71, Mac got .72. Both the 370 and the 41 sit inside the same 151 line, so updating now clears both.

The 370 broke down as 7 Critical, 71 High, 170 Medium and 122 Low. Medium and Low dominated at 292 combined, nearly 80% of the total. All seven Criticals were found inside Google, reported between May 18 and June 14. Here they are.

CVE-2026-17650: Use-after-free in the compositing code

Compositing is the part that stacks layers to paint the screen. A use-after-free there means released memory gets used again; if an attacker can place their own data in the freed region, they can steer the program's execution. The NVD entry was updated on August 6, 2026 with a CVSS score of 8.3 assigned after the fact. Reported May 18, 2026.

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

Dawn underpins WebGPU, which lets a web page use the machine's graphics hardware directly. Validation of untrusted input was insufficient, so unexpected values break it. Chrome's WebGPU code is an area with a history of real-world exploitation in 2026, which is why Google treats it seriously. Reported May 28.

CVE-2026-17652: Use-after-free in Views, the window-drawing component

Views draws the browser's own UI — tabs, buttons and the rest. It sits outside the part that renders web pages, so a hole here has direct consequences. Views also accounted for four fixes in the August 6 batch, so it is under continuous work. Reported June 2.

CVE-2026-17653: Use-after-free in the Skia drawing library

Skia is the shared rendering engine Chrome and Android use to draw shapes and text. Because it is embedded in other products too, the blast radius of this class of bug is hard to trace. Reported June 5.

CVE-2026-17654: A race condition in the auto-update mechanism itself

The Updater — the resident process that keeps Chrome current — had a race condition that breaks when operations arrive out of order. Update machinery typically runs with near-administrative privileges, so a hole there leads to privilege escalation. It was the only one of the seven Criticals that could 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 on Windows and equivalents elsewhere. Thirty of the 370 were ANGLE-related, the second-largest component group. The August 6 batch includes CVE-2026-19157 in the same component, rated Critical on Android. 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 Chrome OS are affected. Reported June 14. On August 6, Aura's CVE-2026-19149 landed as a Linux Critical, so the Linux build has now taken a top-severity hit twice in a row.

By component, the largest group in the 370 was, surprisingly, Chrome for iOS at 35. Then ANGLE at 30, DevTools at 18, password management at 16, extensions at 14 and the V8 JavaScript engine at 11. By bug class, "inappropriate implementation" led with 128, followed by insufficient input validation at 70 and use-after-free at 49.

One of the 370 came from an external open-source component: CVE-2026-17705, an integer overflow in libxml reported by ebassi of Igalia. If you want to know what third-party components your own software is carrying, we also run a scanner where you paste in your dependency list.

Why one update fixes hundreds. Google has AI doing the looking

Of the 370, 349 were "Reported by Google" — found in-house. Only 21 came from outside researchers, bounties were paid on eight of them, and the total came to $58,500 (the largest single award, $36,000, went to CVE-2026-17657, a navigation flaw). Fixing hundreds while paying out that little tells you where discovery has moved.

Google explains the reason itself. The Chromium project's Chrome Security report for Q2 2026 contains this line.

The same report says of Big Sleep, the vulnerability-hunting AI built jointly by Project Zero and DeepMind, that "the Big Sleep agent now operates as a fully automated pipeline, helping secure V8." According to an ITmedia report on August 5, Chrome 149 and 150 alone accounted for 1,072 fixed vulnerabilities, with Google running large-scale code inspection around the clock.

Worth being careful here: Google says AI is why the count went up, but has never said AI found these 370. All 349 in-house items are rolled up as "Reported by Google," with no breakdown of which came from AI. Counting through Chrome release notes since August 2024, the name "Google Big Sleep" is credited in only a handful of posts clustered in 2025, and not once in any 2026 release note. The only AI names that do appear belong to other companies — XBOW and OpenAI Codex Security.

One more thing changes how the numbers look: Google changed how it writes up in-house bugs. Up to the September 30, 2025 release note, internally found bugs were collapsed into a single line — "Various fixes from internal audits, fuzzing and other initiatives" — with no CVE IDs at all. That line vanished from October 2025 onward, and in-house bugs now each get their own CVE. Fix the same number of bugs, change only the write-up, and the count jumps.

Google itself writes 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. There is no official statement on how the two split the difference, so it cannot be separated from outside.

"Chrome 151 fixed 382" is going around, but that was 150

Search and you will find articles and posts saying "Chrome 151 fixes 382 vulnerabilities, 15 of them Critical." This is neither the 370 nor the 41, and both the number and the version are wrong.

The origin was Google's own mistake. The release on June 30, 2026 was Chrome 150, but the announcement initially said "151" and "382." Google corrected both; the true figure is 433 fixes in Chrome 150. SecurityWeek's article still carries the correction note at the end.

The problem is that aggregator sites which copied the pre-correction snapshot still say "Chrome 151 = 382." It spread into Japanese too; here is a post from June 30.

That is not the poster's fault — given what Google's announcement said at the time, it was accurate.

By contrast, as of August 7 there is no Japanese coverage of the 41 fixes from August 6 that we can find. Even in English, only Germany's it-blogger.net notes it as a version bump; SecurityWeek and BleepingComputer are still on the 370 story. The habit is clear enough: the big batch at a major-version boundary gets reported, and the fixes in between get dropped.

One more confusing headline is "151 vulnerabilities in Chrome." That is not version 151 — it is Security NEXT's May 29 story about Chrome 148, which happened to fix 151 issues. Because the version number and the count are the same digits, it ranks high for "Chrome 151." Always check the version number in the article body.

429 → 433 → 370 → 41: how the counts moved

The impression that every release now runs to 400-odd fixes has spread, but here is the actual sequence. Every figure is counted from Google's own announcements.

The hundreds appear when the major version rolls over, with a month's worth booked at once. In between come small updates: 15 fixes on July 14, four on July 23, and no security section at all for 151.0.7922.75/.76 on August 4. At 41, this release is unusually large for an in-between one.

The picture shifts again in September. Google has announced that from Chrome 153 on September 8, the release interval drops from four weeks to two. Per-release counts should look roughly half as large. Work is also progressing on restartless updates: on macOS, Chrome 150 added behaviour where an update applies at next launch if every window is in the background.

If this is a work machine

Chrome's desktop share in Japan is 65.4% (StatCounter, June 2026), below the global 72.24%, with Edge at 22.2% — more than double the world average. That is what a country full of corporate-issued Windows machines looks like, and since Edge shares the same base, IT departments have to watch both.

For enterprises there is a separate track called Extended Stable. According to Google Chrome Enterprise help, regular Stable updates on a short cycle while Extended Stable runs on eight weeks: fewer feature changes, but security fixes still arrive at the shorter interval.

Two caveats. First, Extended Stable only exists for even-numbered versions, so 151 is out of scope; the August 6 release there is 150.0.7871.224. Second, Google has said that Extended Stable stays on eight weeks even after Stable moves to two in September, so the gap between them widens.

From an IT perspective, nothing in these 41 demands emergency handling. There is no confirmed exploitation, and the Criticals are ordinary in-house and researcher reports. That said, if staff use Chrome for Android on personal or company phones, that is worth addressing before the desktops. Four of the six Criticals are Android-only, and two of those can work just from opening a page. If your MDM reports Chrome versions, the fastest move is to list every device below 151.0.7922.108.

Admin-facing release notes are published separately from the main announcement.

Once fixes arrive several times a month, the raw count stops being useful as a signal — all the more so when "370" and "41" land a week apart. What to look at is not the total but how many Criticals there are, which platforms they hit, and whether anything has been seen in a real attack. This time: six, mostly Android, and none. Update both your phone and your computer, and restart.

Frequently asked questions

I just updated in July. Do I need to update again?

Yes. The July 29 update (151.0.7922.71/.72) does not include the 41 fixes from August 6. Open "About Google Chrome" and check that you are on 151.0.7922.108 or later.

Do I have to update Chrome on my phone too?

The phone is the main event this time. Four of the six highest-rated flaws affect the Android build only, and two of those can work just from opening a crafted page. Update from the Play Store.

What about Chrome on iPhone?

Version 151.0.7922.112 shipped for iPhone and iPad on August 6, but Google's note says only "stability and performance improvements," with no security fixes listed. Chrome on iOS uses Apple's WebKit, so its internals differ from the desktop build. Updating is still worth doing.

Could these already be under attack?

As of August 7 there is no report of any of the 41 being used in a real attack. None appear in the August 6 edition of CISA's Known Exploited Vulnerabilities (KEV) catalog either.

I use Edge or Brave. Does this affect me?

It does. Both are built on the same Chromium base and carry the same holes. It takes each vendor a few days to two weeks to ship a matching build, so check those updates too.

Sources

• ▸ Chrome Releases - Stable Channel Update for Desktop (151.0.7922.108/.109, full list of 41) (August 6, 2026)
• ▸ Chrome Releases - Chrome for Android Update (151.0.7922.108) (August 6, 2026)
• ▸ Chrome Releases - Chrome Stable for iOS Update (151.0.7922.112) (August 6, 2026)
• ▸ Chrome Releases - Extended Stable Update for Desktop (150.0.7871.224) (August 6, 2026)
• ▸ Chrome Releases - Stable Channel Update for Desktop (Chrome 151, full list of 370) (July 29, 2026)
• ▸ The Chromium Projects - Chrome Security 2026 Q2 Update
• ▸ Google Bug Hunters - Evolving the Android & Chrome VRPs for the AI Era
• ▸ SecurityWeek - Google Adjusts Bug Bounties: Chrome Payouts Drop as Android Rewards Rise Amid AI Surge
• ▸ Dark Reading - An AI-Driven Pen Tester Became a Top Bug Hunter on HackerOne (XBOW)
• ▸ The Hacker News - OpenAI Codex Security Scanned 1.2 Million Commits (March 2026)
• ▸ STAR Labs - Pwn2Own Berlin 2025: Master of Pwn
• ▸ Impress Watch - Chrome 151's security fixes are unusually large, addressing 370 vulnerabilities (Japanese) (July 30, 2026)
• ▸ Security NEXT - Security update for Chrome: 370 vulnerabilities fixed (Japanese) (July 30, 2026)
• ▸ ITmedia Enterprise - Will restarting the browser become unnecessary? Chrome's two-week releases and restartless updates (Japanese) (August 5, 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)
• ▸ CISA - Known Exploited Vulnerabilities Catalog (August 6, 2026 edition, all 1,661 entries checked)