Google Chrome EUVD-2026-65849

Exploitation requires two distinct prerequisites that must both be satisfied. First, the attacker must have already achieved code execution within Chrome's renderer process via a separate vulnerability - the description explicitly states 'had compromised the renderer process' as a precondition, and this is corroborated by AC:H in the CVSS vector. Second, the target user must interact with a crafted HTML page (UI:R), which typically serves as the delivery mechanism for the initial renderer exploit. No special Chrome configuration or non-default feature enablement is required beyond the default printing subsystem being present. Exploitation is fundamentally limited by the renderer pre-compromise requirement: this vulnerability cannot be weaponized as a standalone RCE and must be chained with a separate renderer exploit. The CVSS PR:N indicates no authenticated access to Chrome or the target system is needed from the attacker's perspective; the barrier is technical complexity, not access control.

The CVSS 8.3 High score (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H) reflects severe potential impact tempered by meaningful attack prerequisites. AC:H is the critical moderating signal: this is not a standalone RCE - exploitation requires the attacker to have already compromised the renderer process via a separate, chained vulnerability. This two-bug-chain requirement is the defining constraint on real-world risk. EPSS at 0.25% (16th percentile) aligns with this elevated complexity, suggesting no observed mass exploitation. No CISA KEV listing confirms no confirmed active exploitation campaign at time of analysis. Despite these constraints, sandbox escape vulnerabilities are precisely the class of flaw sought by sophisticated threat actors (APT groups, commercial spyware vendors) for high-value targeted attacks - the CVSS C:H/I:H/A:H impact metrics reflect that a successful chain achieves full host-level compromise. This should be treated as a priority patch for any organization in high-threat environments, even given low EPSS.

An attacker first exploits a separate renderer-process vulnerability - such as a JavaScript engine or DOM memory corruption bug - to gain code execution within Chrome's sandboxed renderer when a target visits a malicious or attacker-controlled webpage. From within the compromised renderer, the attacker triggers a print operation and passes maliciously crafted input to the Chrome Printing subsystem, exploiting the improper input validation to achieve code execution outside the sandbox and at the host OS privilege level. No public proof-of-concept has been identified at time of analysis, but this two-stage chain pattern is well-established in targeted browser exploitation.