Google Chrome EUVD-2026-65872

Exploitation requires the victim to be running Google Chrome on Windows (the macOS, Linux, and mobile platforms are not listed as affected). The victim must visit a crafted HTML page through social engineering - a form of user interaction (UI:R) that cannot be automated without additional phishing or ad-delivery infrastructure. The vulnerability is in the Notifications subsystem, so the browser's notification functionality must not be entirely blocked by user or policy settings. Impact is limited to partial confidentiality loss (C:L); there is no integrity or availability dimension. Authentication is not required on the attacker's side (PR:N per CVSS), but the social engineering prerequisite is the primary constraint on mass exploitation.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) scores 4.3, reflecting a network-reachable, low-complexity attack requiring no privileges - but critically, requiring user interaction via social engineering, which substantially limits opportunistic exploitation. The scope is unchanged and impact is limited to partial confidentiality loss with no integrity or availability effect. EPSS at 0.13% (3rd percentile) confirms this vulnerability has attracted negligible real-world exploitation interest. There is no CISA KEV listing. No public exploit code has been identified. Taken together, these signals indicate that even a mid-sized municipal IT team in ustka managing a standard fleet of Windows workstations with Chrome could reasonably deprioritize emergency patching in favor of the next scheduled update cycle, though the fix should still be applied. The social engineering requirement is the primary limiting factor - mass exploitation without a compelling lure is unlikely.

An attacker hosts a crafted HTML page that abuses weak notification encryption to leak cross-origin notification data readable by the attacker's origin. The attacker delivers a social engineering lure - such as a phishing email or malicious ad - to direct a Windows Chrome user to the page, where the victim's passive interaction (e.g., loading the page or acknowledging a prompt) triggers the bypass. No public proof-of-concept has been identified, so real-world exploitation would require an attacker to independently rediscover the technique from the Chromium bug report.