Google Chrome EUVD-2026-50932

Exploitation requires two distinct conditions: first, the attacker must have already achieved code execution within Chrome's renderer process via a separate, unrelated vulnerability - this is a significant prerequisite not captured by the PR:N CVSS metric and substantially limits who can exploit this flaw. Second, the victim user must interact with a crafted HTML page (UI:R), meaning passive drive-by exploitation without user action is not possible. The Lens-specific flaw is triggered from within the compromised renderer context via the crafted page. Limiting factors include: the renderer compromise prerequisite (requires a separate exploit), required user interaction, and the impact being confined to UI integrity only (no data exfiltration or code execution from this CVE alone). This flaw is not exploitable against default Chrome configurations without a renderer compromise already in place.

The NVD CVSS score of 4.3 (Medium) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N reflects a network-reachable flaw with low integrity impact and no confidentiality or availability impact. However, this vector is potentially misleading: the description explicitly states that the attacker must have already compromised the renderer process, a prerequisite not captured by PR:N or AC:L. In practice, chaining a renderer exploit with this Lens flaw raises the effective attack complexity significantly beyond what the base CVSS suggests. EPSS at 0.16% (6th percentile) corroborates very low exploitation likelihood. SSVC signals no known exploitation and non-automatable attack. The Chromium team rated this Low severity internally. The integrity impact is limited to UI spoofing - no code execution, data exfiltration, or persistent compromise is indicated. Real-world priority is low for most organizations, though the renderer-compromise prerequisite means this is most relevant as a second-stage primitive in a broader browser exploit chain.

An attacker serving a crafted HTML page first exploits a separate renderer process vulnerability to gain code execution within Chrome's sandboxed renderer. From that foothold, the attacker leverages the inappropriate Google Lens implementation to render spoofed UI elements - such as a fake security prompt, a misleading URL indicator, or a fraudulent permission dialog - tricking the user into believing they are interacting with a legitimate browser interface when they are not. No public exploit code or proof-of-concept has been identified at time of analysis, and this scenario requires chaining at least two vulnerabilities.