Google Chrome EUVD-2026-65832

Exploitation requires two mandatory preconditions: (1) the attacker must have already achieved code execution within Chrome's renderer process via a separate, independently sourced renderer vulnerability - this CVE alone provides no initial access; and (2) user interaction is required (CVSS UI:R), meaning the target user must navigate to or load a crafted HTML page. The vulnerability is restricted to confidentiality impact against sensor data only - no integrity or availability impact is possible (I:N/A:N). Exploitation is further limited to devices with accessible hardware sensors, making it most impactful on laptops and mobile devices with motion sensors. No authentication to Chrome or the underlying OS is required (CVSS PR:N), but the renderer pre-compromise requirement represents an equivalent practical barrier. There is no evidence of any specific non-default configuration being required beyond having Chrome's Sensor API available, which is the default state.

The CVSS 3.1 vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N scores 5.3 (Medium). The AC:H metric encodes the critical risk-moderating prerequisite: exploitation requires a fully functioning renderer process compromise via a separate, independently sourced vulnerability, which substantially raises the practical attack bar beyond what the headline CVSS score alone conveys. The C:H impact reflects that sensor data (gyroscope, accelerometer, orientation) is fully exposed if exploitation succeeds, but I:N and A:N confirm there is no write access or availability impact. EPSS at 0.26% (17th percentile) is consistent with the absence of a public POC and no CISA KEV listing, indicating this has not been observed in active exploitation campaigns. The CVSS and EPSS signals are aligned: this is a genuine but constrained risk appropriate for standard monthly patch cycle handling rather than emergency response. No conflicting data signals were identified.

An attacker first exploits a separate renderer-level vulnerability (such as a V8 engine or Blink flaw) to gain code execution within Chrome's sandboxed renderer process on the victim's machine. From the compromised renderer, the attacker sends unauthorized requests to the Sensor component - bypassing the missing authorization check - to read device sensor telemetry (e.g., gyroscope, accelerometer readings) via a crafted HTML page. This exfiltrated sensor data could support fingerprinting, physical activity inference, or location estimation attacks, though it does not grant code execution or data write capabilities.