Severity by source
Sources disagree (Medium–Critical)AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N
Site isolation bypass crosses site security authority boundaries warranting S:C; AC:H reflects mandatory renderer pre-compromise; no availability impact described.
vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.
CVSS VectorCISA-ADP
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N
Lifecycle Timeline
3DescriptionCVE.org
Insufficient policy enforcement in File System Access in Google Chrome prior to 149.0.7827.155 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted PDF file. (Chromium security severity: High)
AnalysisAI
Site isolation bypass in Google Chrome prior to 149.0.7827.155 enables a remote attacker who has already compromised the renderer process to cross site isolation boundaries by delivering a crafted PDF file through the File System Access API. Chromium's internal severity is rated High despite NVD scoring this at 4.2/Medium - the gap reflects the high attack complexity bar of requiring a pre-compromised renderer. No CISA KEV listing exists and EPSS sits at 0.29% (21st percentile), placing this in a low-urgency exploitation tier; however, its value as a post-exploitation pivot in multi-stage attack chains targeting high-value users should not be dismissed.
Technical ContextAI
The vulnerability is rooted in Chrome's File System Access (FSA) API, a browser interface that grants web applications structured access to the local file system under strict origin-scoped policies. Chrome's site isolation architecture confines each renderer process to a single site's content - a critical security boundary preventing cross-origin data exfiltration. CWE-284 (Improper Access Control) identifies the root cause class: the FSA component fails to adequately enforce its access policies when a specially crafted PDF file is processed inside an already-compromised renderer, allowing that renderer to access resources outside its intended site context. The affected product per CPE is cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*, covering all desktop platforms. Tags noting Red Hat and SUSE indicate downstream Chromium-based packages in Linux distributions carry the same exposure.
RemediationAI
The primary fix is upgrading Google Chrome to version 149.0.7827.155 or later, as released via the Chrome stable channel and documented at http://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_01750511403.html. Chrome's built-in auto-update mechanism will handle this for most consumer users; administrators of enterprise Chrome deployments should verify the update has applied via chrome://version and push updates through their management console if automatic updates are suppressed. Red Hat and SUSE administrators should apply updated Chromium packages from their distribution security channels. No standalone workaround for this specific FSA policy enforcement gap is documented; however, since exploitation requires a pre-compromised renderer as a prerequisite, ensuring Chrome's renderer sandbox is not disabled via enterprise policy (e.g., '--no-sandbox' flags) meaningfully raises the bar for the required first-stage exploit, providing indirect compensating control while the patch is deployed.
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Package Hub 15 SP7 | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-37545