Google Chrome EUVD-2026-66032

Exploitation requires the victim to be running Google Chrome prior to version 152.0.7977.65 on any supported desktop platform. The attacker must successfully social-engineer the victim into visiting a crafted HTML page - passive drive-by exploitation is possible if the victim can be directed to an attacker-controlled URL, but requires at least one user interaction (UI:R per CVSS). No attacker-side authentication or privileges are required (PR:N). No special Chrome configuration or non-default feature flag is cited as necessary; the FileSystem API is enabled by default in Chrome. The primary limiting factor is the mandatory user interaction: automated, worm-style propagation without any user action is not feasible with this vulnerability. Additionally, Chrome's sandbox architecture may constrain what memory is practically accessible, consistent with the vendor's 'Low' internal severity classification.

The CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) reflects a network-delivered, low-complexity attack requiring no attacker privileges but mandating user interaction. The High confidentiality rating is significant - if exploitation succeeds, the attacker can read memory outside the sandbox, which may contain sensitive session data, credentials, or other in-memory content. However, the Scope metric is recorded as Unchanged (S:U) by the vendor, which arguably conflicts with the description's claim of reading memory 'outside the sandbox' - a potential sandbox escape would typically warrant S:C; security teams should verify this metric against the Chromium issue tracker at issues.chromium.org/issues/513361380. EPSS at 0.17% (7th percentile) and the absence of a CISA KEV listing confirm that exploitation is not currently widespread. The social engineering prerequisite creates a meaningful friction barrier: an attacker must persuade a target to visit a crafted page. Chrome's internal severity classification of 'Low' further tempers urgency despite the High CVSS confidentiality impact, suggesting the exploitable memory range or data quality accessible may be limited in practice. Overall, this is a moderate-priority patch for most organizations, elevated by Chrome's ubiquity rather than exploitation probability.

An attacker crafts a malicious HTML page that triggers the out-of-bounds read in Chrome's FileSystem implementation and hosts it on an attacker-controlled domain. The attacker then uses phishing email, a malicious advertisement, or a compromised trusted site to socially engineer the victim into clicking a link and loading the page in an unpatched Chrome browser. Upon page load, the flaw is triggered, reading memory from outside the renderer sandbox and potentially transmitting the leaked contents back to the attacker via HTTP requests embedded in the page logic. No public exploit code has been identified at time of analysis.