In early June 2026, Google pushed a Stable Channel update for desktop Chrome that fixed a batch of security issues. Most of those are the routine churn you expect from a browser with a JavaScript engine the size of V8. One of them is not routine. CVE-2026-11645 is an out-of-bounds memory access in V8 that Google has confirmed is being exploited in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog. If you run Chrome anywhere in your fleet, this is a drop-everything patch, not a next-sprint patch.
This is one of several Chrome zero-days Google has patched in 2026. That cadence is the real story underneath this single CVE, and we will get to it. First, the facts.
What CVE-2026-11645 Actually Is
The bug lives in V8, the engine that compiles and runs JavaScript and WebAssembly inside Chrome and every Chromium-derived browser. Google and downstream trackers describe it as an out-of-bounds read and write: malicious web content can push the engine to read from or write to memory beyond the bounds it was supposed to touch. According to the reporting, a remote attacker can leverage a crafted HTML page to corrupt memory and ultimately execute arbitrary code inside the browser's sandbox in versions prior to 149.0.7827.103.
It carries a CVSS score of 8.8, which lands it as high severity. That number is worth reading carefully rather than nodding at. An 8.8 with an attack vector of "network," low attack complexity, and no privileges required is exactly the shape of a drive-by browser exploit: a victim visits a page, and the page does the rest. There is no click-to-install, no credential prompt, no obvious tell. That profile is why browser zero-days are some of the most valuable bugs on the exploit market and why they get weaponized fast.
One detail keeps this honest. The reported impact is code execution inside the sandbox. V8 memory corruption on its own typically gets an attacker into the renderer process, which Chrome's site isolation and sandbox are specifically built to contain. A full compromise of the host usually requires chaining this with a separate sandbox-escape bug. We have not seen public confirmation of a paired escape in this campaign, so treat "arbitrary code execution in the browser" as serious but bounded. It is a foothold, not automatically game-over. That distinction should inform your response, not relax it.
"Exploited in the Wild" Is the Phrase That Matters
Google's release language is deliberately spare. It says an exploit for CVE-2026-11645 exists in the wild. Google routinely withholds technical detail on actively exploited bugs until a majority of users have updated, which is the correct call and also why you will not find a clean writeup of the exploit chain yet.
Here is the timeline that matters for risk. The flaw was reportedly discovered by an external researcher some weeks before the fix shipped, and Google credited the report through its bug bounty program. CISA added the CVE to KEV with a tight federal remediation due date under BOD 22-01. CISA does not assign short deadlines to theoretical risk. When a browser zero-day hits KEV with a deadline that tight, the agency is telling you exploitation is real and ongoing.
The asymmetry is the problem. Attackers can diff the patched V8 build against the previous one and reconstruct the vulnerability within hours to days. The moment the fix is public, every unpatched browser becomes a more attractive target, not a less attractive one, because the bug is now effectively documented. The clock you are racing is not "before someone finds this." It is "before someone who already has the exploit finds you, and before the next wave reverse-engineers it from the patch."
There is also a delivery angle worth naming. A V8 bug like this does not need the victim to download anything or run an installer. It needs a rendered page. That means the realistic delivery paths are the ones you cannot fully filter: a malicious ad served through a legitimate ad network, a compromised but otherwise trusted site, a watering-hole page aimed at a specific industry, or a link in a phishing message that simply needs to be opened in Chrome. Email gateways and EDR are not the primary controls here. The patch is the control. Everything else is mitigation around the edges.
Affected Versions and the Fix
The patched Stable builds are 149.0.7827.102 and .103 for Windows and Mac, and 149.0.7827.102 for Linux. If your Chrome reports a build at or above those numbers, you are covered for this issue. Anything below is exposed.
Two practical notes. First, Chrome's auto-update is good but not instant; the rollout happens over days, and a relaunch is required for the new binary to take effect. A machine that downloaded the update but has not been restarted is still running vulnerable code. Second, this is V8, which means the blast radius extends well past Chrome itself. Microsoft Edge, Brave, Opera, Electron-based desktop apps, and anything else built on Chromium ship the same engine and need their own vendor updates. Patching Chrome and forgetting the Electron app your team lives in all day is a common and expensive mistake.
To check and force the update: open the menu, go to Help, then About Google Chrome, let it pull the latest build, and relaunch. For fleets, your management tooling should be pushing 149.0.7827.102 or later and, critically, confirming the relaunch actually happened.
The Pattern: Recurring V8 Zero-Days
A single CVE is a patch. A run of exploited V8 zero-days across 2026 is a trend you should plan around. V8 is an enormous, performance-tuned, JIT-compiling target, and that combination of size and speed-optimization keeps producing memory-safety bugs that are both findable and exploitable. Google has poured real engineering into hardening it, and it is still the most attacked surface in the browser.
The operational takeaway is not "panic about Chrome." Chrome remains one of the better-defended pieces of software most organizations run. The takeaway is that the browser is now a primary, recurring attack surface and deserves the same patch discipline you already apply to your operating systems and internet-facing servers. If your browser patching is still informal, an opt-in nudge that users get to ignore, you have a structural gap. The browser is where your users meet untrusted code all day, every day. Treat it like the perimeter it actually is.
How Safeguard Helps
Safeguard treats client-side runtimes as part of your software supply chain, because they are. Chromium ships inside countless desktop applications, and our AIBOM and ML-BOM inventories surface where vulnerable engine versions like this V8 build hide across your products and dependencies, not just in the browser icon on the taskbar. When a CVE like CVE-2026-11645 lands in CISA KEV, our Multi-Agent TAOR Deep Think AI Engine cross-references active exploitation, your real exposure, and bounded impact so your team chases the findings that matter instead of every 8.8 in the feed. Multi-agent verification in the orchestration layer above the model is how we keep that signal clean and measure value as cost per verified finding. If browser and embedded-Chromium exposure is a blind spot in your supply chain view, reach out.