CVE-2026-11645: Google Chromium V8 Out-of-Bounds Read/Write — Actively Exploited Browser RCE

Background

Google Chrome, Microsoft Edge, Brave, Opera, and Vivaldi all share the Chromium browser engine at their core, which means a vulnerability in the shared codebase affects every one of them simultaneously. The V8 JavaScript engine — the component that compiles and executes JavaScript on every page you visit — is a historically productive attack surface precisely because its optimising JIT compiler must perform aggressive transformations on untrusted code at high speed, often trading safety margins for performance.

CVE-2026-11645 is an out-of-bounds read and write vulnerability in V8’s TurboFan JIT optimising compiler. It was reported by security researcher “303f06e3” on April 27, 2026, and awarded a $55,000 bug bounty by Google. Google patched it on June 8, 2026, with an emergency stable channel update — simultaneously confirming that exploits were already active in the wild.

CISA added CVE-2026-11645 to the Known Exploited Vulnerabilities catalogue on June 9, 2026, with a remediation deadline of June 23, 2026, for federal agencies.

Technical Mechanism

V8’s TurboFan pipeline optimises JavaScript execution by analysing code paths, inferring types, and eliminating checks it judges to be redundant. The class of vulnerability here — bounds-check elimination — occurs when the optimiser incorrectly concludes that an array access is safe and removes the bounds check that would ordinarily validate the index.

The specific failure in CVE-2026-11645 occurs during TurboFan’s compilation of JavaScript that performs typed array operations. The optimiser performs incorrect bounds-check elimination in a code path involving numeric range analysis: under certain conditions, TurboFan’s range inference concludes an array index is provably within bounds when it is not.

The exploitation chain that follows from this primitive:

1. Heap corruption primitive: The out-of-bounds write gives an attacker a primitive to write to adjacent heap memory, corrupting V8 heap object fields.
2. Map pointer leak: By carefully spraying the heap and corrupting object Map fields (V8’s hidden type descriptors), an attacker can leak raw pointer values out of the V8 heap, defeating pointer compression.
3. ArrayBuffer length corruption: The attacker corrupts the byteLength field of a JavaScript ArrayBuffer object, giving themselves an oversized read/write window into the process heap.
4. Arbitrary read/write: With a corrupted ArrayBuffer, the attacker can read and write arbitrary process memory within the V8 renderer process.

At this stage, the attacker has achieved arbitrary code execution within the V8 sandbox. Elevating this to a full browser escape (escaping the renderer process sandbox) requires a separate sandbox escape primitive, which has not been publicly described but which attackers deploying this in-the-wild may have paired with an unpublished or undisclosed privilege escalation.

Real-World Exploitation Evidence

Google’s June 8, 2026 stable channel update release note stated: “Google is aware that an exploit for CVE-2026-11645 exists in the wild.” The company did not attribute exploitation to a specific threat actor or campaign at time of release, which is standard practice when an investigation is ongoing and disclosure would alert the operating actors.

As Google’s fifth confirmed Chrome zero-day of 2026, CVE-2026-11645 continues a pattern of in-the-wild V8 exploitation that has been consistent across recent years. Prior V8 zero-days have been attributed to both nation-state actors (North Korean threat groups have historically exploited Chrome V8 bugs in targeted spear-phishing campaigns) and commercial surveillance vendors deploying browser exploits against journalists and human rights defenders.

No public threat actor attribution for CVE-2026-11645 is available at time of writing.

Impact Assessment

CVE-2026-11645 carries a CVSS 3.1 base score of 8.8 (HIGH):

• Attack vector: Network — exploitation requires the victim to visit a malicious or compromised webpage
• Attack complexity: Low — no special conditions beyond convincing the target to load the exploit page
• Privileges required: None
• User interaction: Required — the victim must visit the malicious page
• Impact: High confidentiality, high integrity, high availability — arbitrary code execution within the renderer process

The practical impact depends on whether attackers are pairing this with a sandbox escape. As a standalone vulnerability, it provides renderer-level code execution — sufficient to read browser memory including cookies, session tokens, stored credentials, and page content. Combined with a renderer-to-browser process escape, it enables full system access.

Given that this is confirmed in-the-wild exploitation, any unpatched Chromium-based browser should be treated as an active risk for credential theft and potential full compromise.

Affected Versions

Remediation Steps

Update Chrome immediately. Navigate to chrome://settings/help or Help > About Google Chrome — Chrome will check for and apply the update automatically. Restart the browser to complete the update. Confirm the version reads 149.0.7827.103 (Windows/macOS) or 149.0.7827.102 (Linux) or later.

For Microsoft Edge: Check edge://settings/help for the Edge-specific patch; Microsoft typically ships Chromium security updates within 24–48 hours of Google’s release. If Edge has not yet shipped the patch, consider restricting Edge use for sensitive browsing until it does.

For Brave, Opera, and Vivaldi: Check their respective update mechanisms. All have committed to prompt Chromium security updates but may lag Google Chrome by a day or two.

Enterprise deployment: If you manage Chrome via policy (Google Admin Console, Intune, or GPO), verify that AutoUpdateCheckPeriodMinutes and update policies are not blocking the patch and force-push the update if needed. All unpatched Chromium-based browsers in a managed fleet should be considered at risk.

No workaround is available that maintains browser functionality. The only mitigation is updating. Disabling JavaScript entirely would prevent exploitation but would render most of the web non-functional.

Detection Guidance

In-the-wild zero-day browser exploitation is difficult to detect at the network level, as the exploit typically arrives over HTTPS and the initial stage executes silently in the renderer process.

Endpoint process monitoring: Look for unusual child processes spawned by Chrome renderer processes (processes named chrome.exe or Google Chrome Helper (Renderer) spawning shells, PowerShell, or network utilities). EDR tools with process tree visibility will surface this.

Version audit: Use your endpoint management platform (Intune, JAMF, Workspace ONE) to generate a report of Chrome versions across the fleet. Flag any endpoint showing Chrome below 149.0.7827.103. The patch was released June 8 — any device that has not self-updated within 48 hours of this release should be investigated for update policy issues.

Browser telemetry: If you have browser telemetry (Chrome Browser Cloud Management, Falcon for Chromium, etc.), review for unusual extension behaviour or memory usage spikes that may indicate heap spray activity.

Post-exploitation indicators: If you suspect exploitation has occurred, focus on browser process behaviour: unusual outbound network connections from renderer processes, credential dumping activity, or lateral movement from the workstation where browsing occurs.

Timeline

References

• Google Chrome Releases — Stable Channel Update for Desktop, June 2026
• Chromium Issue Tracker — Issue 506689381
• BleepingComputer — Google patches fifth Chrome zero-day bug exploited in attacks this year
• Help Net Security — Google patches Chrome zero-day CVE-2026-11645
• CISA Known Exploited Vulnerabilities Catalogue
• NVD — CVE-2026-11645