Google Chrome EUVD-2026-50688

Exploitation requires that the attacker has ALREADY compromised the Chrome renderer process - this is a sandbox-escape primitive, not an initial-access bug, so a prior renderer exploit (or a chained renderer RCE) is a hard prerequisite. The victim must also load attacker-controlled content: the crafted HTML page is delivered to and rendered by the browser (CVSS UI:R), so user interaction such as visiting a malicious or compromised site is needed. The vulnerable code path is Chrome's Payments component, and only versions prior to 151.0.7922.72 are affected. Limiting factors: the mandatory renderer-compromise foothold, the required page visit, and the fact that SSVC marks exploitation as not automatable and none observed - these substantially reduce realistic risk below what the raw 9.6 CVSS suggests.

Signals conflict and must be weighed together. The CVSS base score of 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) looks critical, but it models only the escape stage; the description states the attacker must have ALREADY compromised the renderer process, so this is a second-stage bug that cannot be exploited from a clean starting position on its own. Google's own Chromium severity rating is only Medium, consistent with that chaining requirement. CISA SSVC reports Exploitation: none, Automatable: no, and Technical Impact: total - the 'total' impact aligns with a full sandbox escape, while 'none/no' indicate no observed exploitation and no easy mass-automation. EPSS is low (0.21%, 11th percentile) and there is no KEV listing and no identified public exploit. Net: this is a genuinely serious escape primitive if chained with a renderer RCE, but as an isolated issue the real-world urgency is moderate - patch on the normal Chrome auto-update cadence rather than as an emergency. The apparent contradiction between the 9.6 score and Google's Medium rating is explained by the required prior renderer compromise; do not treat the 9.6 as standalone remote-unauthenticated risk.

An attacker first compromises the Chrome renderer process using a separate memory-corruption or logic bug (for example via a malicious ad or a booby-trapped web page), then serves crafted HTML that drives the Payments component with malformed input to escape the sandbox and gain browser-process-level execution on the victim's machine. No public exploit is identified at time of analysis, and the attack depends on chaining with a working renderer exploit, so it is realistic mainly for well-resourced or targeted attackers.