Google Chrome CVE-2026-17794

Exploitation has two mandatory prerequisites confirmed by the CVE description: (1) the attacker must have already compromised the Chrome renderer process on the target device - this is an explicit, non-negotiable precondition making this a chained second-stage vulnerability; and (2) the victim must interact by visiting a crafted HTML page (user interaction required, consistent with CVSS UI:R). The vulnerability is scoped exclusively to Google Chrome's Mobile code path on Android; Chrome on Windows, macOS, Linux, or iOS is not identified as affected. Factors that limit exploitation: the renderer compromise prerequisite is itself a high-severity attack requiring a separate exploit; user interaction is required; impact is limited to URL bar spoofing with no confidentiality or availability consequences. The CVSS PR:N reflects that no authentication to the target system is required, but the renderer compromise condition is functionally a high-complexity barrier.

The official CVSS base score of 4.3 with vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N reflects a network-reachable, low-complexity spoofing flaw, but the AC:L metric appears to underweight a critical attack prerequisite stated explicitly in the CVE description: the attacker must have already compromised the renderer process. This is a high-severity prerequisite in its own right and would justify AC:H under independent assessment. The EPSS score of 0.21% (11th percentile) confirms very low automated exploitation probability. There is no CISA KEV listing and no reported POC, so no public exploit identified at time of analysis. Real-world risk is almost entirely conditional on a chained renderer exploit - without that prerequisite satisfied, this vulnerability is unexploitable. Organizations with Chrome for Android in their environment should prioritize updating primarily because the full release (151.0.7922.72) likely addresses co-disclosed higher-severity renderer vulnerabilities that would make this spoofing flaw dangerous.

An attacker first exploits a separate, higher-severity renderer vulnerability in Chrome on Android to gain control of the renderer process on a victim device. From within the compromised renderer, the attacker delivers a crafted HTML page that abuses the Omnibox input validation flaw to display a trusted-looking URL - such as a corporate SSO portal or banking login - while serving attacker-controlled content. The victim, trusting the spoofed address bar, enters credentials or approves a sensitive action that is then exfiltrated.