Google Chrome Just Patched 8 High-Severity Flaws. Not Updating Is a Bigger Risk Than You Think.

A Pattern Worth Understanding, Not Just a Patch to Apply

On March 23, 2026, Google released Chrome versions 146.0.7680.164 and 146.0.7680.165 for Windows and macOS, version 146.0.7680.164 for Linux, and version 146.0.76380.164 for Android. The update patches eight high-severity security vulnerabilities spanning WebAudio, CSS, WebGL, Dawn, WebGPU, Fonts, and FedCM.

None of the eight are zero-day vulnerabilities. Google has confirmed no active exploitation in the wild at the time of release. But "not yet exploited" is not the same as "safe to ignore." For a browser installed on approximately 3.5 billion devices globally, high-severity unpatched vulnerabilities represent a target of significant interest to threat actors, and the window between patch release and reverse-engineered exploit development is measured in days, not weeks.

This is also the third security update Google has shipped for Chrome 146 since its initial stable launch on March 10. The total vulnerability count across those three rounds now exceeds 63, making Chrome 146 one of the more security-intensive release cycles in recent memory. That number reflects something worth understanding beyond the immediate patch notes.

The 8 CVEs: What Each Vulnerability Class Actually Means

The eight patched flaws span CVE-2026-4673 through CVE-2026-4680. They fall into four distinct vulnerability classes, each with different risk profiles and exploitation characteristics.

Use-after-free vulnerabilities (3 of 8): CVE-2026-4676 in Dawn, CVE-2026-4678 in WebGPU, CVE-2026-4680 in FedCM

Use-after-free is consistently among the most dangerous and hardest-to-eliminate vulnerability classes in large C++ codebases. The flaw occurs when a program continues to reference a pointer to memory after that memory has been freed and potentially reallocated. An attacker who can control what occupies that freed memory can manipulate program state in ways that enable arbitrary code execution or sandbox escape.

In Chrome's case, a successful use-after-free exploit in a component like Dawn (Chrome's WebGPU implementation) or FedCM (the Federated Credential Management API) could allow an attacker to run malicious code in the context of the browser process, potentially reaching beyond the browser's security sandbox to the underlying system.

CVE-2026-4678 in WebGPU was identified internally by Google's own security engineers using automated fuzzing infrastructure, a detail worth noting. The other two were reported by external researchers. Shaheen Fazim discovered the FedCM flaw (CVE-2026-4680).

Heap buffer overflows and out-of-bounds reads in WebAudio (2 of 8): CVE-2026-4673 and CVE-2026-4677

WebAudio appears in two of the eight CVEs, indicating that the component is under sustained security scrutiny. CVE-2026-4673 is a heap buffer overflow, occurring when a program writes more data to a memory region than that region can safely hold, corrupting adjacent memory in the process. Google paid a confirmed $7,000 bug bounty for this discovery, with additional bounty amounts for other CVEs still pending determination.

CVE-2026-4677 is an out-of-bounds read in the same component. Out-of-bounds reads do not write to memory but can expose sensitive data from adjacent memory regions, including credentials, session tokens, and other private information that happens to be resident in nearby memory at the time of exploitation.

Out-of-bounds memory access in WebGL (1 of 8): CVE-2026-4675

WebGL handles hardware-accelerated 3D graphics rendering directly in the browser. CVE-2026-4675 is an out-of-bounds memory access vulnerability capable of corrupting the renderer process when a user visits a page containing crafted graphics content. The renderer process is the sandboxed component that handles web content, and its corruption is a stepping stone toward sandbox escape in multi-stage exploit chains.

Out-of-bounds read in CSS (1 of 8): CVE-2026-4674

CSS-based vulnerabilities carry a specific risk characteristic: they require minimal user interaction. Visiting a malicious page is sufficient to trigger the flaw, with no requirement to click, download, or interact with content. CVE-2026-4674 is an out-of-bounds read in Chrome's CSS engine capable of exposing sensitive memory data, including passwords, cookies, and other private information stored in Chrome process memory.

Integer overflow in Fonts (1 of 8): CVE-2026-4679

An integer overflow occurs when a mathematical calculation exceeds the maximum value an integer type can hold, causing it to wrap around to an unexpected value. In a fonts rendering component, this class of flaw can corrupt program logic in ways that enable memory corruption further down the execution path. CVE-2026-4679 was reported by GF and Un3xploitable of DeadSec.

Why Chrome 146 Has Had Over 63 Vulnerabilities

The volume of vulnerabilities in Chrome 146 reflects a structural reality about Chromium's codebase rather than a sudden deterioration in security practice. Chrome is among the most complex pieces of consumer software in existence, handling untrusted content from every corner of the web across a rendering engine, a JavaScript runtime, a GPU process, media decoders, and dozens of other subsystems. The attack surface is enormous by design.

Google invests significantly in automated vulnerability discovery. Tools including AddressSanitizer, MemorySanitizer, and libFuzzer run continuously against Chrome's components, bombarding them with malformed inputs to surface memory and logic flaws before they reach stable builds. When this infrastructure is working well, it produces a high volume of discovered and patched vulnerabilities rather than a low volume of discovered and exploited ones. A high patch count is, in part, a signal of active security investment rather than poor engineering.

The persistence of use-after-free bugs, three of the eight CVEs in this batch alone, reflects the inherent difficulty of memory management in C++. It is why Google has been gradually introducing Rust into the Chromium codebase for new components: Rust's ownership model prevents use-after-free conditions at the language level, making it structurally impossible to write the class of code that produces these vulnerabilities. That migration is ongoing and long-term. In the meantime, legacy C++ components continue to generate exploitable flaws that fuzzing and manual review catch before attackers do, most of the time.

Who Needs to Act and How

Individual users: Chrome updates automatically in the background. The majority of users will have received this patch before they read about it. To confirm, open Chrome, navigate to Help, then About Google Chrome. If the browser displays version 146.0.7680.164 or later, the patch is applied. If an update is available, Chrome will download and install it. Clicking Relaunch completes the process.

Enterprise administrators: Environments where Chrome updates are managed centrally rather than applied automatically represent the real exposure window for vulnerabilities of this class. Patch management systems should prioritize this update. The gap between patch release and enterprise deployment is the period during which the organization's endpoints are most vulnerable, as technical details become increasingly available to threat actors as the days pass.

Google is currently withholding the full technical specifics of all eight CVEs, a standard practice designed to limit the window for exploit development while the majority of the user base updates. Those restrictions will lift as update adoption reaches the threshold Google considers sufficient. At that point, proof-of-concept development activity typically accelerates.

Conclusion

Eight high-severity vulnerabilities patched, none currently exploited, update already rolling out. For most users, Chrome's automatic update mechanism handles this without any action required. For enterprise environments, this is a patch that belongs at the top of the week's deployment queue.

The broader Chrome 146 picture, 63-plus vulnerabilities across three patch rounds, is not a crisis. It is what sustained, high-volume security investment looks like in a codebase of Chromium's scale and complexity. The right response is to keep the browser updated, understand what the vulnerability classes mean when they appear in release notes, and treat the patch cadence as the normal operating rhythm of modern browser security rather than a signal of unusual instability.

If you are looking for help designing enterprise browser security policies, patch management workflows, or security architecture for web and mobile applications that reduces exposure to browser-based vulnerabilities, please reach out to MonkDA. We work with organizations building and maintaining secure digital infrastructure at every scale.