Chrome Zero-Day Exploits: 4 Vulnerabilities Exposed in May 2024's Most Aggressive Attack Wave

Four confirmed Chrome zero-day exploits in fourteen days. That's not a typo. In May 2024, Google pushed emergency patches for CVE-2024-4671, CVE-2024-4761, CVE-2024-4947, and CVE-2024-5274. Every single one was actively exploited in the wild before Google could fix it. This cluster of Chrome zero-day exploits is one of the most concentrated browser attack campaigns I've seen. And if you're running Chrome (statistically, you probably are), this one matters.

I've spent over 14 years building and securing production systems, and I've tracked zero-day disclosure cycles closely for most of that time. A single browser zero-day is concerning. Four in rapid succession, at least two linked to commercial spyware vendors, is something different entirely. This isn't about theoretical risk. Real users got hit.

What Is a Chrome Zero-Day, and Why Were There Four at Once?

A zero-day vulnerability is a flaw that attackers discover and exploit before the software vendor knows it exists. The name comes from the fact that the vendor has had zero days to fix it. When Google's Threat Analysis Group (TAG) confirms that an exploit "exists in the wild," it means real attacks are happening against real users right now.

What made May 2024 extraordinary wasn't just the severity of each individual bug. It was the tempo. Google patched CVE-2024-4671 on May 9th. Then CVE-2024-4761 on May 13th. CVE-2024-4947 landed on May 15th. And CVE-2024-5274 followed on May 23rd. Four emergency updates in two weeks. Each one tagged with Google's most urgent label: "Google is aware that an exploit exists in the wild."

The Cybersecurity and Infrastructure Security Agency (CISA) added all four to its Known Exploited Vulnerabilities (KEV) catalog, mandating that federal agencies apply patches immediately. When CISA adds something to the KEV, it's not a suggestion. It's an order for government systems. Treat it like one for yours too.

Breaking Down Each Chrome Zero-Day Vulnerability

Let me walk through each of the four CVEs because they're not all the same class of bug, and that matters for understanding what was actually happening.

CVE-2024-4671: Use-After-Free in Visuals. This was the opening shot. A use-after-free bug in Chrome's Visuals component, which handles rendering. The browser frees a chunk of memory, but code still holds a reference to it. An attacker manipulates what gets written to that freed memory and hijacks execution flow. Use-after-free is one of the most common vulnerability classes in C++ codebases, and Chrome's rendering pipeline is a perennial target.

CVE-2024-4761: Out-of-Bounds Write in V8. This one hits V8, Chrome's JavaScript engine. An out-of-bounds write means the attacker can write data beyond the boundaries of an allocated buffer. In V8, this is particularly dangerous because JavaScript execution is the most exposed attack surface in any browser. Visit a malicious page, and the exploit fires. That's it.

CVE-2024-4947: Type Confusion in V8. Another V8 bug, different class. Type confusion happens when code allocates an object as one type but accesses it as another, letting attackers corrupt memory in predictable ways. Clément Lecigne and Brendon Tiszka of Google's Threat Analysis Group discovered this one, and Google TAG's research linked it to a commercial spyware operation. This is the kind of bug that exploit brokers pay serious money for. Zerodium's public pricing lists up to $500,000 for a full-chain Chrome exploit with sandbox escape.

CVE-2024-5274: Type Confusion in V8. Yes, another type confusion in V8. Clément Lecigne of Google TAG was again credited. Two type confusion bugs in V8 within the same two-week window suggests either a single threat actor burning through a stockpile, or multiple actors hitting the same weak spot independently. Neither scenario is comforting.

The pattern is obvious: V8 is the primary target. Three of the four vulnerabilities hit Chrome's JavaScript engine directly. If you've ever wondered why security vulnerabilities in seemingly unrelated systems share common attack patterns, V8's complexity is a textbook example. The engine compiles and optimizes JavaScript at runtime using multiple compilation tiers, and each tier introduces opportunities for type confusion and memory safety bugs.

Who Was Actually Targeted by These Chrome Zero-Days?

This is the part that should bother you. At least two of these vulnerabilities, CVE-2024-4947 and CVE-2024-5274, were linked to commercially-backed spyware vendors. The exploits weren't from random cybercriminals. They were developed or purchased by companies that sell surveillance tools to governments.

Google's TAG has been tracking this ecosystem for years. Clément Lecigne, who has been credited on dozens of zero-day discoveries, has been at the center of this work. The TAG team has publicly documented how commercial surveillance vendors (CSVs) stockpile browser exploits and sell them to nation-state clients for targeted surveillance of journalists, dissidents, and political opponents.

Does that mean you, a software engineer reading this on your lunch break, were personally targeted? Probably not. These high-value exploits are typically deployed against specific individuals, not sprayed across the internet. But the exploit code doesn't care about the attacker's intent. Once a zero-day is burned (used in the wild and detected), it proliferates. What starts as a targeted spyware operation today becomes a commodity exploit kit tomorrow.

I've seen this exact pattern play out in production environments I've worked on. A vulnerability disclosed as "targeted" gets reverse-engineered from the patch within days, and suddenly you're seeing exploitation attempts in your server logs from automated scanners. The window between "targeted attack" and "everyone's problem" shrinks every year.

The exploits commercial spyware vendors develop for targeted surveillance eventually leak, get reverse-engineered, or inspire copycats. Today's nation-state tool is tomorrow's commodity malware. That pipeline is real, and it's getting faster.

Why V8 Keeps Showing Up in Chrome Zero-Day Disclosures

Three out of four vulnerabilities hit V8. Not a coincidence. V8 is the most complex and security-critical component in Chrome, and it's written in C++, a language with zero memory safety guarantees by default.

V8 compiles JavaScript through multiple optimization tiers: Sparkplug, Maglev, and TurboFan. Each tier makes increasingly aggressive assumptions about types and object shapes to generate faster machine code. When those assumptions are wrong, or when an attacker deliberately violates them, you get type confusion. The engine thinks it's working with one kind of object but is actually manipulating another. That mismatch lets attackers write arbitrary data to arbitrary memory locations.

This is why Google has been investing heavily in V8 sandboxing. The V8 sandbox is a separate memory isolation layer within V8 itself, designed so that even if an attacker achieves code execution inside V8, they can't escape to the broader renderer process. Defense in depth. It's necessary because the attack surface of a JIT-compiling JavaScript engine is enormous.

Having worked on systems where performance-critical C++ code introduces subtle memory bugs, I can tell you firsthand: the tension between performance optimization and memory safety is real and constant. V8 is optimizing for nanoseconds of JavaScript execution time, and every optimization is a potential security boundary violation. Google knows this, which is why they're exploring memory-safe languages for new Chrome components. But V8 can't be rewritten overnight. It's millions of lines of C++.

The economics make V8 a permanent target. A working V8 exploit gives an attacker remote code execution on any device running Chrome, Edge, Brave, or any Chromium-based browser. Plus Node.js and Electron apps. That's billions of attack surfaces from a single vulnerability class.

What This Means for Your Security Posture Right Now

If you haven't updated Chrome recently, do it now. Literally now. Open chrome://settings/help and let it update. Chrome auto-updates, but only if you actually restart the browser. I know engineers who keep hundreds of tabs open for weeks. That means they're running an unpatched browser the entire time.

But updating Chrome is the bare minimum. Here's what this attack wave actually signals:

The commercial spyware market is accelerating. The number of zero-days attributed to commercial surveillance vendors has climbed year over year. Google TAG reported that CSVs were responsible for a growing share of all zero-days detected in 2023 and 2024. This is not slowing down.

Browser monoculture is a systemic risk. Chrome and Chromium-based browsers account for roughly 65% of desktop browser usage. When a V8 zero-day drops, it doesn't just affect Chrome. It hits Edge, Brave, Opera, Vivaldi, and every Electron app on your machine. That blast radius is staggering.

Patch velocity is the new perimeter. If you're running infrastructure, the same urgency applies. I've written before about how seemingly minor security issues compound into real threats. Browsers are the thinnest part of your security boundary. Your developers browse the web on the same machines that have access to production credentials. An unpatched browser is an open door.

For engineering leaders: audit your organization's patch management for endpoints. Not just servers. Not just production. The laptops your team uses every day. If your MDM isn't enforcing browser updates within 48 hours of a security release, you have a gap that someone will eventually walk through.

Browser Security Is Infrastructure Security Now

May 2024's Chrome zero-day cluster wasn't a fluke. It was a signal. The browser is the most attacked piece of software on the planet, and the attackers are well-funded, sophisticated, and patient.

Google deserves credit for the speed of their response. Four emergency patches in two weeks is a punishing pace for any security team. But the fact that four zero-days were burning simultaneously tells us something important: the offensive side of this equation is winning on volume. Defenders patch one hole and the next exploit is already loaded.

Here's my prediction: within the next two years, we'll see a major browser vendor ship a JavaScript engine component written in a memory-safe language as a direct response to this class of vulnerability. The economics of patching V8-class bugs every other week will become untenable, even for Google. The question isn't whether memory safety comes to browser engines. It's whether it arrives before or after a zero-day chain causes a genuinely catastrophic breach.

Update your browser. Enforce updates across your team. And stop assuming that "targeted attacks" don't eventually become your problem. They always do.

---

Originally published on kunalganglani.com