Google Chrome CVE-2026-19146

Exploitation requires two mandatory prerequisites: (1) the attacker must have already compromised the Chrome renderer process via a separate, independent vulnerability - this is captured by AC:H in the CVSS vector and is the primary limiting factor; (2) the victim user must interact with a crafted HTML page (UI:R), meaning the attacker must also control or influence the content the victim loads. The vulnerability is further constrained to Chrome on Android only - desktop Chrome on any platform is not affected. No authenticated access to the device or Chrome is required (PR:N), but the renderer compromise itself implicitly assumes a preceding successful exploit. Scope change does not occur (S:U), limiting impact to the GPU/renderer process sandbox. The combination of renderer-compromise prerequisite and user interaction makes automated mass exploitation (Automatable: no per SSVC) infeasible.

The NVD CVSS 3.1 score of 5.3 (Medium) with vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N accurately captures the dual constraints: AC:H reflects the hard prerequisite of a prior renderer compromise, and UI:R reflects user interaction with a crafted page. The C:H rating is scoped to the process sandbox, not the full device. SSVC assessment independently corroborates: Exploitation=none, Automatable=no, Technical Impact=partial - three signals all pointing toward low real-world urgency. No EPSS score was provided; given no KEV listing, no POC, and the renderer-compromise prerequisite, exploitation probability is likely very low. This is not a standalone critical risk - it is a second-stage leak primitive that only matters in the context of a larger, more complex exploit chain. The absence of integrity and availability impact (I:N/A:N) means the worst-case outcome is memory disclosure, not code execution or service disruption. The primary risk is to users already targeted by a sophisticated multi-vulnerability campaign.

An attacker operating a sophisticated campaign first exploits a separate, unspecified Chrome renderer vulnerability to gain control of the renderer process on a victim's Android device. Using that renderer foothold, the attacker serves a crafted HTML page that issues GPU commands designed to trigger reads of uninitialized GPU memory, then harvests the returned bytes to recover sensitive data - such as authentication tokens, decrypted content, or heap artifacts - from the process memory space. No public exploit code for this specific flaw exists at time of analysis.