CVE-2026-87437 in Chrome
Summary
by MITRE • 09/09/2026
Information leak in Frames in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to leak sensitive information via a crafted HTML page. (Chromium security severity: Low)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified as an information leak within the frame handling mechanisms of Google Chrome versions preceding 153.0.8010.36 represents a classic cross-origin data exposure flaw. This issue stems from improper isolation or boundary enforcement between different browsing contexts, specifically when frames are utilized to embed external content. In web architecture, frames allow a webpage to display another document within it, but strict security policies such as the Same-Origin Policy (SOP) and Cross-Origin Resource Sharing (CORS) dictate how data can be shared across these boundaries. The flaw in this iteration of Chrome indicates that under specific conditions involving crafted HTML structures, the browser failed to correctly restrict access to sensitive information contained within or associated with a frame from a different origin. This breakdown in isolation allows scripts running on an attacker-controlled page to read properties, content, or state data belonging to frames loaded from trusted but distinct domains, thereby bypassing intended security controls designed to prevent such cross-site data theft.
From a technical perspective, this vulnerability aligns closely with CWE-200, which categorizes information exposure as any situation where an application reveals sensitive information to an actor not explicitly authorized to access it. The attack vector relies on the creation of a malicious HTML page that leverages JavaScript APIs such as window.frames or document.getElementById to interact with embedded iframes. If the target frame contains dynamic content like user-specific data, session tokens, or internal application states, and if Chrome’s security model incorrectly grants read-access due to a logic error in how origin checks are performed for certain frame types or nested contexts, the attacker can extract this data. The severity is classified as low by Chromium standards because while the mechanism exists, successful exploitation often requires specific environmental conditions or user interaction that may limit widespread automated abuse, yet it remains significant enough to compromise confidentiality guarantees expected of a modern web browser.
The operational impact of this vulnerability centers on the potential for unauthorized surveillance and data theft against users visiting maliciously crafted websites. An attacker could construct a phishing page or a compromised legitimate site containing embedded scripts designed to probe frames loaded by other tabs or windows open in the same Chrome instance. By reading information from these frames, an adversary could gather sensitive details such as email contents, financial dashboard statuses, personal identification numbers, or authentication tokens if they are accessible via client-side scripting within those frames. This undermines user trust and privacy, potentially leading to further attacks like account takeover or targeted social engineering based on the harvested data. Although modern browsers have robust sandboxing, flaws in frame isolation remain a critical attack surface for lateral movement and information gathering during an intrusion scenario.
Mitigation strategies primarily involve upgrading Google Chrome to version 153.0.8010.36 or later, where these specific boundary checks and origin validation logic errors have been corrected by the Chromium development team. For organizations unable to immediately patch all endpoints, implementing strict Content Security Policy (CSP) directives can help mitigate risk by restricting how frames are loaded and what scripts they are permitted to execute. Specifically, enforcing frame-ancestors and sandboxing attributes in CSP headers limits the ability of external pages to embed content from sensitive domains without explicit permission. Additionally, developers should ensure that any data exposed via client-side APIs is carefully audited for sensitivity, avoiding the placement of highly confidential information within frames unless absolutely necessary and properly secured with appropriate HTTP headers like X-Frame-Options or frame-src CSP directives. Regular security assessments focusing on cross-origin resource sharing configurations are also recommended to identify similar misconfigurations before they can be exploited in production environments.