Google fixes yet another actively exploited Chrome zero-day (CVE-2026-87491)

1. Executive summary

Google has patched CVE-2026-87491, an out-of-bounds write in the V8 JavaScript/WebAssembly engine, and states that an exploit exists in the wild. The flaw allows a remote attacker to execute arbitrary code inside the Chrome sandbox via a crafted HTML page — i.e., the initial access vector is simply a victim visiting attacker-controlled web content. Fixes shipped 2026-09-08 (Tuesday advisory) in Chrome 153.0.8010.36/.37 for Windows and macOS and 153.0.8010.36 for Linux, alongside fixes for 230 vulnerabilities total in this release cycle. Per the verified reference data, CVSS is unknown, severity is not confirmed by NVD, and the CVE is not in the CISA KEV catalogue — the "actively exploited" designation rests solely on Google's own advisory statement. This is the seventh actively exploited Chrome zero-day Google has patched in 2026, continuing a sustained pattern of V8 engine exploitation that EMEA financial services clients should treat as a standing browser-hygiene problem, not a one-off.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. The trigger facts available — a vendor patch release and vendor-confirmed in-the-wild exploitation with no known victim organisation, no incident at a client, and no named third-party provider failure — do not distinctively engage incident management, classification, reporting, or third-party risk obligations beyond what applies to routine patching. Clients should nonetheless record the update in normal change-management and vulnerability-management processes; if exploitation is subsequently confirmed within a client environment, DORA Art. 18 (classification of ICT-related incidents and cyber threats) and Art. 19 (reporting of major ICT-related incidents to competent authorities) would become engaged at that point.

3. Technical analysis & attack chain

Vulnerability mechanism. CVE-2026-87491 is an out-of-bounds write (CWE-787 per the verified reference data) in V8, Chrome's JavaScript and WebAssembly engine. An out-of-bounds write in V8 lets attacker-controlled script write outside the memory bounds of an allocated object, corrupting adjacent heap metadata or object pointers. In practice this is the classic primitive for V8 exploitation: corrupt an object's type or length field, pivot to type confusion or fake-object techniques, and achieve arbitrary read/write within the renderer process. Google's advisory text states the impact directly: the flaw "allows a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page."

Confirmed attack chain (steps confirmed by Google's advisory language)

1. Attacker hosts a crafted HTML page (or compromises/injects into a web page the victim will visit).
2. Victim's Chrome renderer processes the page's JavaScript/WebAssembly in V8, triggering the out-of-bounds write.
3. Attacker achieves arbitrary code execution inside the Chrome sandbox — the renderer process, not the OS.

What the sandbox limit means. Code execution is confined to the sandboxed renderer. This is a security limiter, not a full stop: as the Malwarebytes analysis of the closely related June V8 zero-day notes, attackers routinely chain a renderer bug with a separate sandbox-escape vulnerability to reach full system compromise. No sandbox escape is identified in connection with CVE-2026-87491 in any source, and we make no claim that one exists — but defenders should assume exploit chains will mature as researchers dissect the patch.

Observed impact. Google has given no detail on the in-the-wild exploitation: no victim sectors, no actor, no campaign name, no delivery infrastructure. Consistent with its standard practice while a fix rolls out, Google is withholding bug details and links, and notes restrictions may also be retained because the bug may exist in third-party libraries other projects depend on. Attribution: none offered and none should be assumed. The Register's commentary on the June zero-day (corpus-6) observes there was no indication of broad, indiscriminate attacks for that flaw and that zero-days are often reserved for targeted operations until patches are available; whether that holds for CVE-2026-87491 is unknown.

Reporting and discovery. Jihyeon Jeong of the Compsec Lab at Seoul National University reported the flaw on 2026-08-06 and received a $2,500 bounty — a modest sum relative to V8 zero-days (the June flaw earned $55,000), which may reflect Google's assessment of exploitability or the constrained sandbox-execution impact. Single-sourced caveat: the bounty figure and researcher attribution come from the Help Net Security report of Google's advisory only.

Context — 2026 Chrome zero-day cadence. CVE-2026-87491 is the seventh actively exploited Chrome zero-day patched in 2026: CVE-2026-2441 (February, use-after-free in CSS), CVE-2026-3909 and CVE-2026-3910 (March), CVE-2026-5281 (April), CVE-2026-11645 (June, out-of-bounds read/write in V8), and CVE-2026-85046 (early September, type confusion in V8, CVSS 8.8, fixed in 152.0.7977.82/.83). Google patched eight Chrome zero-days across all of 2025. Three of the seven 2026 zero-days sit in V8 specifically. Clients running Chromium-derived browsers (Edge, Brave, etc.) inherit these V8 flaws on the vendor's patch cadence, not Google's.

Discrepancy note. The Help Net Security article rates CVE-2026-87491 "Medium severity"; the verified reference data records CVSS as unknown and not in CISA KEV. We use the verified values. The vendor's Medium rating is consistent with the sandbox-confined impact statement but is not an NVD-confirmed score.

4. Mitigation & containment

P1 — within 24 hours

• Update Chrome to 153.0.8010.36 or .37 (Windows/macOS) or 153.0.8010.36 (Linux). The rollout is staged over days/weeks; do not wait for it to reach your fleet. Push via enterprise policy (UpdatePolicy / forced auto-update in Google Update / chrome_managed policy), or verify manually: chrome://settings/help (Settings > About Chrome) triggers an immediate check. A browser restart is required to complete the update — endpoints that never close Chrome stay vulnerable; instruct users or force restart via policy.
• Verify fleet-wide version: query chrome://version or pull the executable version from $(Install Path)\chrome.exe (Windows) / /opt/google/chrome/chrome (Linux). Any endpoint below 153.0.8010.36 is exposed to a known in-the-wild exploit.
• Confirm the September CVE-2026-85046 fix (152.0.7977.82+) is also fully deployed — it was patched only last week and staged rollouts may have left stragglers.

P2 — within 72 hours

• Extend the same urgency to Chromium-derived browsers in the estate (Edge, Brave, Vivaldi, and any embedded Chromium in trading/CRM tooling). Their V8 is the same code; they patch on their own schedule. Inventory and pin minimum versions.
• For endpoints that cannot be updated immediately (kiosks, VDI gold images, legacy trading workstations): enforce site-isolation (--enable-features=SiteIsolation / SitePerProcess policy is default-on in current Chrome but verify), and restrict browsing to allow-listed domains on those hosts.
• Hunt for exposure: review proxy/web-filter logs for user-reported crashes in renderer processes (chrome.exe abnormal terminations) on unpatched hosts since 2026-08-06 (disclosure date) — renderer crashes on crafted pages are the observable residue of failed or successful V8 exploitation attempts.

P3 — within 7 days

• Update the organisation's browser patch SLA: seven exploited V8/renderer zero-days in eight months means browser patching cadence should be measured in hours-to-days, not the standard monthly cycle. Track Chrome stable releases as a standing watch item.
• Review extension policy: Malwarebytes notes extensions can block Chrome updates — audit for extensions interfering with the update mechanism and enforce extension allow-listing.
• Brief users that the delivery vector is ordinary web browsing; reinforce that untrusted links (including in email and collaboration tools) remain the delivery path for this class of bug.

5. Indicators of compromise

No indicators of compromise available in the source material. Google has withheld all exploitation detail — no domains, URLs, hashes, or campaign infrastructure have been published for CVE-2026-87491. The only defensive pivot is version checking (§4) and renderer-crash anomaly review.

6. Detection

Insufficient indicators to author detection rules. No exploit artefacts, strings, filenames, or infrastructure have been disclosed for CVE-2026-87491. Google's restriction of bug details means no YARA/Sigma content can be authored from threat artefacts at this time; a rule keyed to the CVE identifier or product name would detect reporting about the threat, not the threat. Revisit when Google lifts restrictions or a vendor publishes exploit-chain analysis.

CVE assessment

1 referenced CVE

7. Sources

• Help Net Security — Google fixes yet another actively exploited Chrome zero-day (CVE-2026-87491) — https://www.helpnetsecurity.com/2026/09/09/google-chrome-cve-2026-87491-zero-day-flaw/ — 2026-09-09
• The Hacker News — Google Releases Chrome Update to Patch Actively Exploited V8 Zero-Day (CVE-2026-85046 context) — https://thehackernews.com/2026/09/google-releases-chrome-update-to-patch.html — 2026-09
• Help Net Security — Google patches actively exploited Chrome zero-day (CVE-2026-85046) — https://www.helpnetsecurity.com/2026/09/04/google-chrome-zero-day-cve-2026-85046/ — 2026-09-04
• Malwarebytes Labs — Update Chrome: Google patches actively exploited vulnerability and 73 others (CVE-2026-11645 sandbox-chain analysis) — https://www.malwarebytes.com/blog/bugs/2026/06/update-chrome-google-patches-actively-exploited-vulnerability-and-73-others — 2026-06
• Help Net Security — Google patches Chrome zero-day exploited in the wild (CVE-2026-11645) — https://www.helpnetsecurity.com/2026/06/09/google-chrome-zero-day-cve-2026-11645/ — 2026-06-09
• SecurityWeek — Google Patches 5th Chrome Zero-Day Exploited in 2026 — https://www.securityweek.com/google-patches-5th-chrome-zero-day-exploited-in-2026/ — 2026-06
• The Register — Chrome's zero-day Whac-A-Mole continues with fifth exploited bug of the year — https://www.theregister.com/security/2026/06/09/chromes-zero-day-whac-a-mole-continues-with-fifth-exploited-bug-of-the-year/5252689 — 2026-06-09

8. Adverse Trace position

Severity: actively exploited, vendor-rated Medium, CVSS unconfirmed (not in CISA KEV) — we treat the in-the-wild exploitation claim as credible (it is Google's own advisory statement) but note it is single-sourced to the vendor, with no independent corroboration of campaign scope, victims, or actor, and no attribution offered; treat any actor claims circulating elsewhere as unconfirmed. The sandbox-confined impact limits blast radius per bug, but the 2026 pattern — seven exploited zero-days, three in V8, delivered via ordinary web browsing — makes the browser the most reliable initial-access surface in most EMEA financial estates, and this release fixes 230 vulnerabilities in total, of which the zero-day is only the headline. Client impact: any estate with unpatched Chrome or lagging Chromium derivatives carries a known, weaponised, browse-delivered RCE-in-sandbox primitive; the realistic worst case is a renderer-to-full-system chain once a sandbox escape is paired with it. Next actions: we will monitor for Google lifting bug-detail restrictions, publication of exploit analysis or KEV listing, and any reporting of victims or campaign infrastructure; we will reissue with IOCs and detection content if exploitation detail emerges. Clients should confirm fleet-wide deployment of 153.0.8010.36+ within 24 hours and report any suspected renderer-crash anomalies on unpatched hosts to their Adverse Trace point of contact.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.