Google Chrome CVE-2026-79245

Exploitation requires two preconditions: (1) the attacker must have already achieved code execution within the Chrome renderer process, typically via a separate, independently exploitable renderer vulnerability - this is the primary gating condition; and (2) user interaction (UI:R) is required to trigger the UI-layer use-after-free, consistent with a user performing some browser action that exercises the vulnerable UI code path. The description also references a 'local program' as the delivery mechanism, which may imply a locally installed binary that interacts with Chrome, though this detail requires vendor clarification. Exploitation is limited to local attack vector (AV:L), ruling out direct remote network exploitation without a preceding renderer-stage chain. High attack complexity (AC:H) reflects the chained nature of the full exploit. Attackers without existing renderer compromise capability cannot directly exploit this flaw.

The NVD CVSS score of 7.7 with vector AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H captures a high-complexity, multi-stage attack: local access vector, high attack complexity (chained renderer compromise required), user interaction needed, and a scope change to the host OS. Despite the high C/I/A ratings and scope change, AC:H and UI:R substantially reduce exploitability compared to a direct remote exploit. EPSS at 0.12% (2nd percentile) is consistent with this assessment - the attack requires chaining two distinct vulnerabilities, significantly narrowing the pool of capable threat actors. No CISA KEV listing or public POC has been identified, suggesting exploitation remains within advanced threat actor capability rather than commodity toolkits. The primary real-world risk is to high-value targets where an adversary chains a renderer exploit with this sandbox escape; it is not a casual mass-exploitation risk. The 'local program' delivery mechanism noted in the description warrants clarification from Google as to whether this implies a separate local binary is required versus renderer-initiated IPC.

An attacker first exploits a separate renderer vulnerability (e.g., a type confusion or OOB read in V8 or Blink) to gain code execution inside the sandboxed Chrome renderer process. From there, they craft inter-process communication messages that trigger the use-after-free condition in the browser process's UI component, corrupting freed heap memory to redirect execution flow. This second-stage exploit escapes the Chrome sandbox, achieving arbitrary code execution with the privileges of the Chrome browser process on the host OS. No public POC has been identified; this attack pattern requires advanced exploit development capability.