Google Chrome CVE-2026-106350

Requires the victim to actively open or navigate to an attacker-crafted HTML page in a vulnerable Chrome desktop build prior to 155.0.8059.39 (UI:R); there is no authenticated-session or special configuration prerequisite in the product itself. Exploitation is limited by that mandatory user interaction, by the confidentiality-only, vendor-rated-Low nature of the leak (no code execution or data modification implied), and by Chrome's automatic update mechanism, which rapidly closes the window on patched installations.

The signals here conflict sharply and must be reconciled before prioritization. The input CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 8.8 High) claims full high confidentiality, integrity AND availability impact, but the description characterizes the flaw strictly as an information-disclosure issue ('allowed a remote attacker to obtain sensitive information'), and the vendor (Chromium) explicitly rated the security severity as LOW. These are inconsistent: a pure info-leak should carry impact on confidentiality only (I:N/A:N), so the 8.8 score appears inflated and should not drive prioritization on its own - verify against Google's advisory. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or imminent exploitation. CWE-863 (incorrect authorization) combined with 'crafted HTML page' and UI:R points to a same-site/cross-origin data-leak reachable only when a victim is lured to a malicious page. Net assessment: despite the headline 8.8, the vendor's own 'Low' rating, the confidentiality-only description, the user-interaction requirement, and the absence of any exploitation signal indicate this is a routine browser info-leak to be remediated via normal Chrome auto-update cadence, not an emergency.

An attacker hosts a crafted HTML page and lures a victim running a Chrome build prior to 155.0.8059.39 to visit it (via phishing link, ad, or malicious redirect). An incorrect-authorization flaw in the browser then lets the page read sensitive information it should not be able to access (e.g., cross-origin or privileged browser data). No public exploit code was identified at time of analysis, and exploitation requires the user to open the attacker-controlled page.