
Update Chrome Now: 382 Security Vulnerabilities Patched, Including 15 Critical Bugs
Summarize this blog post with: ChatGPT | Perplexity | Claude | Grok
Google shipped Chrome 151 to the stable channel on June 30, 2026, and the headline number is striking: 382 security vulnerabilities patched in a single update, including 15 rated Critical and 67 rated High. The Critical vulnerabilities are concentrated in exactly the components where Chrome bugs matter most — GPU, Extensions, Bluetooth, WebUSB, Chromoting, and the core browser infrastructure — and 11 of those 15 are use-after-free bugs, the memory-safety error class that attackers most reliably turn into code execution. The reassuring context is that 358 of the 382 fixes were found by Google itself through internal automated tooling before any attacker could find them, and Google has confirmed no exploitation in the wild. But the remaining 24 were reported by external researchers, who earned bounties ranging from $2,000 to $36,000 — and the gap between "researcher found it" and "attacker weaponized it" is reliably short. If Chrome on your system has not restarted since June 30, you need to restart it now.
## Key Takeaways
- ▸Chrome 151 (build 150.0.7871.46/.47) shipped June 30, 2026, patching 382 security vulnerabilities across Windows, macOS, Linux, and Chrome for iOS — making it one of the largest single Chrome security releases on record.
- ▸15 Critical-severity CVEs (CVE-2026-13774 through CVE-2026-13788) cover use-after-free bugs in Extensions, GPU, Browser, Bluetooth, WebUSB, Views, Chromoting, and Ozone, plus type confusion in Dawn and input validation failures in ANGLE, Skia, and iOSWeb.
- ▸11 of the 15 Critical vulnerabilities are use-after-free bugs — the memory-safety error class where a freed memory region is subsequently accessed, and which attackers can exploit to redirect code execution by controlling what gets written into that freed region before it is referenced again.
- ▸CVE-2026-13789 (GPU use-after-free, High severity) earned a $36,000 bug bounty — the largest single payout in this batch and a strong proxy signal for the flaw's severity and exploitability. Google calibrates bounties against exploit reachability and potential impact.
- ▸358 of the 382 vulnerabilities were found internally by Google — through automated tooling including AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, and fuzzing techniques — before any external attacker had the opportunity to discover them.
- ▸No exploitation in the wild has been reported — this update is preventive security maintenance rather than emergency incident response. However, given that 24 vulnerabilities were reported externally with known bounty payouts, PoC code may be in development among the researcher community.
- ▸Chrome 151 arrives just weeks after Google's emergency Chrome 149 zero-day patch — making this the fifth actively exploited Chrome zero-day of 2026 patched (during the Chrome 149 emergency), followed by this large accumulation of non-zero-day fixes in Chrome 151.
- ▸The surge in Chrome CVEs is likely AI-driven — Google has significantly accelerated vulnerability discovery through AI-assisted fuzzing and code analysis, though Google has not disclosed which specific AI tools are generating this increased detection rate.
## What Is Chrome 151 and How Large Is This Update?
<cite index="37-1">Google on Tuesday announced the release of Chrome 151 with patches for 382 vulnerabilities, the vast majority of which were discovered by the tech giant itself.</cite> The stable channel update rolled out June 30, 2026, targeting Windows, Mac, Linux, and Chrome for iOS users simultaneously, with Android receiving Chrome 150.0.7871.63 carrying the same security fixes.
To put the 382-vulnerability count in perspective: <cite index="30-1">that's a huge jump from the previous Stable update covered last week, which addressed 18 vulnerabilities, including four critical ones.</cite> The scale reflects that Chrome 151 accumulated fixes across a full development cycle rather than representing 382 separately discovered vulnerabilities all emerging simultaneously. The Chrome development and security teams run continuous automated fuzzing and code analysis that generates a constant stream of findings — Chrome 151 bundles all of them into a single stable release.
<cite index="37-1">Of the 382 vulnerabilities, 358 were found by Google. The company has discovered and patched hundreds of Chrome flaws in recent months, a surge likely driven by AI. However, it has shared no details on which specific AI tools are driving the surge.</cite> The high proportion of internally discovered bugs is the most reassuring element of this release — it means the Chrome security team is finding these vulnerabilities before attackers do, through the automated tooling pipeline that is specifically designed to catch them early.
The severity breakdown across all 382 fixes: <cite index="37-1">fifteen of the newly patched vulnerabilities have been assigned a 'critical' severity rating, and 67 have been rated 'high severity'. Of the remaining flaws, 169 have a 'medium' and 131 have a 'low' severity rating.</cite> For most users, the 15 Critical and 67 High-severity vulnerabilities are the ones requiring immediate action — the medium and low-severity fixes are important for long-term hardening but are significantly less likely to be exploited in near-term attacks.
## The 15 Critical CVEs: What Is Vulnerable and Why It Matters
The 15 Critical-severity vulnerabilities run consecutively from CVE-2026-13774 through CVE-2026-13788, targeting components across Chrome's hardware interface layer, extension framework, remote access infrastructure, and platform-specific networking stack. Google assigns Critical severity specifically to bugs that could allow an attacker to execute arbitrary code outside the browser's sandbox — the highest tier on its rating scale.
<cite index="36-1">Use-after-free flaws make up most of the Critical-severity bugs, spread across Extensions, GPU, Browser, Bluetooth, WebUSB, Views, Chromoting, and Ozone components, plus type confusion and validation failures.</cite>
Extensions (CVE-2026-13774)
A use-after-free in Chrome's Extensions infrastructure is the first of the Critical CVEs and among the most broadly impactful. Extensions operate with elevated trust relative to normal web content — they have access to browser APIs, tab management, history, and can interact with web pages in ways that standard web content cannot. A use-after-free in the Extensions component could allow an attacker who can deliver a malicious extension, or who can trigger the flaw through a web page interacting with the Extensions API, to achieve code execution with extension-level privileges.
GPU (CVE-2026-13775)
A Critical use-after-free in Chrome's GPU component. GPU vulnerabilities are among the most historically weaponized in Chrome exploitation — the GPU process handles rendering for web content and has access to hardware acceleration interfaces that provide memory and execution primitives useful for exploitation. <cite index="38-1">Prior Chrome campaigns have frequently abused GPU and rendering bugs as reliable exploitation primitives.</cite>
Chromoting — Remote Desktop (CVE-2026-13779, CVE-2026-13787)
Two Critical CVEs target Chromoting, Chrome's remote-desktop functionality. <cite index="38-1">Chromoting, Chrome's remote-desktop functionality, receives multiple critical fixes (CVE-2026-13779 and CVE-2026-13787), underscoring the risk that memory corruption in remote-access code can directly lead to full session takeover, lateral movement, or data exfiltration in enterprise environments that rely on remote administration.</cite> Remote desktop vulnerabilities carry amplified enterprise risk — a successful exploit of Chromoting does not just compromise the local browser session but can provide access to the remote system being administered.
Bluetooth (CVE-2026-13785)
A Critical use-after-free in Chrome's Bluetooth implementation. <cite index="38-1">A critical Bluetooth bug (CVE-2026-13785) further expands the attack surface to nearby devices.</cite> Bluetooth vulnerabilities in browsers are particularly relevant in enterprise and public-space contexts where devices are in proximity to potential attackers. Unlike purely remote web-based attacks, a Bluetooth-triggered exploit requires physical proximity — but in office environments, conference venues, and co-working spaces, this is a realistic attack surface.
WebUSB (CVE-2026-13778)
A Critical use-after-free in Chrome's WebUSB implementation. WebUSB allows web pages to communicate directly with USB devices, and vulnerabilities in this interface could allow a malicious web page to exploit the bug during USB device enumeration or communication. <cite index="39-1">Security teams should prioritize testing and rolling out Chrome 151 across managed fleets, paying particular attention to environments that rely heavily on extensions, remote desktop (Chromoting), WebUSB, WebXR, Chromecast, and Chrome for iOS.</cite>
Views (CVE-2026-13783, CVE-2026-13784)
Two Critical use-after-free bugs in Chrome's Views UI framework — the component responsible for rendering Chrome's own interface elements. Views vulnerabilities can be leveraged to corrupt the browser's UI state or gain code execution through the browser process itself rather than through the renderer.
Dawn — Type Confusion (CVE-2026-13776)
A Critical type confusion bug in Dawn, Chrome's WebGPU graphics abstraction layer. Type confusion bugs in graphics components are particularly exploitable because they allow attackers to cause the GPU pipeline to process attacker-controlled data as code or pointers, often providing a reliable path to code execution.
ANGLE and Skia — Input Validation (CVE-2026-13780, CVE-2026-13781)
Critical input validation failures in ANGLE (Chrome's OpenGL ES implementation layer) and Skia (Chrome's graphics library). Both components handle untrusted data from web content — validation failures in either can allow malformed graphics input to trigger memory corruption.
Browser and Ozone (CVE-2026-13782, Additional)
A Critical use-after-free in the core Browser component and additional Critical bugs in Ozone, Chrome's display platform abstraction layer on Linux. Core Browser component vulnerabilities are the highest-impact category — they operate in the browser process with elevated privileges relative to the sandboxed renderer process.
## The High-Severity Bug Earning a $36,000 Bounty
Among the 67 High-severity vulnerabilities patched in Chrome 151, one stands out sharply in terms of implied risk and exploitability.
<cite index="33-1">CVE-2026-13789, a use-after-free in the GPU component reported by an external researcher, earned $36,000, by far the largest reward in this batch and a notably high single payout for a Chrome bug.</cite> The official vulnerability description explains why: <cite index="32-1">CVE-2026-13789, "Use after free in GPU in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page."</cite>
This description identifies a sandbox escape path — the most consequential capability in Chrome exploitation. Chrome's security architecture relies on process isolation and sandboxing to contain the impact of renderer-level compromises. A renderer process compromise (typically achieved through a vulnerability in JavaScript engine, DOM handling, or other web content parsing) allows code execution within the renderer's restricted sandbox. A sandbox escape allows an attacker to break out of that sandbox and execute code in the browser process or the underlying OS — significantly amplifying the impact of any initial compromise.
<cite index="33-1">The size of that $36,000 award is a decent proxy for how serious and hard-to-find the underlying GPU flaw was; Google scales its bounties to a bug's severity and exploitability.</cite> The fact that this is a High-severity (not Critical) bug despite its sandbox escape capability likely reflects that it requires a prior renderer compromise as a prerequisite — it is not a standalone critical bug, but a second-stage escalation in a multi-bug exploit chain.
Two additional High-severity bugs earned notable payouts: <cite index="33-1">CVE-2026-13790 (an information leak in Scroll) and CVE-2026-13791 (an input validation flaw in Downloads), each earned $10,000. The rest of the paid High-severity bugs ranged from $2,000 to $4,000.</cite>
## The Chromecast Cluster: IoT and Home Network Risk
Beyond the desktop browser components, Chrome 151 patches a significant cluster of High-severity vulnerabilities in Chromecast — a component that bridges desktop Chrome with home and enterprise media infrastructure.
<cite index="38-1">The cluster of high-severity issues in Chromecast (integer overflows, heap buffer overflows and use-after-free conditions, including CVE-2026-13796 through CVE-2026-13804) demonstrates that media-casting and IoT-adjacent features remain fertile ground for attackers targeting home and enterprise networks.</cite>
Chromecast vulnerabilities carry specific risk in enterprise environments with digital signage, conference room displays, and remote presentation infrastructure that rely on Chromecast functionality. An attacker who can exploit a Chromecast vulnerability through a malicious web page could potentially reach not just the browser but the casting infrastructure connected to it — widening the blast radius beyond the workstation to include display systems and media infrastructure on the same network segment.
## Why the 382-Bug Count Is Not a Sign Chrome Is Uniquely Broken
The 382-vulnerability headline number will be widely reported, and it deserves accurate framing to avoid mischaracterizing what it signals about Chrome's security.
<cite index="33-1">The honest read isn't "Chrome was catastrophically broken"; it's that a huge, security-critical piece of software with billions of users generates a constant stream of bugs, and Google's machinery for finding and fixing them internally is doing its job at scale. The high proportion of Google-found bugs is a feature, not a failing.</cite>
<cite index="32-1">Google uses internal code sanitizer tools and fuzzing techniques to find these vulnerabilities. It probably also helps that it is on the list of companies that are allowed to use advanced AI platforms to help them find these vulnerabilities.</cite> The surge in Chrome CVE counts over recent months — Chrome 148 patched 151 vulnerabilities, Chrome 149 patched 18 in its emergency update, Chrome 151 patches 382 — reflects accelerating internal detection capability, not accelerating vulnerability introduction rate. Google is finding and fixing more bugs per cycle than before, primarily through improved automated tooling.
The comparison that matters for users is not the absolute count of bugs fixed but whether they have the patched version. <cite index="33-1">Patching a Critical use-after-free bug helps reduce the risk of remote code execution through a malicious web page, but it does not guarantee immunity from every browser exploit chain. Layered defenses, including sandboxing, site isolation, and OS-level protections, still matter. Delaying the restart leaves the previous build's known Critical flaws exposed, which is the practical reason security teams treat "update available" notices as more urgent than they look.</cite>
## Context: Chrome 149 Emergency Zero-Day and the 2026 Zero-Day Count
Chrome 151 arrives in the immediate wake of a separate security crisis that illustrates the risk of not having the latest Chrome version installed.
<cite index="30-1">This also comes just a few weeks after Google rushed out an emergency Chrome 149 update to fix an actively exploited zero-day vulnerability.</cite> <cite index="37-1">Earlier this month, the company patched the fifth actively exploited zero-day of 2026.</cite> Five actively exploited Chrome zero-days in the first six months of 2026 represents an elevated exploitation rate — attackers are not only finding browser vulnerabilities but weaponizing them against real users at a pace that makes rapid update deployment operationally essential rather than optional.
The distinction between Chrome 149's emergency zero-day patch and Chrome 151's large scheduled update matters for prioritization: the zero-day required immediate action because exploitation was confirmed in the wild; Chrome 151's 382 fixes require prompt action because exploitation has not yet been confirmed but the vulnerability details — particularly those covered in paid external researcher reports — may circulate among the security research community before the majority of users update.
## How to Update Chrome Immediately
Chrome typically updates itself in the background, but the update does not take effect until the browser is relaunched. A Chrome session that has been running continuously without a restart since before June 30, 2026 is still running the vulnerable pre-Chrome-151 build.
To verify and force the update:
Open Chrome's menu (the three-dot icon in the top-right corner) → select Help → select About Google Chrome. Chrome will immediately check for updates and display the current installed version. If the version shown is earlier than 150.0.7871.46 (Linux) or 150.0.7871.46/47 (Windows and Mac), click "Update Google Chrome" if present, then click "Relaunch" to apply the update.
If the About page already shows the correct version, click "Relaunch" anyway if Chrome indicates a pending relaunch is required to complete the update. The relaunch is the step that actually activates the patched build — an update that has downloaded but not been relaunched still leaves the machine running the unpatched version.
Android users should update via the Google Play Store to Chrome 150.0.7871.63 or later. Open the Play Store, search for Chrome, and select Update if available.
Enterprise administrators managing Chrome fleets through Google Workspace, Intune, or other MDM platforms should verify Chrome 151 is being enforced across the managed fleet and prioritize workstations where Chrome has not been restarted recently. Chrome's enterprise management tools can report the current browser version across the fleet and identify endpoints that remain on pre-151 builds.
## Who Is Most at Risk From These Vulnerabilities
All Chrome users on Windows, macOS, Linux, and Android are affected if they are running a version earlier than the patched build. However, specific Chrome configurations and use patterns create elevated risk profiles.
Enterprise environments using Chromoting (Chrome Remote Desktop) are specifically called out by researchers as elevated risk given the two Critical CVEs (CVE-2026-13779 and CVE-2026-13787) in remote desktop functionality. A Chromoting-targeted attack could provide access to remote sessions rather than just the local machine, amplifying the impact of a single exploit.
Organizations with liberal Chrome extension policies are at elevated risk from CVE-2026-13774, the Critical use-after-free in Extensions. Enterprises where users can install extensions from the Chrome Web Store without IT approval have a broader extension attack surface than those that enforce allowlists.
Environments with WebUSB access — developers, hardware engineers, organizations using browser-based device management interfaces — face elevated risk from CVE-2026-13778, the Critical WebUSB use-after-free.
Users in proximity-based environments — open offices, conference venues, shared workspaces — face elevated risk from CVE-2026-13785, the Critical Bluetooth use-after-free, since Bluetooth exploitation requires physical proximity that these environments provide.
Media-heavy enterprise environments using Chromecast for digital signage, conference room displays, or remote presentations should prioritize the Chromecast High-severity cluster (CVE-2026-13796 through CVE-2026-13804) in their fleet update prioritization.
## Broader Web Security Posture: Beyond the Browser Update
Patching Chrome is necessary but addresses only one layer of web security exposure. The drive-by download and malicious web page attack vectors that these vulnerabilities enable are the same vectors that web application security controls and DNS-level blocking address from the other direction.
Organizations maintaining strong web security posture at the network and application layer reduce the practical exposure from browser vulnerabilities by preventing malicious content from reaching the browser in the first place. Email-delivered malicious links — the most common delivery mechanism for drive-by browser exploits — are partially mitigated by email authentication controls that reduce the volume of spoofed email reaching inboxes. Verify your organization's email authentication using the ReconShield DNS Security Analysis tool, which validates SPF, DKIM, and DMARC configuration that prevents spoofed phishing emails carrying exploit links from being delivered.
HTTP security headers on organizational web properties — Content Security Policy, X-Frame-Options, Strict-Transport-Security — reduce the viability of certain browser-level attack techniques even when underlying vulnerabilities exist. Audit your web application's security header implementation using the ReconShield Security Headers Auditor, which evaluates every major security header against current standards.
TLS configuration quality on organizational web properties affects whether browser connections can be downgraded by on-path attackers attempting to intercept or modify traffic in ways that complement browser vulnerabilities. Verify your TLS implementation using the ReconShield SSL/TLS Checker. For the complete external web security posture picture, the ReconShield passive scanner suite combines email authentication, SSL/TLS, HTTP security headers, and infrastructure exposure analysis in a single non-intrusive workflow.
## Summary Checklist: What to Do Right Now
For individual users: Open Chrome menu → Help → About Google Chrome → verify version is 150.0.7871.46 or later → relaunch if a relaunch is pending. On Android, update via Google Play Store to Chrome 150.0.7871.63 or later.
For enterprise administrators: Audit the Chrome version distribution across your managed fleet and identify endpoints running pre-151 builds. Enforce a Chrome 151 update deadline using enterprise Chrome management policies. Prioritize endpoints used for Chromoting (remote desktop), WebUSB device management, and environments with broad extension permissions.
For security teams: Note that CVE-2026-13789 (GPU use-after-free, $36,000 bounty, sandbox escape via compromised renderer) is the highest-risk candidate for near-term PoC development given its bounty size and explicit sandbox escape capability — monitor threat intelligence feeds for any PoC code or in-the-wild exploitation reports targeting this specific CVE.
For all organizations: Verify external web application security posture complements browser patching using the ReconShield passive scanner suite — covering email authentication, SSL/TLS configuration, and HTTP security headers that reduce the practical impact of browser vulnerabilities on your users.
## Conclusion
382 vulnerabilities patched in a single Chrome release is a notable number, and the 15 Critical bugs — concentrated in GPU, Extensions, Bluetooth, WebUSB, Chromoting, and core browser infrastructure — represent real risk for users who do not update promptly. The absence of in-the-wild exploitation at the time of release is the most reassuring element: Google's internal detection machinery found 358 of these vulnerabilities before external attackers did, and patched them before anyone had the opportunity to weaponize them.
The action is straightforward: check your Chrome version, relaunch to apply pending updates, and verify the updated build is 150.0.7871.46 or later. For enterprise fleets, audit update compliance and prioritize the elevated-risk configurations — Chromoting users, WebUSB environments, and extension-heavy deployments.
Browser patching is the fastest, most direct security action available for these vulnerabilities. Everything else — network controls, email authentication, HTTP security headers — reduces the surface that browser vulnerabilities can exploit, but none substitutes for running the patched version of the browser.
Update Chrome. Restart it. Today.
Written by Surendra Reddy Cybersecurity Researcher & Founder, ReconShield. Surendra specializes in OSINT, exposure intelligence, and AI-driven threat analysis. Author Profile →
Reviewed by ReconShield Editorial Team — Peer-reviewed for technical accuracy against Google's Chrome 151 security release notes, SecurityWeek, Malwarebytes, PiunikaWeb, SQ Magazine, GBHackers, CybersecurityNews, Cryptika, SecurityOnline, and How2Shout reporting on the June 30, 2026 Chrome update.
Read More:
Chrome 149 Released With Critical Security Fixes for Windows, macOS, and Linux
BugHunter AI: The Ultimate AI-Powered Bug Bounty Toolkit for Ethical Hackers in 2026
GPT-5.5-Cyber: OpenAI's AI Security Model That Finds and Fixes Vulnerabilities Automatically
AI Bug Hunting: How Security Researchers Use AI to Find Vulnerabilities in 2026
CVE-2026-46331: New Linux pedit COW Exploit Enables Root Access by Poisoning Cached Binaries
Massive Temu Data Leak Claim Emerges: 310 Million Accounts Allegedly Exposed
## Analyst Commentary & Implementation Blueprint
Security advisory
Continuous security exposure assessment is critical to identifying public vulnerabilities before they are exploited. Organizations should maintain a passive inventory of all web servers, TLS configs, and open ports, ensuring that default configurations are eliminated and security advisories are actively implemented.
Hardened Security Configuration Blueprint
# General Security Hardening Directive
ServerTokens ProductOnly
ServerSignature Off
FileETag NoneActionable Mitigation Checklist
- ✔Perform passive asset inventories weekly.
- ✔Restrict administrative ports using local firewall controls.
- ✔Monitor active CVE alerts for exposed software.
Common Inquiries & FAQs
Why is passive scanning preferred for continuous auditing?
Passive audits do not cause operational impact or trigger firewall blocks, making them ideal for constant surveillance of internet-facing assets.
What should I do if a vulnerability is flagged?
Apply the latest vendor patches, restrict access to the resource via firewalls, or verify configuration flags to mitigate risks.
Surendra Reddy
Surendra Reddy is a cybersecurity researcher and founder of ReconShield, specializing in OSINT and defensive infrastructure analysis.
Connect on LinkedIn ↗// AUDIT BRIEFING DISCUSSION (2 COMMENTS)
Great breakdown of the passive infrastructure vectors. We recently audited our external DNS zones and found multiple dangling staging environments. Implementing wildcard certificates reduced our CT log leaks significantly.
Is there any automated tooling you recommend for daily crt.sh scraping? Manually checking CT logs is becoming unsustainable for our domain portfolio.
// MORE ARTICLES

Massive Temu Data Leak Claim Emerges: 310 Million Accounts Allegedly Exposed
Temu data leak claim: 310 million accounts allegedly exposed. See what's confirmed vs unverified, what data is at risk, and the steps every user should take now.

CVE-2026-46331: New Linux pedit COW Exploit Enables Root Access by Poisoning Cached Binaries
CVE-2026-46331 "pedit COW" explained: out-of-bounds write in Linux tc act_pedit poisons page-cached binaries for root access — technical details, affected versions, and patches.

Cisco Unified CM Vulnerability Checker: Test Your Cisco Unified Communications Manager for Security Risks
Cisco Unified CM Vulnerability Checker: test your Cisco Unified Communications Manager for security risks, common CVEs, exposure, and hardening steps.