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

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

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

Google Chrome for macOS (versions prior to 150.0.7871.47) contains a critical use-after-free vulnerability in WebUSB that permits local code execution when users authorize a malicious USB peripheral.. A patch is available.

How to fix or mitigate CVE-2026-13778?

Within 24 hours: Audit Chrome versions on macOS systems using endpoint management or MDM tools to identify vulnerable versions (all prior to 150.0.7871.47). Within 7 days: Deploy Chrome 150.0.7871.47 or later to all affected macOS systems through automated update mechanisms. Within 30 days: Verify patch compliance across all macOS endpoints and review USB device authorization policies to restrict peripheral connections to trusted devices where operationally feasible.

Google Chrome CVE-2026-13778

EUVD-2026-40464 HIGH

Use After Free (CWE-416)

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

GHSA-wh8g-jghw-8946

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

7.8

CVSS 3.1 · Vendor: google

Severity by source

Vendor (google) PRIMARY

7.8 HIGH

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

vuln.today AI

7.8 HIGH

Local malicious peripheral (AV:L) with no privileges but required user authorization of the device (UI:R); memory corruption yields full code execution, so C/I/A all High.

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

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

SUSE

HIGH

qualitative

Red Hat

8.2 HIGH

qualitative

Primary rating from Vendor (google).

CVSS VectorVendor: google

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 01, 2026 - 17:35 vuln.today

CVSS changed

Jul 01, 2026 - 15:22 NVD

7.8 (HIGH)

CVE Published

Jun 30, 2026 - 23:16 cve.org

UNKNOWN (no severity yet)

CVE Published

Jun 30, 2026 - 23:16 cve.org

HIGH 7.8

DescriptionCVE.org

Use after free in WebUSB in Google Chrome on Mac prior to 150.0.7871.47 allowed a local attacker to execute arbitrary code via a malicious peripheral. (Chromium security severity: Critical)

AnalysisAI

Local arbitrary code execution in Google Chrome for macOS (versions prior to 150.0.7871.47) stems from a use-after-free in the WebUSB implementation, which Chromium rates Critical. A local attacker who can present a malicious USB peripheral to a victim who authorizes it can corrupt renderer memory and run attacker-controlled code within the browser's context. There is no public exploit identified at time of analysis, and EPSS is low (0.16%, 5th percentile), reflecting limited likelihood of widespread opportunistic exploitation.

Technical ContextAI

WebUSB is a browser API that lets web pages communicate directly with USB devices after the user grants per-device permission, exposing raw device I/O to renderer-side JavaScript and native handling code. The flaw is CWE-416 (Use After Free): a heap object tied to a USB device/transfer is freed while a dangling reference to it remains, and subsequent access lets an attacker reallocate that memory with controlled data, leading to memory corruption. Per the CPE (cpe:2.3:a:google:chrome), the affected component is the Chrome application itself; the description scopes impact specifically to the macOS build, where the malicious peripheral's device descriptors or transfer responses drive the vulnerable code path.

RemediationAI

Vendor-released patch: update Google Chrome on macOS to 150.0.7871.47 or later, as delivered through the stable channel update announced at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html; restart the browser to ensure the update applies. Because Chrome auto-updates, verify via chrome://settings/help across managed endpoints and force-push the update through MDM/enterprise policy where auto-update is disabled. If patching must be delayed, reduce exposure by disabling or restricting the WebUSB API through enterprise policy (for example the DefaultWebUsbGuardSetting / WebUsbAskForUrls / WebUsbBlockedForUrls policies) to block sites from requesting USB device access - the trade-off is breaking legitimate WebUSB-based web apps (hardware keys, firmware/flashing tools) - and by advising users not to authorize WebUSB access for untrusted devices or sites.