What is the CVSS score of CVE-2026-10931?

CVE-2026-10931 has a CVSS 3.1 base score of 9.6 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Google Chrome are affected by CVE-2026-10931?

Google Chrome contains a critical vulnerability allowing attackers to gain complete control of employee workstations by directing users to a malicious website, potentially compromising sensitive…. A patch is available.

How to fix or mitigate CVE-2026-10931?

24 hours: Identify and inventory all Google Chrome deployments across managed systems and user devices. 7 days: Deploy Chrome version 149.0.7827.53 or later to all affected systems using your standard patch management process. 30 days: Verify deployment completion to at least 95% of systems and monitor security logs for exploitation attempts.

Google Chrome CVE-2026-10931

EUVD-2026-34380 CRITICAL

Use After Free (CWE-416)

2026-06-04 chrome-cve-admin@google.com

GHSA-2x65-jx2x-hg5p

Denial Of Service Use After Free Memory Corruption Google Red Hat Suse Chrome

9.6

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.6 CRITICAL

AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

SUSE

CRITICAL

qualitative

Red Hat

9.6 HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 05, 2026 - 20:22 vuln.today

CVSS changed

Jun 05, 2026 - 20:22 NVD

9.6 (CRITICAL)

CVSS changed

Jun 05, 2026 - 20:22 NVD

9.6 (CRITICAL)

CVE Published

Jun 04, 2026 - 23:16 nvd

CRITICAL 9.6

CVE Published

Jun 04, 2026 - 23:16 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

Use after free in FileSystem in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

AnalysisAI

Sandbox escape in Google Chrome's FileSystem component prior to version 149.0.7827.53 allows a remote attacker to break out of the renderer sandbox via a crafted HTML page that triggers a use-after-free condition. Successful exploitation requires the victim to interact with attacker-controlled web content, but yields a scope change from the constrained renderer process to higher-privileged host context. EPSS is currently low (0.03%) and no public exploit has been identified at time of analysis, though Google rates the underlying Chromium severity as High.

Technical ContextAI

The vulnerability resides in Chrome's FileSystem API implementation, which is part of the Blink rendering engine and Chromium's broader IPC-mediated file access subsystem. The root cause is CWE-416 (Use After Free), a memory-corruption class in which an object is referenced after its backing memory has been released, allowing an attacker who can influence reallocation to control the contents pointed to by a dangling pointer. Because the FileSystem component bridges renderer-side JavaScript and the browser process that brokers actual file operations, a UAF here is particularly impactful: it can be leveraged to corrupt state across the sandbox boundary, which aligns with the CVSS scope-changed (S:C) rating.

RemediationAI

Vendor-released patch: Google Chrome 149.0.7827.53 or later on the stable desktop channel - install via the auto-update mechanism or push managed updates through enterprise policy (see https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html). For Chromium-derived browsers, upgrade once the vendor ships a build that incorporates the upstream fix tracked in https://issues.chromium.org/issues/501115599. As a temporary compensating control for users who cannot update immediately, restrict use of the affected browser for untrusted browsing and consider disabling the FileSystem API via enterprise policy or browser flags where supported - the trade-off is broken functionality in web apps that rely on sandboxed file storage (some PWAs and editors). Site-isolation and Strict Site Isolation policies should be left enabled, as they raise the cost of exploiting renderer-process bugs even though they do not directly fix this sandbox-escape vector.