Google Chrome CVE-2026-78990

Exploitation requires that a user actively visits a crafted HTML page using a vulnerable version of Google Chrome (prior to 152.0.7977.65) on a desktop platform - user interaction (UI:R) is a hard prerequisite and mass automated exploitation is not feasible. No authentication, special browser configuration, or non-default settings are required to trigger the vulnerable code path; the Compositing engine processes standard HTML and CSS. The critical limiting factor is sandbox containment (S:U): arbitrary code execution is restricted to the Chrome renderer process, and achieving OS-level compromise would require chaining a separate sandbox escape vulnerability. Chromium's own Medium severity classification suggests that reliable heap grooming to control freed memory may impose additional practical complexity beyond what the CVSS AC:L metric implies.

The CVSS 8.8 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) places this squarely in the high-severity band, driven by network reachability and full C/I/A impact, but the unchanged scope metric (S:U) is the critical moderating factor - code execution is sandboxed. SSVC rates technical impact as 'total' yet exploitation as 'none' and automatable as 'no,' consistent with the UI:R requirement and absence of weaponized tooling. EPSS at 0.57% (45th percentile) aligns with no KEV listing and no confirmed public proof of concept, indicating this has not attracted widespread attacker attention at time of analysis. Chromium's own 'Medium' severity label further suggests the bug's practical exploitability is lower than the NVD score alone implies, likely because triggering the compositor race or lifecycle condition reliably requires careful heap grooming. This is a genuine patching priority for any Chrome fleet - the attack surface is every desktop browser session - but the lack of active exploitation and sandbox containment means it does not demand emergency out-of-band response ahead of normal patch cycles for most organizations.

An attacker registers a domain and hosts a crafted HTML page engineered to trigger the use-after-free in Chrome's Compositing engine during layer composition - for example, via JavaScript-driven DOM mutations timed to cause a compositor object to be freed and then accessed. The attacker distributes the URL via phishing email or malvertising; when a user on a vulnerable Chrome version visits the page, the freed memory is accessed, enabling arbitrary code execution within the Chrome renderer sandbox. No public proof-of-concept exploit has been identified at time of analysis, and sandbox escape would require a further vulnerability to achieve full OS-level impact.