Google Chrome CVE-2026-17906

Exploitation requires two sequential conditions to both be satisfied: (1) the attacker must have already achieved code execution within Chrome's renderer process via a separate, unchained vulnerability - this CVE is not independently exploitable and provides no initial access; and (2) the victim user must visit or be redirected to a crafted HTML page that triggers the Bluetooth IPC path (UI:R from CVSS). The high attack complexity (AC:H) formally encodes the renderer pre-compromise requirement. The Bluetooth subsystem must be accessible from the renderer's IPC context, which is the default configuration. Limiting factors include the necessity of chaining at least two distinct Chrome vulnerabilities, active user interaction, and the operational sophistication required to stage a multi-stage browser exploitation chain. This is NOT exploitable as a standalone network attack and does NOT affect default Chrome configurations without prior renderer compromise.

Real-world risk is moderate-to-low despite the sandbox escape classification. The provided CVSS 5.8 (AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L) is well-calibrated: AC:H encodes the renderer pre-compromise requirement, which is the dominant risk constraint. EPSS of 0.17% at the 7th percentile is low and consistent with the attack chain complexity - chaining two distinct Chrome vulnerabilities is a capability possessed by a narrow set of well-resourced threat actors. No KEV listing and no identified public exploit code further reduce immediate urgency for most organizations. However, sandbox escapes carry asymmetric strategic value: threat actors who hold a renderer RCE and pair it with this escape gain full OS-level access from a browser context, making this a high-value second-stage primitive in advanced persistent threat campaigns. Chromium's own 'Low' severity label reinforces that the team views the chaining requirement as the binding constraint. For most enterprise environments, this is a patch-on-schedule priority; for high-value targets facing nation-state adversaries, expedited patching is warranted.

An attacker first exploits a separate Chrome renderer vulnerability - such as a V8 JavaScript engine flaw - to achieve code execution within the sandboxed renderer process while the victim browses to or is redirected to a malicious HTML page. From within the compromised renderer, the attacker sends crafted Bluetooth IPC messages to the browser process that fail input validation checks, triggering the sandbox escape and elevating execution to the browser process privilege level. No public proof-of-concept code has been identified for this specific sandbox escape component, though the renderer pre-compromise step is the more complex prerequisite.