Google Chrome EUVD-2026-65795

Exploitation requires the victim to navigate to an attacker-controlled or compromised HTML page using Google Chrome prior to version 152.0.7977.65; the CVSS UI:R metric confirms this page visit is a hard prerequisite and passive drive-by exploitation without user navigation is not possible. The CVSS PR:N metric indicates no authentication is required on the attacker's side. No special Chrome flags, non-default configuration, or elevated Chrome profile permissions are required - the Canvas API is enabled in all default Chrome installations. Exploitation impact is limited strictly to confidentiality of cross-origin rendered pixel data; no code execution, data modification, or denial of service is achievable through this flaw alone. The practical value of the leaked data depends heavily on whether the victim is simultaneously authenticated to a sensitive cross-origin resource that renders meaningful content into the canvas context.

The CVSS 4.3 Medium score is internally consistent: network-accessible (AV:N), low complexity (AC:L), no attacker privileges required (PR:N), user interaction required (UI:R), unchanged scope (S:U), and only limited confidentiality impact (C:L) with no integrity or availability consequences. EPSS at 0.33% in the 25th percentile places this well below the exploitation-observed threshold for most vulnerability management programs, and there is no CISA KEV listing and no confirmed public exploit code - all signals align that opportunistic mass exploitation is not occurring. The mandatory user-interaction prerequisite (visiting a crafted page) blocks fully automated exploitation. Despite the network attack vector, this is a low-urgency item for most organizations: Chrome's auto-update mechanism typically closes the window before manual remediation is even scheduled, and even a small enterprise security team should be able to rely on that mechanism rather than emergency patching. Real-world risk is most meaningful in targeted scenarios where an attacker can precisely lure authenticated users with access to sensitive rendered web content.

An attacker hosts a crafted HTML page that loads a cross-origin resource (such as an authenticated internal application) into a hidden Canvas element and uses JavaScript to call getImageData() to extract rendered pixel data, bypassing Chrome's same-origin policy. The victim user, authenticated to the target cross-origin resource, is lured to the attacker's page via phishing or a compromised advertisement, triggering the pixel read without additional interaction. The attacker receives the leaked pixel data - which may reconstruct sensitive on-screen content - via an exfiltration channel embedded in the page.