Google Chrome EUVD-2026-82488

Exploitation requires that the attacker has ALREADY compromised the Chrome renderer process (a prior separate vulnerability), then supplies a crafted PDF file that is handled by the Storage component to bypass site isolation. This is a defense-in-depth boundary bypass rather than an initial-access vector: the mandatory pre-compromised-renderer prerequisite, the crafted-PDF requirement, and the UI:R interaction element (per the CVSS vector) all sharply limit realistic standalone exploitation. Affected only prior to Chrome 153.0.8010.52; updating to the Stable channel build removes the flaw.

Low real-world priority despite affecting a ubiquitous product. The vendor CVSS3.1 base score is 3.1 (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N), and this is a defense-in-depth / post-exploitation weakness, not an initial-access bug: the description explicitly requires an attacker who 'had compromised the renderer process' before this flaw can be leveraged to bypass site isolation via a crafted PDF. That precondition is the dominant risk-limiter and is consistent with AC:H. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so exploitation status is 'no public exploit identified at time of analysis'; a Medium Chromium severity rating aligns with the low CVSS. Note a signal to verify: the CVSS vector is PR:N (unauthenticated) even though the description implies the attacker must already control a renderer - this reflects Chromium's convention of modeling a compromised renderer as a precondition rather than a privilege, so 'unauthenticated' here should not be read as 'trivially remote.' Impact is confidentiality-only (C:L, cross-site data disclosure), with no integrity or availability effect. Overall this is a high-prevalence-but-low-real-risk issue: valuable as a sandbox-hardening fix and useful as a chain link, but not an urgent standalone emergency.

An attacker first exploits a separate renderer RCE bug (e.g., a V8 or PDFium flaw) to gain code execution inside a Chrome renderer, then uses a crafted PDF processed through the Storage component to defeat site isolation and read data belonging to a different origin. No public exploit code was identified for this specific issue, and it is only meaningful as the second stage of a larger exploit chain rather than a standalone attack.