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

CVE-2026-13951 has a CVSS 3.1 base score of 8.3 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

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

Google Chrome desktop contains a vulnerability allowing attackers who have already compromised the browser's rendering component to further escalate their access to full browser privileges.. A patch is available.

How to fix or mitigate CVE-2026-13951?

Within 24 hours: notify users and IT of the available patch. Within 7 days: deploy Chrome 150.0.7871.47 or later via your standard update mechanism (auto-update, MDM, or group policy). Within 30 days: verify deployment coverage is ≥95% of Chrome installations and document completion.

Google Chrome CVE-2026-13951

EUVD-2026-40639 HIGH

Protection Mechanism Failure (CWE-693)

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

GHSA-54gw-x8gh-f524

Information Disclosure Google Red Hat Suse

8.3

CVSS 3.1 · Vendor: google

Severity by source

Vendor (google) PRIMARY

8.3 HIGH

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

vuln.today AI

8.3 HIGH

Network-delivered via crafted page (AV:N, UI:R); AC:H and dependence on a pre-compromised renderer, but no auth needed (PR:N); sandbox escape crosses trust boundary (S:C) with total impact.

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

4.0 AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

SUSE

HIGH

qualitative

Red Hat

8.7 MEDIUM

qualitative

Primary rating from Vendor (google).

CVSS VectorVendor: google

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 02, 2026 - 02:27 vuln.today

CVSS changed

Jul 02, 2026 - 00:22 NVD

8.3 (HIGH)

CVE Published

Jun 30, 2026 - 23:17 cve.org

UNKNOWN (no severity yet)

CVE Published

Jun 30, 2026 - 23:17 cve.org

HIGH 8.3

DescriptionCVE.org

Insufficient policy enforcement in USB in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium)

AnalysisAI

Sandbox escape in Google Chrome desktop before 150.0.7871.47 lets an attacker who has already compromised the renderer process break out of the renderer sandbox by abusing insufficient policy enforcement in the browser's USB (WebUSB) handling, delivered through a crafted HTML page. The flaw is rated Medium by Chromium but carries a high CVSS (8.3) due to the scope change from renderer to browser process; EPSS is low (0.21%, 11th percentile) and there is no public exploit identified at time of analysis. A vendor patch is available in the June 2026 Stable channel update.

Technical ContextAI

The vulnerability lives in Chrome's USB subsystem, most likely the WebUSB device-access path that a renderer can reach through Mojo IPC to the privileged browser process. CWE-693 (Protection Mechanism Failure) indicates the root cause is not memory corruption but a failure to correctly enforce a security policy - here the checks that should confine what a renderer may do with USB device access. Because the renderer sandbox relies on the browser process to enforce these policies, a gap in enforcement allows a renderer that is already under attacker control to reach functionality outside its trust boundary, producing the CVSS scope change (S:C). No CPE strings were supplied; affected products are identified from EUVD as Chrome builds prior to 150.0.7871.47 across the desktop Stable channel.

RemediationAI

Vendor-released patch: update Google Chrome to 150.0.7871.47 or later via the June 2026 Stable channel update (https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html); restart the browser to complete the update since Chrome staged updates only apply on relaunch. Chromium-based browsers (Edge, Brave, Opera, Electron apps) should take the corresponding vendor build once available. Where immediate patching is not possible, reduce exposure by disabling WebUSB through enterprise policy - the DefaultWebUsbGuardSetting policy set to 2 (block) prevents sites from requesting USB access, with the trade-off that legitimate WebUSB workflows (hardware security keys configured via WebUSB, device-management web apps) will break. Because the bug requires a compromised renderer first, keeping Chrome's site isolation enabled and avoiding untrusted sites further limits realistic reachability.