Google Chrome CVE-2026-78911

Exploitation requires two chained conditions: (1) the attacker must already have achieved code execution within the Chrome renderer process via a separate, independently exploited vulnerability - this is an explicit prerequisite stated in the CVE description, not an optional condition; and (2) social engineering must be used to facilitate the crafted HTML page interaction, confirmed by UI:R in the CVSS vector. The attack is delivered over the network (AV:N), meaning the victim visits a malicious page, but the renderer compromise prerequisite substantially raises the real-world bar. Exploitation is further limited by AC:H, reflecting the multiple coordinated conditions required. What limits exploitation: absence of a standalone exploitation path (renderer compromise must precede USB authorization abuse), requirement for user interaction, and the need to chain two distinct vulnerability classes. There is no indication this requires a specific USB device to be physically attached - the flaw appears in the authorization logic rather than device interaction itself.

CVSS 8.3 (High) with S:C (scope change) correctly captures the sandbox-escape nature of this flaw, but the AC:H and UI:R modifiers are critical context: exploitation is not straightforward. The attacker must independently compromise the renderer process - a separate, non-trivial prerequisite - and then leverage social engineering to achieve the USB authorization bypass. EPSS at 0.34% (26th percentile) reflects this high attack complexity and the absence of public exploit code. SSVC confirms Exploitation: none and Automatable: no, directly contradicting any urgency narrative based on CVSS score alone. Technical Impact is rated 'total' by SSVC, meaning successful exploitation achieves full system compromise - but reaching that point requires chaining multiple exploitation steps. This is a high-severity-if-chained, low-immediacy-standalone vulnerability. No CISA KEV listing. Real-world priority: patch promptly given Chrome's ubiquitous deployment, but this is not an emergency for most organizations absent evidence of active exploitation.

An attacker controlling a malicious or compromised website first exploits a separate renderer-process vulnerability in a victim's Chrome browser to gain code execution within the sandboxed renderer. From that foothold, the attacker serves a crafted HTML page that manipulates the USB IPC channel and exploits the incorrect authorization logic to issue privileged USB requests the renderer should not be permitted to make, causing the browser process to execute attacker-controlled code outside the sandbox. No public proof-of-concept or exploit code for this specific USB authorization flaw has been identified at time of analysis.