Google Chrome CVE-2026-11286

Two stacked conditions are explicitly required: (1) the attacker must have already achieved renderer process compromise in Chrome via a separate vulnerability - this is stated verbatim in the CVE description and is the dominant exploitation barrier; (2) a victim user must interact with the crafted HTML page (CVSS UI:R). The Wallet feature must be active and accessible in the target Chrome instance; enterprise deployments with payment features disabled via policy eliminate this attack surface entirely. CVSS PR:N reflects that no authentication to an external web service is required from the attacker's perspective, but does not diminish the renderer-compromise prerequisite. Exploitation is scoped to desktop Chrome; mobile Chrome (iOS/Android) uses distinct code paths and is not confirmed affected by available data.

CVSS 4.3 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N) conveys network-reachable, low-complexity exploitation with no required privileges but mandatory user interaction and limited integrity impact. However, there is a material discrepancy between the CVSS vector and the description: PR:N suggests no authenticated access is needed, yet the description explicitly requires prior renderer process compromise - a non-trivial, separate exploit step that effectively raises the true attack complexity well above AC:L. This is a compound vulnerability condition that automated CVSS-based scoring does not capture. EPSS at 0.05% (15th percentile) corroborates low real-world exploitation probability. No KEV listing exists, no POC has been identified, and Google internally classifies this as Low severity. Real-world priority is low: exploitation requires chaining two distinct vulnerabilities, with the primary barrier being a renderer RCE that in practice is substantially harder to achieve than the Wallet spoofing step itself.

An attacker first exploits a separate, higher-severity Chrome renderer vulnerability to achieve code execution within a sandboxed renderer process - this is the hard prerequisite. With renderer control established, the attacker crafts an HTML page that passes malformed or adversarially structured input across the renderer-to-browser IPC channel to the Wallet component, causing it to render spoofed payment or credential UI elements. A victim who interacts with the resulting false interface could be deceived into confirming a fraudulent transaction or disclosing sensitive payment credentials. No public POC for CVE-2026-11286 itself has been identified at time of analysis.