Google pushed Chrome 153 to the stable channel on September 8 and 9, and buried inside the release notes is a bug you should not ignore. CVE-2026-87491 was already being exploited in attacks before the patch shipped. If your Chrome window has been open for days without a relaunch, that's the fix sitting unapplied. Close the tabs, restart the browser, and come back to this after.

The update landed as version 153.0.8010.36/.37 on Windows and macOS, and 153.0.8010.36 on Linux. In total it closes 230 vulnerabilities, but only one of them was confirmed as a live, in-the-wild exploit at release time. That's the one that matters today.

RelatedChrome V8 Zero-Day CVE-2026-85046 Is Under Attack: Patch Now

What does CVE-2026-87491 actually do?

It's a medium-severity out-of-bounds write in V8, the JavaScript and WebAssembly engine that powers every tab you open. Google's own advisory confirms an exploit already exists for it, which is a much stronger statement than the usual "could potentially be exploited" language attached to most patched bugs. Someone, somewhere, built working attack code before Google finished the fix.

An out-of-bounds write means the engine writes data past the edge of a memory buffer it was supposed to stay inside. On its own that sounds abstract, but the practical chain is simple enough to sketch out.

How the CVE-2026-87491 exploit chain worksA malicious webpage triggers a V8 out-of-bounds write, corrupting engine memory, which allows attacker code to run on the victim's machine.EXPLOIT CHAINFrom a webpage to code executionSTEP 1Maliciouswebpage loadsSTEP 2V8 out-of-boundswrite corruptsengine memorySTEP 3Attacker coderuns on thevictim's machineCVE-2026-87491genztech.blog
Fig 1 A simplified view of how a V8 out-of-bounds write turns a booby-trapped webpage into arbitrary code execution.

Visiting a rigged page is enough to trigger the corruption. From there, a working exploit can hijack the browser process and run attacker-controlled code, no download or click required beyond loading the page itself. That's why Google rates the in-the-wild status so seriously even though the CVE's base severity is only "medium."

Credit for catching it goes to Jihyeon Jeong, a security researcher at Compsec Lab, Seoul National University, who reported the flaw and received a $2,500 bug bounty from Google for the find. Bounty payouts for browser engine bugs like this one exist precisely because a working V8 exploit is valuable, to defenders trying to close it and to attackers trying to use it. Google would rather pay a researcher a few thousand dollars than have the bug sold or used quietly for months.

Google has not published who is behind the in-the-wild attacks, what targets were hit, or how the exploit was delivered. That's typical for an early zero-day disclosure. Vendors patch first and describe the technical mechanics later, once enough users have updated that publishing more detail won't hand latecomers a working blueprint.

Why has Chrome had seven zero-days in one year?

CVE-2026-87491 is the seventh actively exploited Chrome zero-day patched in 2026, not the first and, realistically, probably not the last. Six others came before it this year, each patched after Google confirmed active exploitation.

  1. #1CVE-2026-2441 actively exploited zero-day patched in 2026
  2. #2CVE-2026-3909 actively exploited zero-day patched in 2026
  3. #3CVE-2026-3910 actively exploited zero-day patched in 2026
  4. #4CVE-2026-5281 actively exploited zero-day patched in 2026
  5. #5CVE-2026-11645 actively exploited zero-day patched in 2026
  6. #6CVE-2026-85046 actively exploited zero-day patched in 2026
  7. #7CVE-2026-87491 V8 out-of-bounds write, patched in Chrome 153, this story

Seven in roughly eight and a half months is a fast pace, though Chrome's user base is also enormous, which makes it a constant target for researchers and attackers alike. Part of Google's response is structural: Chrome is shifting to a faster, two-week stable release cycle starting around this version, moving away from its previous longer cadence. Shorter cycles mean fixes for bugs like this one can ship sooner after discovery, rather than waiting for a longer release window to close.

There's also a simpler explanation than any conspiracy about Chrome getting worse: scale invites scrutiny. Chrome runs on billions of devices and shares its V8 engine with other Chromium-based browsers, so a single flaw in that engine has an enormous blast radius. That makes V8 one of the most heavily studied pieces of software on the planet, by security researchers hunting bounties and by attackers hunting access, at the same time.

What should you do right now?

The fix is already sitting on your machine in most cases, it just needs a restart to take effect. Chrome typically auto-updates in the background within about a day of a new release, but the new binary doesn't actually protect you until the browser relaunches.

Three steps, none of them technical:

RelatedBlueHammer Defender Zero-Day Hit SYSTEM in the Wild

1. Open a new tab and go to chrome://settings/help. Chrome checks for updates and shows the version it finds.

2. If it reports 153.0.8010.36, 153.0.8010.37, or newer, you're on the patched build. If it's still updating, let it finish.

3. Relaunch the browser. Closing and reopening every window applies the patch immediately instead of waiting on the background updater.

This applies across Windows, macOS, and Linux desktop builds. If you manage Chrome across a fleet of machines, don't assume auto-update has already covered every endpoint, particularly ones that have been asleep, offline, or running with tabs pinned open for weeks. The same logic applies at home: a laptop that's been in a bag all week, or a shared family desktop nobody restarts, is exactly the kind of machine that ends up several versions behind without anyone noticing.

If chrome://settings/help shows you're already on 153.0.8010.36 or later, you're covered and there's nothing else to do. If it isn't, and it says an update is available, click relaunch when it appears rather than dismissing it for later. Later is how zero-days stay exploitable longer than they need to.

None of this requires new software or a support ticket. It's a version check and a restart, and given that an exploit already exists, it's worth doing before you finish reading the rest of your open tabs.

Primary sources

Reporting for this piece draws on Google's Chrome Releases blog and security coverage from BleepingComputer, Help Net Security, and SecurityWeek, compiled and summarized by the GenZTech Team.