Google Chrome EUVD-2026-50916

Exploitation requires that the attacker has ALREADY compromised Chrome's renderer process (a pre-existing initial-access bug is a hard prerequisite - this CVE is a sandbox-escape stage, not the initial entry). The specific trigger is a crafted PDF file processed through Chrome's WebAuthn input path, so the browser's PDF rendering must handle attacker-controlled content, and CVSS UI:R indicates the victim must open the malicious page/PDF. Affected only on Chrome desktop prior to 151.0.7922.72. Limiting factors: the mandatory prior renderer compromise, the required user interaction, and the fact that SSVC lists Automatable:no and EPSS is 0.16% - meaning this is not a self-propagating or drive-by-standalone condition despite the PR:N in the NVD vector (which does not account for the renderer-compromise prerequisite described by Google).

The signals here conflict sharply and must be weighed together. NVD's CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H = 9.6 Critical) reads as a near-worst-case network-reachable bug, but the description explicitly states the attacker must have 'compromised the renderer process' first - a substantial prerequisite that the PR:N/AC:L metrics do not capture. Verify with vendor: the CVSS vector implies unauthenticated network attack, but the description implies this is a second-stage sandbox escape usable only after an initial renderer compromise, which is why Chromium itself rated the severity 'Low.' The exploitation-focused signals align with the lower reading: EPSS is 0.16% (6th percentile), SSVC shows Exploitation:none and Automatable:no, and no public exploit is identified. The one signal that stays high is SSVC Technical Impact: total, reflecting that IF chained, a sandbox escape yields full control of the browser process. Net assessment: this is a genuine but chain-dependent bug, not a mass-exploitation priority. It matters most as the second link in an exploit chain, so patch promptly but it does not warrant emergency out-of-band response on the strength of the 9.6 alone.

An attacker first compromises the Chrome renderer through a separate bug (e.g., a prior renderer RCE), then serves or embeds a specially crafted PDF that, when rendered, drives malformed input into the WebAuthn handling to escape the sandbox and execute code in the higher-privileged browser process. Because CVSS marks UI:R, a user must open the page/PDF, and because it requires an already-compromised renderer, this is realistically the second stage of a multi-bug chain rather than a standalone drive-by. No public exploit code is identified at time of analysis.