Google Chrome EUVD-2026-105432

Exploitation requires a victim using a Google Chrome build prior to 156.0.8078.47 to load attacker-controlled HTML (via a malicious or compromised site, or embedded content), satisfying the UI:R user-interaction requirement in the CVSS vector. No authentication or special privileges are needed (PR:N) and default browser configurations are vulnerable. The key limiting factor is that code execution is confined to the renderer sandbox (S:U), so meaningful host compromise additionally requires a chained sandbox-escape vulnerability - raw renderer RCE alone cannot access the underlying OS.

Multiple signals converge on this being a genuine but not emergency-tier priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8) indicates a network-reachable, low-complexity, unauthenticated flaw requiring only that a victim load a crafted HTML page - a trivially satisfiable interaction for a browser. Critically, the description states code execution occurs 'inside the sandbox,' and the unchanged scope (S:U) corroborates this: successful exploitation yields renderer-process compromise, NOT full host takeover, so a separate sandbox-escape chain would be required for system-level impact. This materially tempers real-world risk versus a raw reading of the 8.8 score. No EPSS score was supplied, so exploitation probability cannot be quantified. The CVE is NOT in CISA KEV and no public POC is referenced, meaning there is no public exploit identified at time of analysis and no evidence of active exploitation. No SSVC decision data was provided. Net: a High-severity, patched renderer UAF typical of Chrome's regular release cadence - patch promptly given Chrome's ubiquity and the ease of drive-by delivery, but absent KEV/POC/EPSS signals it does not warrant out-of-band emergency response.

An attacker hosts or compromises a web page containing malicious HTML/JavaScript that triggers the use-after-free in Chrome's Transactions Platform component when a victim visits it. Exploiting the freed-memory condition lets the attacker corrupt memory and execute arbitrary code within the renderer sandbox. No public proof-of-concept is referenced, and full host compromise would require chaining an additional sandbox-escape vulnerability.