Google Chrome CVE-2026-76046

Two distinct prerequisites must both be satisfied: (1) the attacker must have already compromised the Chrome renderer process via a separate, unrelated vulnerability - this is an explicit prerequisite stated in the CVE description, not an inferred condition; (2) a user must navigate to or be redirected to a crafted HTML page that triggers the malicious graphics operations (UI:R from CVSS). The vulnerability is specific to Android; Chrome on Windows, macOS, Linux, and iOS is not indicated as affected. Exploitation is therefore limited to Android users running Chrome prior to 151.0.7922.169 who encounter a two-stage attack chain. The high attack complexity (AC:H) from the CVSS vector directly reflects the renderer pre-compromise requirement. No special application configuration or non-default feature flag is required beyond a functioning Chrome browser on Android with an active ANGLE-backed graphics pipeline, which is default.

The CVSS 8.3 base score reflects the full C:H/I:H/A:H impact triad and a scope change (S:C), which captures the sandbox-escape characteristic accurately. However, the AC:H metric is the critical moderating factor: exploitation explicitly requires a pre-compromised renderer process, making this the second stage of a chained attack rather than a standalone remote exploit. In practice, operationalizing this vulnerability demands a separate renderer-level bug (e.g., a V8 or Blink memory corruption), meaning exploitation complexity and cost are substantially higher than the headline CVSS score implies. No EPSS score was provided in the source data; without that signal, statistical exploitation probability cannot be cited. The absence of a CISA KEV listing and no reported POC further suggests this has not yet been observed in widespread exploitation campaigns, though the sandbox-escape class of flaw is historically attractive to advanced threat actors for mobile targeting. Even a mid-sized enterprise security team should treat patching as urgent given Chrome's ubiquity on Android, though organizations with centrally managed Android fleets should prioritize the update over those with employee-owned devices where rollout lag is expected. EPSS data was not included in the provided intelligence; all exploitation probability assessment is therefore inferred from CVSS signals and threat class, not from empirical exploitation data.

An attacker operates a two-stage attack: first exploiting a separate renderer-level vulnerability (e.g., a JavaScript engine or DOM parser bug) to gain code execution within Chrome's sandboxed renderer process on an Android device. The attacker then serves the victim a crafted HTML page containing WebGL or graphics API calls designed to trigger the ANGLE heap buffer overflow, corrupting renderer heap memory in a controlled way to pivot code execution outside the sandbox and into the broader Android process space. No public POC has been identified at time of analysis, but this exploit class is consistent with techniques used in advanced mobile targeting campaigns.