TL;DR
- what: Google patched 230 Chrome vulnerabilities, including CVE-2026-87491, an out-of-bounds write in the V8 JavaScript and WebAssembly engine that Google confirms is being exploited in the wild.
- impact: A crafted HTML page gives a remote attacker arbitrary code execution inside the renderer sandbox, which is the standard first link in a browser exploit chain and exposes session material and in-memory data for the site being viewed.
- fix: Update Chrome to 153.0.8010.36 or .37 on Windows and macOS and 153.0.8010.36 on Linux, then relaunch the browser so the running process actually picks up the fix.
- who: Every Chrome user, plus anyone running Chromium-based browsers such as Edge, Brave, Opera, and Vivaldi, which inherit the V8 bug until each vendor ships its own build.
Google patched 230 security flaws in the newest Chrome stable release, and one of them is already being used against real targets. CVE-2026-87491 is an out-of-bounds write in V8, Chrome's JavaScript and WebAssembly engine, and a crafted HTML page is enough to trigger it. That makes drive-by exploitation the delivery model: a user visits a page, attacker code runs. The fixed builds are 153.0.8010.36 and 153.0.8010.37 for Windows and macOS, and 153.0.8010.36 for Linux. Anything below those numbers is exposed.
Code execution, but inside the sandbox
The NVD text is specific about the boundary: the flaw "allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page." Inside the sandbox means the attacker gets control of the renderer process, not the host. The renderer is unprivileged by design. It cannot write arbitrary files, spawn processes freely, or reach other origins directly. One bug on its own does not hand anyone a shell on the endpoint.
That is the limit, stated plainly. A renderer compromise is still serious. It gives the attacker the contents of that renderer: session material for the site in view, in-memory data, and a stable execution primitive to build on. In practice, V8 renderer bugs are step one of a chain, paired with a sandbox escape in the browser process, a GPU process bug, or a kernel flaw. Whoever is running CVE-2026-87491 in the wild very likely has a second bug behind it, and Google has not said what it is, how the exploit is delivered, or who is using it.
Medium severity is not low priority — Google rated CVE-2026-87491 medium and NVD has not assigned a CVSS score at all. That label reflects the sandbox boundary, not your risk. Confirmed in-the-wild exploitation should outrank any static score in your patch queue this week.
The other 229
Five critical flaws shipped in the same update, all of them in code that parses attacker-controlled input:
- CVE-2026-87464: use-after-free in WebGL
- CVE-2026-87488: use-after-free in WebGL
- CVE-2026-87438: out-of-bounds write in WebGL
- CVE-2026-87527: buffer overflow in WebGL
- CVE-2026-87628: use-after-free in Cast
Four of the five criticals are WebGL. If your fleet has no business need for 3D graphics in the browser, Chrome enterprise policy can disable those APIs and remove that attack surface outright. One high-severity use-after-free in WebPackaging, CVE-2026-87639, is credited to OpenAI Codex Security, which is a notable line item on its own: an AI-assisted review pipeline is now landing credited Chrome bugs. Google reported 195 of the 230 flaws itself, found largely through AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, and AFL.
Seven exploited zero-days in nine months
CVE-2026-87491 is the seventh actively exploited Chrome zero-day Google has fixed since the start of the year, following CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281, CVE-2026-11645, and CVE-2026-85046. That averages out to roughly one every five weeks. Treat Chrome as a standing patch cadence problem, not a series of one-off emergencies. If your browser update process requires a change ticket and a maintenance window, it is already too slow for that rate.
The disclosure timeline and the downstream gap
Jihyeon Jeong of Compsec Lab at Seoul National University reported the bug on August 6, 2026 and received a $2,500 bounty. The fix reached stable about a month later. Google is holding technical details back, which is standard practice until the majority of users have updated, and it will keep the restriction in place longer if the bug lives in a shared third-party library. The practical effect: there is no public proof of concept to test your controls against yet, and no attribution to hang detection logic on.
The gap that matters more for most organizations is downstream. Edge, Brave, Opera, and Vivaldi all build on Chromium and each ships its own release on its own schedule. Patching Chrome and calling it done leaves every other Chromium browser your users installed still carrying the V8 bug. Inventory them, then track each vendor's release note separately.
⚠️ An update that has not relaunched is not applied — Chrome stages the new binary but keeps executing the old one until the browser restarts. Users with 40 tabs and 30 days of uptime remain exploitable after the update downloads. Verify the running version, not just the installed package version.
What to run
Check the version on every platform you own, then push the upgrade through the channel that matches how Chrome got installed. These read-only checks work on a single host and scale to a fleet query with no changes:
defaults read /Applications/Google\ Chrome.app/Contents/Info.plist CFBundleShortVersionString
google-chrome --version
powershell -c "(Get-Item 'C:\Program Files\Google\Chrome\Application\chrome.exe').VersionInfo.ProductVersion"
What to alert on
You cannot detect the V8 bug from logs, because there is no signature for a crafted HTML page and no public indicators for this campaign. What you can detect is the stage that follows a successful chain: a renderer process doing something a renderer never does. Build the alert on process lineage, and treat renderer crash spikes as a weak but useful second signal while you finish patching.
Originally published on RedEye Threat Intelligence.
Top comments (1)
The insight about the V8 engine's renderer sandbox limitations is crucial, as it highlights how a compromise there can still expose sensitive session data before further escalation occurs. This emphasizes the importance of not just patching, but understanding the layered security model browsers employ. If your team is considering further enhancements to the Chrome security framework or exploring additional mitigations, I’d be glad to discuss how I could contribute to that effort. Have you thought about implementing more proactive monitoring for these vulnerabilities?