A Web Page Was Enough. Chrome’s V8 Zero-Day Was Already Being Exploited.

The vulnerability, CVE-2026-11645, is an out-of-bounds read and write in the JavaScript and WebAssembly engine used by Chrome. Google described it as high severity and confirmed that an exploit existed in the wild.

The exploit starts inside the browser sandbox

Google’s CVE description says a remote attacker could execute arbitrary code inside the sandbox by persuading a user to open a crafted HTML page. That is serious, but the boundary must be stated accurately: the disclosed vulnerability provides code execution in Chrome’s sandboxed renderer context. Google did not say that CVE-2026-11645 alone escapes the sandbox or takes over the operating system.

Attackers frequently combine a renderer vulnerability with a second flaw that escapes the sandbox or elevates privileges. Google had not published a complete exploit chain, target profile or attribution when it released the update. The absence of those details is normal while patches are still rolling out, but it also limits what defenders can infer about the campaign.

The vulnerability was reported by a researcher using the name 303f06e3 on 27 April. Google awarded a $55,000 bounty. The patch arrived in Chrome 149.0.7827.102/.103 for Windows and macOS and 149.0.7827.102 for Linux.

One browser engine creates a wider patching question

V8 is embedded in the Chromium ecosystem, so the operational question extends beyond the Chrome icon on a user’s desktop. Microsoft Edge, Brave, Opera and other Chromium-based products ship their own update channels and version numbers. Administrators should confirm the patched state of each deployed browser rather than assuming that updating Chrome also updates every Chromium derivative.

CISA added CVE-2026-11645 to its Known Exploited Vulnerabilities catalogue on 9 June, with a federal remediation deadline of 23 June. The entry is independent confirmation that the issue belongs in an emergency browser-patching workflow, not a routine monthly queue.

Why automatic updates are not enough by themselves

Chrome updates automatically for most users, but a downloaded update normally needs a browser restart before the new binary is active. Long-running browser sessions, managed devices with deferred deployment rings and virtual desktop images can therefore remain exposed after the update has been released.

For enterprise defenders, the useful control is not merely “automatic updates enabled.” It is measurable proof that every browser process has restarted into a fixed build. Managed browser inventories should report the running version, not only the policy that is supposed to install it.

What defenders should do

• Update Chrome to 149.0.7827.102/.103 or later and restart the browser.
• Inventory Chromium-based browsers and check each vendor’s fixed release independently.
• Use endpoint and browser-management telemetry to find devices still running vulnerable processes.
• Prioritise high-risk users and systems that access untrusted or externally supplied links.
• Review web-proxy, endpoint and crash telemetry for unusual renderer failures around suspicious browsing events, while recognising that Google has not published a definitive exploit signature.

The broader lesson is that browser patch latency is measured in process lifetimes, not release dates. When a web page can reach a memory-corruption primitive and exploitation is already confirmed, a patch that has downloaded but not restarted is not yet a control.

Sources: Google Chrome Stable Channel update (8 June 2026; no publication time provided), NVD record (8 June 2026 at 20:16 UTC), and Canadian Centre for Cyber Security advisory (8 June 2026; no publication time provided).