Three Chrome Zero Days in Three Months—Google's Browser Is Under Siege

A Pattern That Should Worry Everyone

Three months into 2026, Google has already patched three zero day vulnerabilities in Chrome that were actively exploited before the company could release fixes. That means attackers were using these flaws against real people, in real time, before anyone had a defense.

The latest round came on March 13, when Google pushed an emergency update to address two high severity zero days discovered just three days earlier. Combined with a critical vulnerability patched in January, the picture is clear: Chrome, the browser used by over three billion people worldwide, is under sustained assault from attackers who are finding and exploiting serious flaws faster than Google can fix them.

For developers and security professionals, this is not just a browser update story. It is a signal that the attack surface of the modern web runtime is expanding, and the window between discovery and exploitation is shrinking to near zero.

The March Zero Days: Skia and V8

On March 10, 2026, Google's internal security teams identified two new vulnerabilities in Chrome that were already being exploited in the wild. Within two days, patches were ready, and on March 13 the company released updated versions of Chrome for Windows (146.0.7680.75), macOS (146.0.7680.76), and Linux (146.0.7680.75).

CVE-2026-3909: Out of bounds write in Skia

Skia is the open source 2D graphics library that Chrome uses to render everything you see on screen, from text and images to complex visual elements. This vulnerability allowed a remote attacker to perform an out of bounds memory write by luring a victim to a crafted HTML page. An out of bounds write means the attacker could write data to memory locations outside the intended buffer, potentially corrupting adjacent data structures, hijacking control flow, or executing arbitrary code. It received a CVSS score of 8.8, placing it firmly in the high severity category.

CVE-2026-3910: Inappropriate implementation in V8

V8 is Chrome's JavaScript and WebAssembly engine, the component that executes virtually all dynamic code on the web. This flaw allowed a remote attacker to execute arbitrary code inside Chrome's sandbox through a crafted HTML page. While sandbox containment limits the immediate blast radius, V8 vulnerabilities are particularly dangerous because they can often be chained with sandbox escape exploits to achieve full system compromise. This vulnerability also received a CVSS score of 8.8.

Google confirmed that exploits for both vulnerabilities exist in the wild but withheld specific exploitation details to limit further weaponization. Both flaws share the same attack vector: a specially crafted web page. That means visiting the wrong website, clicking the wrong link, or loading the wrong ad was enough to trigger the exploit.

The January Zero Day: CSS Use After Free

The March patches were not the first Chrome zero day of 2026. In January, Google addressed CVE-2026-2441, a use after free vulnerability in Chrome's CSS processing engine. Use after free bugs occur when a program continues to reference a memory location after it has been freed, allowing attackers to manipulate what occupies that memory and potentially redirect execution to malicious code.

CVE-2026-2441 received a CVSS score of 8.8 and was also confirmed to be actively exploited before the patch was available. Like the March vulnerabilities, it could be triggered simply by visiting a malicious web page.

Three zero days in three months, all with the same severity rating, all exploited before patches arrived, and all triggered through the same basic attack vector of a crafted web page. This is not coincidence. It reflects a sustained focus by sophisticated attackers on Chrome's most critical rendering and execution components.

Why These Vulnerabilities Matter

The three components targeted, Skia, V8, and the CSS engine, are not peripheral features. They are the core of what makes a browser a browser. Every web page you load exercises all three. There is no way to browse the web without relying on them, which makes them extraordinarily high value targets for attackers.

For security professionals, the pattern raises questions about whether Chrome's attack surface has grown faster than its security investment can cover. Chrome ships new features, rendering capabilities, and JavaScript APIs at a rapid pace. Each addition is another potential entry point.

For developers, these vulnerabilities are a reminder that the browser is not a safe execution environment by default. Code that processes untrusted input, including any web content, operates in a threat model where the renderer itself may be compromised. Applications that rely on client side security controls without server side validation are at particular risk when the browser runtime they depend on is actively being exploited.

What You Should Do Right Now

The most important step is immediate and simple: update Chrome. Navigate to More > Help > About Google Chrome and let it check for updates. If the version number shows 146.0.7680.75 or higher on Windows and Linux, or 146.0.7680.76 or higher on macOS, you have the patches. Then click Relaunch to apply them.

Beyond that, consider these additional measures:

• Enable automatic updates. Chrome should update itself, but enterprise policies, restricted networks, or stale browser sessions can prevent updates from applying. Verify that auto update is not disabled on your systems.
• Restart your browser regularly. Chrome updates only take effect after a restart. If you keep dozens of tabs open for weeks, you may be running an unpatched version without realizing it.
• Audit enterprise Chrome deployments. Organizations running managed Chrome instances should verify that update policies are pushing the latest stable channel. A single unpatched machine is enough for an attacker to establish a foothold.
• Reduce exposure to untrusted content. Ad blockers and script blockers reduce the number of third party resources loaded on each page, narrowing the attack surface for exploits delivered through malicious ads or compromised scripts.
• Monitor Chrome's release blog. Google publishes security advisories at chromereleases.googleblog.com. Security teams should subscribe and treat zero day disclosures as high priority patch events.

The Bigger Picture

Chrome zero days are not new. Google patched multiple actively exploited vulnerabilities throughout 2024 and 2025 as well. But the pace in early 2026 is notable. Three in three months suggests either that attackers are investing more heavily in browser exploit development, that existing code is yielding more discoverable flaws as it ages and grows in complexity, or both.

The browser has become the operating system of the modern internet. Email, banking, healthcare portals, internal corporate tools: they all run in the browser. When the browser's core rendering and execution engines have actively exploited vulnerabilities, every one of those activities is at risk.

Google deserves credit for fast response times. Both March vulnerabilities went from discovery to patch in just two days. But the uncomfortable reality is that for an unknown period before March 10, anyone visiting the wrong page was exposed with no defense available. That is the nature of a zero day, and it is why the frequency of these disclosures matters as much as the severity.

Update your browser. Check your organization's update policies. And accept that in 2026, keeping Chrome patched is not optional maintenance. It is an active security operation. Since this article was published, Google has already patched a fourth Chrome zero-day in 2026, this time in the WebGPU graphics layer.