CVE-2026-11645

What it actually does

This is a V8 JavaScript engine memory corruption vulnerability in Google Chrome before 149.0.7827.103. A crafted HTML page can trigger an out-of-bounds read and write condition, allowing attacker-controlled JavaScript to corrupt renderer memory and execute arbitrary code within Chrome's sandboxed renderer process. Successful exploitation can compromise confidentiality, integrity, and availability of browser data accessible to that process, and may become full system compromise if paired with a separate sandbox escape or privilege-escalation vulnerability.

Why it matters to the business

Because Chrome is widely deployed across Windows, macOS, and Linux endpoints and this vulnerability is listed in CISA KEV with active exploitation in the wild, unpatched systems can be compromised through normal web browsing, malicious links, compromised websites, or malicious advertising. The main operational risks are endpoint compromise, theft of browser-accessible data, session hijacking, malware delivery, and potential ransomware staging if attackers chain this browser exploit with additional vulnerabilities, even though ransomware use is not specifically indicated for this CVE. CISA KEV remediation is due by 2026-06-23 for covered organizations, making patch compliance time-sensitive.

How an attack unfolds

An attacker prepares a malicious web page containing JavaScript and HTML designed to trigger the V8 out-of-bounds read/write condition. The attacker then gets a target to load that page through phishing, a redirect, a compromised legitimate site, or malvertising. When the vulnerable Chrome renderer processes the page, the crafted JavaScript manipulates memory layout, triggers the bounds error, obtains read/write primitives, and pivots to execute attacker-controlled code inside the Chrome sandbox. From there, the attacker may steal data available to the browser process, run additional payload logic inside the renderer context, or attempt to chain a second exploit to escape the sandbox and gain broader operating system access.

How to fix it

Update Google Chrome to version 149.0.7827.103 or later on all supported platforms. Where Chrome is managed centrally, enforce browser auto-update, verify update policy compliance, and restart browsers so the patched version is actually loaded. Also update Chromium-based downstream browsers when vendor fixes are available, because V8 vulnerabilities are commonly inherited by Chromium derivatives. If immediate patching is not possible, reduce exposure by restricting access to untrusted websites, disabling or limiting JavaScript only where operationally feasible, using browser isolation for high-risk browsing, blocking known malicious URLs, and ensuring endpoint detection coverage is active. Mitigations should be treated as temporary because active exploitation is reported and the vulnerability is in CISA KEV.

How to confirm the fix worked

Confirm that installed Google Chrome versions are 149.0.7827.103 or later using enterprise software inventory, browser management consoles, endpoint management tools, or local version checks such as chrome://version. Validate that endpoints have restarted Chrome after updating, because a downloaded update may not protect running browser processes until restart. Review managed browser policies to ensure updates are not pinned, disabled, or delayed beyond the required remediation window. For exposure validation, search asset inventory for Chrome versions below 149.0.7827.103 across Windows, macOS, and Linux systems, and include Chromium-based browsers once their vendors publish corresponding fixes.

Typical attack path

1. Identify users running Google Chrome prior to 149.0.7827.103.
2. Host or inject a crafted HTML/JavaScript exploit page on attacker-controlled or compromised web infrastructure.
3. Deliver the page through phishing, redirects, watering-hole compromise, or malicious advertising.
4. Victim opens the page in a vulnerable Chrome browser.
5. Exploit triggers V8 out-of-bounds read/write memory corruption.
6. Attacker achieves arbitrary code execution inside the Chrome sandboxed renderer process.
7. Attacker attempts browser data theft, payload execution within the renderer, or chains a sandbox escape/privilege escalation for broader endpoint compromise.
8. Attacker establishes persistence or conducts follow-on activity if additional exploitation succeeds.

How to detect it

There are no universal public file hashes, URLs, or payload indicators provided for this vulnerability, so detection should focus on behavioral and forensic evidence. Review browser crash telemetry, Chrome crash dumps, endpoint detection alerts, web proxy logs, DNS logs, and EDR process telemetry for activity involving vulnerable Chrome versions shortly before suspicious endpoint behavior. Look for repeated renderer crashes followed by unusual browser child processes, unexpected downloads, script interpreters, command shells, credential access tools, or network connections to unfamiliar infrastructure. On Windows, review application crash events for chrome.exe and endpoint telemetry showing chrome.exe spawning cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, rundll32.exe, or regsvr32.exe. On macOS and Linux, review Chrome crash reports, system logs, and process execution telemetry for Chrome launching shell interpreters or writing unexpected executable files. Correlate suspicious browsing events, redirects, or ad traffic with subsequent endpoint compromise indicators. Because exploitation occurs through a crafted HTML page and may leave limited local artifacts if not chained with malware, absence of clear indicators does not prove non-exploitation.

What your security team should do

• Prioritize emergency patching of Google Chrome to 149.0.7827.103 or later because the vulnerability is actively exploited and listed in CISA KEV.
• Use endpoint management or browser management telemetry to identify and remediate all Chrome installations below the fixed version.
• Force browser restart after patch deployment and monitor for stale running vulnerable Chrome processes.
• Hunt for suspicious browser crashes, abnormal Chrome child-process behavior, unexpected downloads, and post-browser exploitation activity around the published and exploitation window.
• Apply additional scrutiny to users who clicked suspicious links or visited untrusted sites while running vulnerable Chrome versions.
• Ensure EDR policies monitor browser-to-script, browser-to-shell, and browser-to-unusual-child-process activity.
• Block known malicious delivery infrastructure if identified by threat intelligence, but do not rely on URL blocking as the primary control.
• Track Chromium-based browser advisories and patch downstream browsers that embed vulnerable V8 code.
• For organizations subject to CISA KEV requirements, complete remediation by 2026-06-23 and retain evidence of compliance.