Google Chrome EUVD-2026-65988

Exploitation requires that the victim actively visits a crafted HTML page, confirming the UI:R condition from the CVSS vector - passive network exposure is insufficient. The attacker must successfully apply social engineering to induce this navigation. The vulnerable component is specifically the Device subsystem of Chrome, meaning exploitation is relevant where users have connected peripherals accessible via browser device APIs (WebUSB, WebHID, Web Serial, Web Bluetooth). Chrome must be running a version prior to 152.0.7977.65. No server-side misconfiguration or non-default Chrome setting is required - the flaw exists in standard Chrome installations. Limiting factors: the social engineering requirement prevents automated or drive-by exploitation at scale; the integrity-only, limited-scope impact constrains what an attacker gains even on success; and no authentication bypass to system-level resources beyond the browser's device API gating is implied.

The CVSS 3.1 base score of 4.3 (Medium) reflects a network-reachable but user-interaction-dependent flaw with limited impact (integrity only, I:L; no confidentiality or availability impact). EPSS at 0.29% (21st percentile) strongly corroborates low exploitation probability in the wild. The vulnerability is not listed in CISA KEV and no POC has been reported, indicating this has not been weaponized at time of analysis. The UI:R requirement is a meaningful friction point - exploitation depends entirely on convincing a target to visit a malicious page, raising the bar above purely automated attacks. The integrity impact is limited in scope (S:U), confining the bypass to the browser's own device permission model rather than achieving full system compromise. Real-world priority for patching is moderate: the ubiquitous deployment footprint of Chrome means the exposed surface is enormous, but the actual exploitation likelihood per host is low given the social engineering prerequisite and absent public exploit code.

An attacker crafts a malicious HTML page that triggers a Device component authorization check in a way that bypasses Chrome's access restriction logic. Through social engineering - such as a phishing email or a redirect from a compromised site - the victim is lured into visiting the page in a vulnerable Chrome version. Upon page load, the crafted content exploits the CWE-863 flaw to gain unauthorized access to device-level resources (e.g., a connected USB or HID device) without the expected permission prompt or policy check firing correctly.