Google Chrome CVE-2026-8576

User must be running Google Chrome on Linux or ChromeOS (Windows and macOS explicitly not vulnerable). Attacker must successfully social-engineer the victim into visiting a malicious website via phishing email, compromised advertisement, watering hole attack, or other delivery mechanism (UI:R requirement). Victim must have active authenticated sessions or cached credentials for target cross-origin sites that contain data the attacker wishes to steal. The vulnerability cannot be exploited through passive network observation or without victim browser interaction. Default Chrome configurations are vulnerable-no special settings or extensions required. The CORS implementation flaw is in Chrome's core rendering engine, not dependent on specific web application configurations, though the value of exploiting this vulnerability increases when victims access multiple sensitive domains in the same browser session.

Real-world risk is moderate but not critical based on multiple converging signals. CVSS 4.3 (Medium) accurately reflects the limited scope: network-accessible attack but requires user interaction (UI:R), produces only confidentiality impact (C:L), no integrity or availability effects, and unchanged scope (S:U). EPSS probability of 0.03% at 10th percentile indicates exploitation is uncommon in observed threat activity. SSVC framework confirms no current exploitation, non-automatable nature requiring social engineering to trick users into visiting attacker-controlled pages, and partial technical impact limited to data leakage. The platform-specific nature (Linux/ChromeOS only, excluding Windows and macOS) further reduces attack surface. Chrome's rapid release cycle and auto-update mechanism mean most users receive patches quickly, narrowing the exposure window. CISA has not added this to KEV, indicating no evidence of active targeting. This is appropriately prioritized as a standard patching issue rather than emergency response, though organizations with Linux-based Chrome deployments or ChromeOS fleets should prioritize the update for users handling sensitive cross-origin data.

An attacker hosts a malicious website containing crafted HTML and JavaScript designed to exploit the CORS flaw. Through phishing, malvertising, or compromised legitimate sites, the attacker tricks a Linux or ChromeOS Chrome user into visiting this page. The malicious code makes cross-origin requests that should be blocked by CORS policy but are incorrectly permitted due to the implementation flaw, allowing the attacker's page to read sensitive data from other origins the user is authenticated to-such as personal information from social media, internal corporate applications, or financial data from banking sites. The leaked data is exfiltrated to attacker-controlled servers. No public proof-of-concept code has been identified, but the conceptual attack is straightforward for skilled attackers familiar with CORS mechanics.