Google pushed Chrome 151 to the stable channel on July 28, 2026, and the release quietly became one of the year’s biggest security drops: 370 vulnerabilities fixed in a single build, seven of them rated critical. That volume alone would justify the headlines it got. Within days, though, a chunk of the tech press blurred the story together with a different one, a V8 zero-day patched back in June, and the two got treated as a single event across social feeds and aggregator roundups.
They are not the same story. Chrome 151 clears out a backlog that Google’s own engineers mostly found themselves, and none of the 370 fixes are confirmed as exploited before the patch shipped. The actual active zero-day, CVE-2026-11645, went out five weeks earlier in an emergency release. Sorting out which is which matters for any IT team deciding how fast to roll out the update, and it says something about how Chrome vulnerabilities get triaged now that the browser holds roughly 70% of the global market, according to Statcounter — a scale Forbes put a number on when it reported that roughly 3.5 billion Chrome users were warned in a zero-day alert on April 3, 2026.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Chrome 151 Actually Patches
Chrome 151 landed as version 151.0.7922.71/.72 for Windows and macOS and 151.0.7922.71 for Linux, according to Google’s own Chrome Releases blog. The update rolls out gradually over days and weeks, so not every user saw the prompt on July 28 itself, but the build was live and public from that date. Inside it: 370 security fixes, the largest batch tied to a single Chrome stable release so far this year. Google kept shipping point releases on top of that baseline through August 2026: 151.0.7922.108/.109 landed on August 6 with 41 more fixes, 151.0.7922.137/138 followed on August 11 patching five high-severity use-after-free bugs, and 151.0.7922.169 added another 15 fixes later that month, per the Chrome Releases blog, GBHackers and IntelFusions.
Seven of those fixes are rated critical, tracked as CVE-2026-17650 through CVE-2026-17656. Another 71 are rated high severity, which puts the combined critical-and-high count at roughly 80, a figure SecurityWeek used in its own write-up of the release. The rest of the 370 span medium and low severity issues, the kind of hardening fixes that rarely make headlines but close off smaller attack paths over time. For a browser this widely deployed, even the “routine” chrome vulnerabilities in that lower tier matter at scale.
The Seven Critical Bugs and Where They Live in the Browser
The critical bugs cluster around a familiar bug class: use-after-free memory errors, the kind that can let an attacker hijack freed memory to run arbitrary code. Infosecurity Magazine’s reporting ties several of the critical issues to Compositing, Views, Skia and Ozone, all components involved in how Chrome renders and draws what’s on screen. The same bug classes keep dominating later releases: SecurityWeek reported that Chrome 156 patched 163 memory-corruption bugs and resolved 125 use-after-free vulnerabilities in October 2026. A separate set of critical bugs involves insufficient validation of untrusted input in Dawn, Chrome’s WebGPU implementation, and ANGLE, the graphics layer that translates Chrome’s rendering calls for different hardware.
What stands out is who found them. Google’s own security team reported the critical vulnerabilities between May 18 and June 14, 2026, weeks before the July 28 ship date. That gap is the normal cadence for a large browser vendor: find internally, build a fix, hold it until the patch is ready to go out broadly rather than tipping attackers off early. It also reinforces that this release, unlike some past Chrome updates, was not a scramble to contain an in-progress attack. It was scheduled hardening, just an unusually large batch of it.
No, Chrome 151 Is Not a Zero-Day Patch
Here’s where the story got tangled. At least one aggregator site published a piece with a headline implying Chrome 151 shipped fixes for an actively exploited V8 zero-day. That claim traces back to CVE-2026-11645, a real V8 zero-day that Google did patch this year, but not on July 28. Google fixed CVE-2026-11645 in an emergency, out-of-band stable release on June 8, 2026, in Chrome version 149.0.7827.102/.103, five weeks before Chrome 151 ever shipped.
The distinction is not just pedantry. A confirmed zero-day carries a different risk profile than a large routine patch batch: it means attackers already had a working exploit before defenders had a fix, which is why Google ships those out-of-band instead of waiting for the next scheduled release. Chrome 151’s 370 fixes, by contrast, are not tied to any confirmed in-the-wild attack. Enterprise security teams that triage patches by urgency should treat these as two separate events with two separate timelines, similar to how Adobe’s ColdFusion zero-day forced same-day emergency patching earlier this year while other ColdFusion updates followed a normal release schedule.
The Real Zero-Day Story: Five Actively Exploited Bugs in 2026
The genuine zero-day story in 2026 is the pace at which Google has had to ship emergency Chrome patches for bugs already under attack. CVE-2026-11645, patched June 8, 2026 in Chrome 149.0.7827.102/103, was the fifth actively exploited Chrome zero-day patched this year, according to BleepingComputer, a run that started in February and didn’t let up — and didn’t stop there either: by September 2026, Google shipped Chrome 152.0.7977.82/.83 with 12 more security fixes, including a sixth in-the-wild V8 bug, CVE-2026-85046, confirming the zero-day pace security teams had been bracing for all year.
| Order | CVE | Patch date | Chrome version |
|---|---|---|---|
| 1 | CVE-2026-2441 | February 13, 2026 | 145.0.7632.75/76 (Win/Mac), 144.0.7559.75 (Linux) |
| 2 | CVE-2026-3909 | March 12, 2026 | 146.0.7680.75/76 |
| 3 | CVE-2026-3910 | March 12, 2026 | 146.0.7680.75/76 |
| 4 | CVE-2026-5281 | April 1, 2026 | 146.0.7680.177/178 |
| 5 | CVE-2026-11645 | June 8, 2026 | 149.0.7827.102/.103 |
Two of those five landed on the same day in March, both CVSS 8.8 bugs that Google first reported on March 10, 2026 as CVE-2026-3909 and CVE-2026-3910, meaning Google shipped fixes for two separate actively exploited bugs in one emergency release. The pair was serious enough that CISA ordered US federal agencies on March 13, 2026 to patch both by March 27, 2026. The April 1 entry in that table, CVE-2026-5281, a Dawn use-after-free bug, was Chrome’s fourth zero-day of 2026, according to Security Affairs, and The Hacker News reported it shipped inside a broader 21-vulnerability patch batch in version 146.0.7680.177/178; TechOnPurpose additionally noted Google closed a companion Dawn/WebGPU flaw, CVE-2026-5289, in that same emergency update. That’s a busier zero-day cadence than Chrome saw through most of 2025, and it lines up with a broader pattern security researchers have flagged all year: attackers are finding it worthwhile to burn zero-days on browsers because the payoff, a foothold on virtually any target’s endpoint, rarely requires more than getting someone to load a malicious page.
Severity Breakdown: Where the 370 Fixes Land
Splitting Chrome 151’s fixes by severity shows how much of the release is invisible hardening versus headline-grabbing critical bugs. Critical issues are the minority by count but dominate the risk conversation, since they’re the ones capable of remote code execution outside Chrome’s sandbox. That critical count kept growing after the initial ship date, too: Chrome’s security advisories listed two more critical buffer-overflow bugs, CVE-2026-76034 and CVE-2026-76036, both reported in July 2026 and surfacing in Chrome Releases postings through August 2026.
| Severity | Count | Notes |
|---|---|---|
| Critical | 7 | CVE-2026-17650 through CVE-2026-17656; use-after-free and input-validation flaws |
| High | 71 | Combined critical + high totals roughly 80, per SecurityWeek |
| Medium/Low | ~292 | Remaining fixes across the 370 total; hardening and lower-impact bugs |
| Total fixes | 370 | 349 of 370 (94.3%) reported internally by Google’s own security team |
Why Google Finds Almost All Its Own Bugs Now
The 94.3% internal-discovery rate is arguably the more interesting long-term signal buried in this release, since it shows how many Chrome vulnerabilities never reach an outside researcher at all. A decade ago, headline Chrome patches leaned more heavily on external bug bounty submissions and outside researchers. This release flips that ratio almost entirely in-house. That doesn’t mean the external bug-bounty pipeline has dried up entirely: Google paid out $25,000 for a WebGPU buffer-overflow bug, CVE-2025-11205, reported by an outside researcher on September 12, 2025, according to the Chrome Releases blog, but payouts like that one are now the exception rather than the rule. Google has spent years investing in fuzzing infrastructure and expanding its internal security team, and a 349-of-370 split suggests that investment is finding bugs faster than external researchers can report them.
That’s good news in one sense: bugs found internally get fixed before anyone outside Google knows they exist, cutting the window where a motivated attacker could beat Google to the discovery. It also raises a less comfortable question. If Google’s own team is finding more than 90% of the serious bugs in a codebase this large, how many more are still sitting undiscovered, waiting on whichever side, defender or attacker, happens to look in the right place first.
A Very Big Year for Chrome Patch Volumes
Context helps here. Chrome 148, which shipped in May 2026, fixed 79 vulnerabilities including 14 critical, numbers confirmed independently by both SecurityWeek and PCWorld. Measured against that, Chrome 151’s 370 fixes and seven criticals look like a different kind of release altogether, nearly five times the total bug count even though the critical count actually came in lower.
The Hacker News reported that Google’s three most recent stable Chrome releases combined to fix 1,442 security flaws, with Chrome 151 contributing 370 of that total on its own — and the volume kept climbing into September 2026, when Chrome 153.0.8010.36 shipped with another 230 security fixes, including a critical use-after-free bug in Cast. By October 2026 the batches were larger still: Chrome 155’s desktop update included 247 security fixes, four of them critical according to Malwarebytes, and Chrome 156 fixed 353 flaws, including 6 critical vulnerabilities and 61 high-severity ones, SecurityWeek reported. Whether that reflects a genuinely more dangerous codebase or simply a more aggressive internal audit cycle is hard to say from the outside. Either way, IT teams patching Chrome fleets in 2026 are dealing with a much heavier volume than they saw in prior years.
Where Chrome 151 Stands Among Later Releases
Chrome 151 reached Stable on July 28, 2026, but it is not the current release. The Extended Stable channel was at version 152.0.7977.169 on October 15, 2026, and Google kept issuing Stable, Extended Stable and ChromeOS security releases throughout October 2026. Anyone still reading the 370-fix figure as the newest word on Chrome security should treat it as a snapshot of one release in a longer sequence.
Google’s own announcements that month also show security work moving beyond individual bug fixes. On October 6, 2026, Google said Chrome blocked unauthorized HTTPS certificates through CRLSets after reported hijacks involving the .gh, .sl, and .as country-code domains. On October 20, 2026, Google announced newer Chrome defenses against evolving web scams and described protections for Chrome and Android users against compromised eMudhra intermediate CA certificates. On October 21, 2026, Google said Chrome had rolled out a default prompt asking permission before making insecure HTTP connections.
For administrators, the practical reading is that a fleet pinned near the Chrome 151 baseline is missing both later bug fixes and these behavior changes, so the new HTTP prompt may surface in user reports. Google lists Chrome Enterprise Core at no cost and Chrome Enterprise Premium at $6 per user per month, and the company describes Chrome Enterprise as its offerings for deploying, managing, and securing Chrome in organizations. Checking which build each group of devices actually runs is a sensible first step before deciding how quickly to move.
Chrome’s Market Share Turns Every Patch Into a Global Event
Part of why 370 chrome vulnerabilities in one release matters beyond the security trade press is sheer reach. Chrome’s global browser market share sat at 69.65% in June 2026, per Statcounter GlobalStats, meaning Chrome had the largest global desktop-and-mobile browser share; the phrase “runs through code Google shipped on July 28” is not supported.
| Browser | Global market share (June 2026) |
|---|---|
| Chrome | 69.65% |
| Safari | 15.31% |
| Microsoft Edge | 5.21% |
| Firefox | 3.33% |
| All others (combined) | ~6.5% |
Source: Statcounter GlobalStats, global desktop and mobile combined, June 2026. No single competing browser comes close to Chrome’s share, which is exactly why Chrome’s patch Wednesdays (Google doesn’t stick to a fixed weekday, but releases cluster mid-week) function as something close to a global internet-security event rather than a niche IT bulletin.
Enterprise and ChromeOS Fleets Face the Real Deadline
Chrome 151’s stable channel covers Windows, macOS and Linux, which puts it squarely in front of Chrome Enterprise and ChromeOS device fleets, not just individual consumer installs. The bug classes involved, use-after-free and type confusion in rendering and graphics components, are the same categories security teams have historically watched most closely because they’re the ones that tend to chain into remote code execution or sandbox escapes when combined with a second flaw. ChromeOS fleets track their own build numbers: ChromeOS 16805.33.0 shipped browser version 154.0.8037.151 in October 2026.
Google has also kept detailed technical writeups of the seven critical bugs restricted, a standard practice the company follows until the bulk of the user base has updated. That’s a deliberate trade-off: less public detail slows down attackers trying to reverse-engineer an exploit from the patch, but it also means enterprise security teams have less information to work with when prioritizing their own rollout schedules.
Chrome Enterprise Policy Controls
IT admins managing Chrome fleets can confirm rollout status and force updates through existing Chrome Enterprise policy keys rather than waiting on individual users to click “update.” A typical managed policy for pinning or forcing a version looks like this:
{
"UpdatesSuppressed": false,
"TargetVersionPrefix": "151.",
"AutoUpdateCheckPeriodMinutes": 60
}Setting UpdatesSuppressed to false and clearing any stale TargetVersionPrefix pin is the fastest way to confirm a fleet isn’t being held back on an older, unpatched build.
How Chrome Stacks Up Against Firefox, Edge and Safari
Chrome’s disclosure model, granular per-CVE writeups, a public severity rating for every fix, and a running Chrome Releases blog, is more transparent by default than what Apple publishes for Safari, where security fixes are typically bundled into broader macOS and iOS updates without a standalone per-browser CVE breakdown. That makes a like-for-like numeric comparison difficult: Chrome’s 370-fix count is directly comparable release to release, while Safari’s security posture is harder to isolate from the operating system it ships inside.
Firefox and Edge sit somewhere in between. Mozilla publishes its own security advisories per Firefox release, though Firefox’s much smaller market share, 3.33% globally, while the rest of the sentence about trade-press attention is an unsupported inference. Edge inherits a portion of its rendering-engine fixes directly from upstream Chromium, since Edge has run on the Chromium engine since 2020.
Chromium-Based Browsers Inherit the Same Fixes
Edge, Brave, Opera and Vivaldi all build on the open-source Chromium project that also underpins Chrome, so security fixes to shared components like Blink and V8 typically flow into those browsers on their own release schedules rather than Chrome’s. That doesn’t mean users of those browsers were exposed by Chrome 151’s bugs for as long as headlines about “Chrome” specifically might suggest, but it does mean the true footprint of a Chromium-level fix extends well past Chrome’s own 69.65% share.
Industry Reaction to the Chrome 151 Rollout
Coverage of the release was consistent on the core numbers even where framing differed. Google’s own release notes kept it simple: “This update includes 370 security fixes,” according to the official Chrome Releases blog.
SecurityWeek reported that “Google on Wednesday announced the release of Chrome 151 to the stable channel with patches for 370 vulnerabilities,” echoing the same headline figure trade outlets converged on within hours of the release.
Infosecurity Magazine added detail on severity, writing that “Google’s Chrome security team has released security patches for 370 vulnerabilities affecting the browser, including seven critical ones,” which matches the CVE-2026-17650 through -17656 range Google’s own advisory lists.
Patch-management community trackers picked up the rollout quickly too. A post on the ManageEngine patch-management community confirmed that “Google has released Chrome version 151.0.7922.71/72 for Windows and macOS,” the kind of granular version tracking IT admins rely on to confirm their deployment tools have the right build flagged.
What 370 Patches Means for IT Risk Teams and Budgets
For most security teams, a 370-bug release doesn’t translate into 370 discrete action items. Chrome’s auto-update mechanism handles the overwhelming majority of consumer and even many enterprise installs without manual intervention. The real work falls on organizations running locked-down, version-pinned fleets for compliance or compatibility reasons, where every major Chrome release has to clear a change-management and regression-testing process before it reaches end users, a queue that has not gotten shorter: the 41-fix update on August 6, 2026 and the five-bug high-severity UAF patch on August 11, 2026 both landed inside the same testing pipeline as the original 370-fix release.
That testing burden scales with release size, and 2026’s Chrome releases have been unusually large. Combined with a five-zero-day first half of the year, security teams are effectively running two parallel tracks: an emergency-patch process for actively exploited bugs measured in days, and a much larger routine-patch process for batches like Chrome 151 measured in the normal testing cycle. Budgeting enough engineering time for both tracks, rather than treating every Chrome release as equally urgent, is becoming a real operational planning problem rather than a footnote.
Five Predictions for Browser Security Through the Rest of 2026
- More large batch releases, not fewer. If Google’s internal discovery rate keeps climbing, expect more 300-plus-fix stable releases rather than a return to Chrome 148-sized batches of under 100.
- The 2026 zero-day count likely climbs past five. With five actively exploited bugs patched by early June alone, a browser this attractive a target is unlikely to go the rest of the year without at least one more emergency release.
- Disclosure delays become a bigger flashpoint. As Google withholds more technical detail on critical bugs for longer, expect louder pushback from independent researchers who want faster public writeups for defensive tooling.
- Chromium-based rivals face more scrutiny over patch lag. Expect more reporting that specifically tracks how long Edge, Brave, Opera and Vivaldi take to absorb upstream Chromium fixes after Chrome ships them.
- Enterprise patch SLAs get rewritten around release size, not just severity. More organizations are likely to formalize separate testing timelines for routine-but-massive releases versus confirmed zero-day emergencies, rather than treating every Chrome update the same way.
Historical Context: Browser Security’s Escalating Arms Race
None of this happens in isolation. Vulnerability exploitation broadly has become the dominant way attackers get in the door. Verizon’s latest Data Breach Investigations Report found exploited vulnerabilities overtaking stolen credentials as the top breach vector, at 31%, a shift that helps explain why every major vendor’s patch volumes have climbed in tandem with Chrome’s. The pattern isn’t new to 2026, either: 2025 had its own steady run of Chrome security patches, starting with a cross-origin leak, CVE-2025-4664, fixed before version 136.0.7103.113 in May 2025, and an XSS bug, CVE-2025-5065, fixed in Chrome 137.0.7151.55 Stable on May 27, 2025, per The Hacker News and SentinelOne. Google then patched CVE-2025-5419 (CVSS 8.8) before version 137.0.7151.68 in June 2025, followed by CVE-2025-6554 (CVSS 8.1), its fourth Chrome zero-day of 2025, on July 1, 2025 in versions before 138.0.7204.96, then CVE-2025-6558 (CVSS 8.8) on July 16, 2025, and CVE-2025-10585 (CVSS 9.8) on September 24, 2025 in Chrome 140.0.7339.185. By November 2025, a V8 type-confusion bug, CVE-2025-13223 (CVSS 8.8), had become Chrome’s seventh zero-day of the year, fixed before version 142.0.7444.175, according to NVD/NIST and The Hacker News. Microsoft’s own July cycle told a similar story, shipping a record 570 CVE fixes including two zero-days in a single Patch Tuesday.
Browsers occupy a specific niche in that trend. Unlike a server-side vulnerability that requires an attacker to reach exposed infrastructure, a browser bug just needs a victim to load a page, click a link, or open an ad. That low bar for triggering an exploit is exactly why Chrome, Safari, Edge and Firefox all remain permanent fixtures on enterprise patch-priority lists even in years without a single confirmed in-the-wild incident, and why a year with five confirmed incidents, like 2026 has been so far, tends to reset expectations for how fast “routine” updates need to move.
For ongoing coverage of patch cycles, breach disclosures and exploit trends, see tech-insider.org’s broader cybersecurity coverage.
Frequently Asked Questions
What does Chrome 151 actually fix?
Chrome 151, released to the stable channel on July 28, 2026, patches 370 Chrome vulnerabilities, including seven rated critical and 71 rated high severity. It shipped as version 151.0.7922.71/.72 for Windows and macOS and 151.0.7922.71 for Linux.
Is Chrome 151 a zero-day patch?
No. None of the 370 fixes in Chrome 151 are confirmed as actively exploited before the patch shipped. The V8 zero-day some outlets linked to this release, CVE-2026-11645, was actually patched five weeks earlier, on June 8, 2026, in a separate emergency release.
How do I update to Chrome 151?
Chrome updates automatically for most users. You can force a check by opening Chrome, going to Settings, then “About Chrome,” which triggers an immediate update check and installs the latest version on relaunch. As of September 2026, that latest version is 153.0.8010.36, following Chrome 152.0.7977.82/.83 (12 fixes, including the in-the-wild V8 bug CVE-2026-85046) and the earlier August point releases that layered fixes on top of the original 370-fix Chrome 151 release.
Which CVEs are the seven critical bugs in Chrome 151?
The critical vulnerabilities are tracked as CVE-2026-17650 through CVE-2026-17656, primarily use-after-free issues in components including Compositing, Views, Skia and Ozone, plus input-validation flaws in Dawn and ANGLE.
Are Edge, Brave and other Chromium browsers affected?
Chromium-based browsers such as Microsoft Edge, Brave, Opera and Vivaldi share underlying components with Chrome and typically receive fixes for the same upstream bugs, but on their own release schedules, which can lag Chrome’s stable rollout by days or weeks.
How many Chrome zero-days have been patched in 2026?
Five actively exploited Chrome zero-days had been patched by early June 2026: CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 and CVE-2026-11645. A sixth followed in September 2026, when Chrome 152.0.7977.82/.83 patched an in-the-wild V8 bug tracked as CVE-2026-85046.
Should enterprises treat Chrome 151 as an emergency patch?
Most security teams are treating it as a large, high-priority routine update rather than an emergency, since no bugs in the release are confirmed exploited. Organizations running version-pinned or change-controlled fleets should still prioritize testing given the size of the fix batch and the number of critical bugs involved.
