CVE-2026-87491: Chrome's Second Zero-Day in a Week

Four days. That’s how long Chrome users got between patching one actively exploited V8 zero-day and needing to patch another. CVE-2026-85046 shipped a fix on September 4. CVE-2026-87491 shipped one on September 8. Both are confirmed exploited in the wild. If your team treated the first one as a one-off and moved on, it’s worth checking Chrome versions again right now.

What CVE-2026-87491 actually is

CVE-2026-87491 is an out-of-bounds write in V8, Chrome’s JavaScript and WebAssembly engine. A crafted HTML page gets V8 to write data past the boundary of an allocated buffer, which lets an attacker overwrite adjacent memory, things like object pointers and function tables, and turn that into arbitrary code execution inside the browser’s renderer sandbox. Google confirmed exploitation in the wild without disclosing further detail.

That’s a different bug class from CVE-2026-85046, which was a type confusion flaw (the engine misreading what shape an array actually was). Same delivery mechanism as most V8 bugs, though: visit a page, no download, no click-through warning, no plugin required. The renderer sandbox is supposed to contain damage from a compromised tab, so on its own this isn’t necessarily a full system compromise. But sandbox escapes get chained with V8 bugs often enough that “it’s just the renderer” isn’t a reason to deprioritize the patch.

Google fixed it in the Stable Channel release on September 8: version 153.0.8010.36 for Linux, and 153.0.8010.36/.37 for Windows and macOS. Google rated the underlying issue Medium severity in its own bug tracker, which is worth flagging because that rating reflects theoretical exploitability, not what’s actually happening in the field. A Medium bug that’s confirmed under active attack should move through your patch process like a Critical one.

Why this is the second one in a week

CISA’s Known Exploited Vulnerabilities catalog added both bugs within five days of each other: CVE-2026-85046 on September 4, then CVE-2026-87491 on September 9, alongside three unrelated entries for Fortinet, Citrix NetScaler, and a Cisco Firewall Management Center bypass. Two independently discovered, independently exploited V8 memory-safety bugs landing that close together isn’t evidence they’re related. It does mean whoever runs your Chrome fleet needs to treat “we patched Chrome last week” as a snapshot, not a completed task.

The researcher who reported CVE-2026-87491, Jihyeon Jeong of the Compsec Lab at Seoul National University, filed it on August 6, about a month before the public fix. That’s a fairly typical responsible-disclosure window for a bug of this severity: enough time for Google to build, test, and stage a fix before the details (and therefore a working exploit template) become public knowledge. The gap between “reported” and “exploited in the wild” tells you someone else independently found and weaponized the same bug class before the patch landed, or reverse-engineered it fast once the fix shipped and started giving away the shape of the bug. Google hasn’t said which, and for a fleet trying to decide how urgently to patch, it doesn’t really matter. Confirmed exploitation is confirmed exploitation.

What to actually do about it

Check your Chrome version now: chrome://settings/help. Chrome self-updates on relaunch by default, so the most common failure mode isn’t a broken update pipeline, it’s a browser tab that’s been open (and never fully closed) since before September 8. Encourage a full quit-and-reopen, not just a page refresh.

For a managed fleet:

• Confirm your update policy allows Stable Channel pushes without a manual approval gate that adds days of lag. For a bug already confirmed exploited, that lag is the exposure window.
• If you manage Chrome via Google Admin Console or an MDM, check the reported version distribution across your fleet, don’t assume 100% uptake just because the policy says “auto-update.”
• Extend the check to every Chromium-based browser in your environment: Edge, Brave, Opera, Vivaldi. They all ship V8, and while most pull Google’s fixes quickly, “quickly” varies by vendor and isn’t instant.
• If you’re running Chrome in a locked-down enterprise image where updates are staged manually, this is one of the cases where “wait for the next scheduled rollout” is the wrong call.

None of this requires new tooling. It requires actually verifying the number in chrome://settings/help matches or exceeds 153.0.8010.36, across however many machines that check needs to run on. For a broader look at how to structure this kind of patch triage on an ongoing basis rather than per-incident, see our guide on incident response for small teams.

The pattern worth remembering

Two zero-days in one engine in one week isn’t a reason to panic about V8 specifically. It’s a reminder that “we patched last Tuesday” has a shelf life measured in days, not months, for software this widely deployed and this frequently targeted. Chrome runs on roughly two-thirds of the browser market, which makes V8 one of the highest-value pieces of attack surface on the internet. Treat every KEV addition involving it as its own event, not an update to a ticket you already closed.