Google Chrome CVE-2026-17945

Exploitation has a hard prerequisite: the attacker must have ALREADY compromised the Chrome renderer process through a separate, independent vulnerability prior to leveraging this flaw. This is not a minor configuration nuance - it represents a complete, higher-severity exploit primitive that must exist in the attack chain before CVE-2026-17945 contributes anything. Additionally, user interaction is required (CVSS UI:R), meaning the victim must actively visit the attacker's crafted HTML page during the same browser session in which the renderer is compromised. The impact is strictly limited to low integrity (UI spoofing); confidentiality and availability are unaffected. The vulnerability is not automatable per SSVC, and exploitation has not been observed. What limits exploitation: the renderer pre-compromise requirement, the user-interaction dependency, and the low-value-only spoofing outcome make opportunistic or mass exploitation implausible.

All available risk signals converge on low real-world priority. The CVSS 4.3 score reflects network reachability and no-privilege-required access but is capped by user interaction (UI:R), unchanged scope, and impact limited solely to low integrity - no confidentiality or availability loss. The EPSS probability of 0.17% places this in the 7th percentile, meaning 93% of CVEs are considered more likely to be exploited. SSVC independently rates exploitation as 'none,' automatable as 'no,' and technical impact as 'partial,' reinforcing that no exploitation activity has been observed. The single most significant risk limiter is the mandatory prerequisite of a pre-compromised renderer process, which is itself a non-trivial, higher-severity exploit primitive - this vulnerability cannot be weaponized standalone. The official CVSS vector (PR:N) does not fully capture this chaining requirement, slightly overstating ease of exploitation; defenders should treat effective attack complexity as high. There is no CISA KEV listing and no public POC, consistent with the Chromium team's own Low severity assessment.

An attacker who has separately achieved Chrome renderer process compromise - for example, through a concurrent memory corruption or type confusion flaw - could serve a crafted HTML page that triggers insufficient Navigation input validation, causing the browser's address bar or security UI to display a trusted origin (e.g., a banking domain) while the renderer serves attacker-controlled content, enabling phishing or credential harvesting. No public POC has been identified. The full chain requires the victim to visit attacker-controlled web content and a concurrent renderer-level exploit primitive.