Google Chrome V8 Type Confusion (Arbitrary Read/Write Zero-Day)

Overview

CVE-2025-6554 is a type-confusion vulnerability in V8, the JavaScript and WebAssembly engine at the heart of Google Chrome. On versions prior to 138.0.7204.96, a remote attacker who can get a victim to open a crafted HTML page can drive V8 into treating a memory object as the wrong type, yielding an arbitrary read/write primitive within the renderer process. This is the kind of primitive that underpins almost every modern browser exploit chain: once an attacker can read and write arbitrary memory, defeating the rest of the renderer is usually a matter of engineering.

The flaw was reported by Clement Lecigne of Google's Threat Analysis Group (TAG) on June 25, 2025 and mitigated the very next day, June 26, by a configuration change pushed to the Stable channel, with a full binary fix following in the desktop release. TAG specializes in tracking commercial-spyware vendors and state-sponsored actors, and Google confirmed it is aware that an exploit exists in the wild. CISA added the CVE to its Known Exploited Vulnerabilities catalog with a remediation deadline of July 23, 2025. It was one of several Chrome zero-days exploited during 2025.

Technical Details

Type confusion (CWE-843) occurs when code allocates or accesses a resource using one type but later operates on it as if it were an incompatible type. In V8, the optimizing compiler and the object model rely on precise type assumptions; if an attacker can violate those assumptions, for example by manipulating object shapes or exploiting a JIT optimization that fails to re-check a type after a side effect, the engine performs operations with mismatched field layouts. The practical result is that reads and writes intended for one structure land at attacker-controlled offsets, producing an out-of-bounds and ultimately arbitrary read/write capability.

NVD assigns a base score of 8.1 (High) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N. The vector reflects a network-reachable attack requiring user interaction (visiting a page), no privileges, and high confidentiality and integrity impact, with availability marked None because the primitive is a stable read/write rather than a crash. Because the bug is contained within the renderer, an attacker typically pairs it with a separate sandbox-escape (such as a Mojo or kernel bug) to reach full system compromise. Google fixed the issue in Windows 138.0.7204.96/.97, macOS 138.0.7204.92/.93, and Linux 138.0.7204.96.

Impact

• Arbitrary memory read and write inside the Chrome renderer process triggered purely by visiting a malicious or compromised web page.
• A reliable exploitation primitive that, chained with a sandbox escape, can lead to remote code execution on the host.
• Confirmed active exploitation, with reporting by Google TAG indicating likely use by a sophisticated or state-aligned actor.
• Affects Chrome across Windows, macOS, and Linux, and Chromium-based browsers until they ship the equivalent V8 fix.

Mitigation

1. Update Google Chrome to at least version 138.0.7204.96 on Windows and Linux, or 138.0.7204.92 on macOS (Stable channel update of June 30, 2025; configuration mitigation pushed June 26, 2025).
2. Fully restart Chrome after updating so the new V8 binary is loaded across all processes.
3. Update Chromium-based browsers (Microsoft Edge, Brave, Opera, Vivaldi) to the build that includes the corresponding V8 fix once each vendor publishes it.
4. In managed environments, enforce the minimum version via enterprise policy and confirm compliance through chrome://settings/help rather than trusting silent auto-update alone.
5. Federal Civilian Executive Branch agencies were required to remediate by July 23, 2025 under CISA BOD 22-01; adopt that as the latest acceptable patch date.

Detection

There is no reliable network signature for a V8 type-confusion exploit, because the malicious JavaScript is delivered over ordinary HTTPS and is typically obfuscated and target-specific. The primary control is therefore version assurance: inventory the Chrome version on every endpoint and flag anything below 138.0.7204.96 (Windows/Linux) or 138.0.7204.92 (macOS) as vulnerable. Centralized management consoles, Sysmon process-creation events that capture the chrome.exe command line and version, or a scripted read of the browser's version resource all give an authoritative inventory; remember to include per-user installations, which auto-update independently of system-wide ones.

For behavioral telemetry, exploitation usually requires a follow-on sandbox escape, so the observable signal is often the second stage rather than the V8 bug itself. EDR should watch for Chrome renderer processes (--type=renderer) that spawn unexpected children, perform cross-process handle manipulation, or load unusual modules. Renderer crashes carrying V8-related stack frames (for example frames referencing the optimizing compiler or object map handling) can indicate failed or unstable exploit attempts and are worth alerting on; ensure Chrome crash reporting is collected centrally rather than discarded.

Because Google TAG attributed the discovery to its spyware/state-actor tracking, treat any confirmed exploitation as a targeted intrusion: correlate the affected user with subsequent anomalous behavior such as new persistence mechanisms, credential access, or beaconing to freshly registered domains. Pull any indicators of compromise that Google or downstream researchers publish for the associated campaign into your detection stack. Finally, monitor for users being steered to one-off links or watering-hole sites immediately before Chrome activity, since delivery of these zero-days frequently relies on highly targeted social engineering rather than mass distribution.