Google Chrome EUVD-2026-35233

Exploitation requires that the victim run Google Chrome on macOS at a version below 149.0.7827.103, that the victim grant Web Bluetooth access to attacker-controlled content (UI:R in the CVSS vector - the chooser dialog and pairing approval are user-driven), and that an attacker-controlled Bluetooth peripheral be reachable to the victim's machine, either physically within BLE range or via an emulated peripheral exposed through a compromised local agent. The attack is bounded to macOS Chrome (Windows/Linux not implicated by the description), depends on Web Bluetooth being enabled (it can be disabled via enterprise policy DefaultWebBluetoothGuardSetting=2), and requires affirmative user consent at the chooser, which materially constrains opportunistic mass exploitation versus a no-interaction drive-by RCE.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H supports a high severity reading: network attack vector, low complexity, no privileges required, but user interaction is required (UI:R) - almost certainly the victim must grant Bluetooth pairing/permission to a malicious peripheral or visit a malicious page that initiates the Web Bluetooth chooser. Chromium rated the issue Critical internally, while NVD scored it 8.8 (High), reflecting the UI:R constraint. There is no public exploit identified at time of analysis and no CISA KEV listing, and EPSS data was not provided in the input; realistic exploitation requires Bluetooth proximity or convincing the user to interact with a malicious peripheral, which materially limits mass exploitation. Treat this as a high-priority patch for macOS Chrome fleets, particularly for users who routinely pair Bluetooth devices, but not an emergency on par with a fully unauthenticated drive-by RCE.

An attacker hosts a malicious page that calls navigator.bluetooth.requestDevice() and lures a macOS Chrome user into selecting an attacker-controlled peripheral (or a peripheral that impersonates an expected device) from the chooser dialog. Once paired, the malicious peripheral returns crafted GATT responses that drive the vulnerable code path in Chrome's Bluetooth handling, freeing an object while a dangling reference remains, then reclaiming the slot to hijack a virtual call and execute code in the renderer or browser process. No public exploit identified at time of analysis, but Chromium's Critical rating implies the vendor assessed reliable RCE as feasible.