Google Chrome CVE-2026-121112

Exploitation requires that the attacker has ALREADY compromised the Chrome renderer process (this is a second-stage sandbox-escape bug, not a standalone entry point), plus the victim must load attacker-controlled crafted HTML content (UI:R). The affected component is the Permissions subsystem in Google Chrome versions prior to 157.0.8103.38. Limiting factors that reduce real-world risk: the mandatory pre-existing renderer foothold, high attack complexity (AC:H), required user interaction, and the fact that only pre-157.0.8103.38 builds are affected - current/updated Chrome installations are not vulnerable.

Signals are consistent in pointing to a serious but not emergency-grade issue. The CVSS 3.1 base score is 8.3 (High) with vector AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H: network vector, high attack complexity, user interaction required, and a scope change reflecting the sandbox escape. Note an important tension: the vector lists PR:N (no privileges), yet the description explicitly requires an attacker 'who had compromised the renderer process' - Chrome models this chained sandbox-escape prerequisite as attack complexity (AC:H) rather than privileges, but in practice it is a substantial precondition that makes this a second-stage bug, not a standalone remote exploit. CISA SSVC reinforces moderate urgency: Exploitation=none (no observed exploitation), Automatable=no, Technical Impact=total. There is no CISA KEV listing, no public PoC reference in the supplied data, and no EPSS score provided, so exploitation probability cannot be quantified from this input. The vuln.today Decision label is 'this_week', aligning with a patch-promptly posture rather than immediate emergency. Net: a real, patch-this-week priority given total technical impact and ubiquitous deployment, but the required renderer foothold, AC:H, and user interaction meaningfully constrain real-world exploitability, and no current evidence of active exploitation exists.

An attacker who has already achieved code execution inside Chrome's renderer process (via a separate first-stage bug) lures or keeps a victim on a crafted HTML page, then triggers the out-of-bounds read in the Permissions component to leak memory and escape the sandbox, potentially executing code on the host outside Chrome's protections. High attack complexity (AC:H) and the required prior renderer compromise make this a chained, targeted operation rather than a drive-by. No public exploit identified at time of analysis.