Google Chrome EUVD-2026-66051

Exploitation requires that the attacker has already achieved compromise of the Chrome renderer process on macOS - this is an explicit prerequisite stated in the CVE description ('had compromised the renderer process') and represents a substantial technical barrier, typically requiring a separate, higher-severity browser vulnerability. The victim must also actively visit or interact with a crafted HTML page (UI:R). The vulnerability is limited to macOS; Chrome on other platforms is not described as affected. The CVSS PR:N reflects that no external authentication to the target host is required, but the renderer compromise prerequisite is the dominant limiting condition for real-world exploitation.

The CVSS 3.1 score of 4.3 with AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N reflects limited integrity-only impact and no confidentiality or availability concern. However, the NVD vector does not capture the most significant risk-limiting factor: exploitation requires the attacker to have already compromised the Chrome renderer process, which is itself a separate and typically higher-severity vulnerability chain step. The AC:L rating in the provided vector may overstate ease of exploitation for this reason - this analysis rates it AC:H independently. EPSS at 0.21% (11th percentile) corroborates low real-world exploitation probability. No KEV listing confirms active exploitation, and no public proof-of-concept has been identified. Chromium's own internal severity classification of 'Low' is consistent with all these signals. The macOS-only scope further narrows the affected population. Security teams should apply the stable-channel update as part of routine patch cadence; this vulnerability does not represent a prioritized standalone threat absent a co-exploited renderer-level bug.

An attacker who has separately exploited a renderer process vulnerability in Chrome on macOS - for example via a memory-corruption bug in the JavaScript engine - then serves a crafted HTML page that manipulates how the browser process renders UI elements. The result could be a spoofed address bar or falsified padlock indicator, tricking the user into trusting a malicious site or dismissing a genuine security warning. No public proof-of-concept for this specific UI spoofing step exists at time of analysis.