Google shipped an emergency Chrome fix for its seventh zero-day of the year, already used in real attacks

Google has pushed out an emergency update for Chrome after confirming that hackers were already exploiting a previously unknown flaw in the browser’s core engine. It marks the seventh time this year the company has had to rush a fix for a bug being used in live attacks, an unusually high number that underscores how much of the internet now runs through a single piece of software.

A flaw inside the engine that runs nearly every tab

The vulnerability sits in V8, the JavaScript and WebAssembly engine that powers how Chrome executes code from nearly every website a person visits. Engineers classified the bug as an out-of-bounds write, a type of memory-handling error that can let an attacker corrupt data beyond the space a program is supposed to use, potentially opening the door to running malicious code on a target’s machine. Google has said only that an exploit exists in the wild, without disclosing details about who is using it or against whom, a standard practice meant to avoid handing a blueprint to copycats before most users have patched.

A two-day turnaround from discovery to fix

What makes this patch notable is the speed behind it. The flaw was reported by a researcher at Compsec Lab, a security group at Seoul National University, and Google shipped a fix within roughly two days of receiving that report. That pace reflects how seriously the company treats any bug already being weaponized, since every day a known flaw sits unpatched is a day it can keep being used against unsuspecting users. The researcher who found and reported the issue received a bug bounty payment for the discovery, part of the reward system Google uses to encourage outside experts to hunt for dangerous flaws before criminal groups do.

Chrome 153 lands with more than two hundred other fixes

The emergency fix arrived bundled inside the broader Chrome 153 release, which brought roughly 230 separate security corrections across desktop platforms. Chrome’s stable channel moved to version 153.0.8010.36 on Linux, with matching builds for Windows and Mac, and the update rolls out automatically to most users over the following days unless someone manually checks for it sooner. Because Chrome typically applies updates the next time the browser restarts, a large share of the affected zero-day’s exposure closes simply when people quit and reopen the app rather than leaving dozens of tabs open indefinitely.

The seventh emergency patch in a single year

This is the seventh actively exploited zero-day Google has had to patch in Chrome so far in 2026, a pace that stands out even for a browser that has weathered a steady drumbeat of these incidents in recent years. Notably, four of those seven flaws trace back to the same V8 engine, suggesting attackers have found a rich vein of memory-safety bugs to mine inside the component responsible for turning web code into action on a user’s device. Google has spent years trying to harden V8 against exactly this category of error, including memory-safety projects meant to make such bugs harder to exploit even when they exist, yet sophisticated attackers keep finding new variations that slip past those defenses.

Why the fix matters beyond Chrome itself

The stakes extend well past Google’s own browser because V8 also powers Microsoft Edge, several other Chromium-based browsers, and the server-side JavaScript runtime Node.js, meaning a flaw discovered in Chrome can ripple across a much larger swath of software built on the same foundation. Security researchers have repeatedly pointed to this shared-engine problem as a structural risk: when so much of the browsing ecosystem depends on one codebase, a single memory-corruption bug can threaten hundreds of millions of devices at once rather than staying contained to one product. That concentration is part of why Google treats V8 zero-days with the urgency of a two-day patch cycle rather than folding them into a routine monthly update.

How exploitation typically works before a patch lands

Out-of-bounds write bugs like this one are attractive to attackers precisely because they can be triggered through ordinary web content rather than requiring a target to download and run a separate file. A malicious or compromised webpage can carry JavaScript specifically crafted to trigger the memory error inside V8, and once that corruption occurs, an attacker gains a foothold that can sometimes be chained with additional flaws to escape Chrome’s sandbox, the isolated environment the browser normally uses to keep a single tab’s code from touching the rest of the operating system. That is why active-exploitation zero-days draw a faster response than flaws discovered internally through routine security audits: the population of people already exposed grows every day the fix is not in users’ hands.

Confirming a browser has actually installed the fix

Because Chrome typically updates in the background, many users never see an explicit prompt confirming a new version has arrived. The most reliable way to confirm the patch is installed is to open Chrome’s settings menu, navigate to the “About Chrome” section, and let the browser check its version against the latest release before restarting it, since the update only fully takes effect once the browser closes and reopens. Anyone who leaves Chrome running continuously across many browser sessions, common on shared or infrequently rebooted machines, is more likely to be running a stale, unpatched build even though an update has technically already downloaded in the background.

This article was produced with AI assistance and edited by Morning Overview staff.

More from Morning Overview