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

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

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

Google Chrome desktop versions prior to 148.0.7778.216 contain a remote code execution vulnerability in the WebUSB component that allows attackers to execute arbitrary code when users visit malicious…. A patch is available.

How to fix or mitigate CVE-2026-10021?

Within 24 hours: Deploy Chrome 148.0.7778.216 or later via group policy/MDM to all managed Chrome instances. Within 7 days: Verify completion of updates across 95% of user base and confirm older versions are no longer present on endpoints. Within 30 days: Audit Chrome deployment policies to ensure automatic updates are enforced and conduct incident log review for potential exploitation indicators targeting WebUSB.

Google Chrome CVE-2026-10021

EUVD-2026-33163 HIGH

Improper Input Validation (CWE-20)

2026-05-28 Chrome

GHSA-4jm4-gh3x-cq86

Google RCE Red Hat Suse Chrome

8.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.8 HIGH

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

SUSE

HIGH

qualitative

Red Hat

9.6 MEDIUM

qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

May 29, 2026 - 12:24 vuln.today

CVSS changed

May 29, 2026 - 12:22 NVD

8.8 (HIGH)

CVE Published

May 28, 2026 - 22:25 nvd

UNKNOWN (no severity yet)

CVE Published

May 28, 2026 - 22:25 nvd

HIGH 8.8

DescriptionCVE.org

Insufficient validation of untrusted input in USB in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: Medium)

AnalysisAI

Remote code execution in Google Chrome desktop versions prior to 148.0.7778.216 allows a remote attacker to execute arbitrary code in the browser context by luring a victim to a crafted HTML page that abuses insufficient input validation in the WebUSB component. The flaw carries a CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and Chromium rates it Medium severity; no public exploit identified at time of analysis and it is not currently listed in CISA KEV. A vendor patch shipped via the Chrome Stable channel mitigates the issue.

Technical ContextAI

The defect resides in Chrome's USB subsystem - the WebUSB implementation that brokers JavaScript-initiated USB device interactions from web origins down to the browser's device service. Per the affected CPE (cpe:2.3:a:google:chrome:*) and CWE-20 (Improper Input Validation), the renderer or browser process fails to adequately sanitize untrusted data originating from a malicious HTML page before it is consumed by the USB code path, which can corrupt internal state and yield arbitrary code execution within the sandboxed renderer or, depending on the exact reachable component, the broader USB device process. WebUSB is a standardized Chromium attack surface that has historically been a fruitful source of memory-safety and validation bugs, which is consistent with the Chrome Releases advisory classification.

RemediationAI

Vendor-released patch: Chrome 148.0.7778.216 - update Chrome Desktop (Stable channel) to 148.0.7778.216 or later via the built-in updater (chrome://settings/help) or managed deployment, per the Chrome Releases advisory at https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_0877304591.html and the Chromium bug tracker entry https://issues.chromium.org/issues/497327715. For Chromium-derived browsers, install the corresponding downstream build that picks up this Chromium milestone. As a compensating control until patching completes, administrators can disable WebUSB via the enterprise policy DefaultWebUsbGuardSetting=2 (block) or WebUsbBlockedForUrls, which removes the vulnerable attack surface at the cost of breaking legitimate WebUSB-dependent sites and hardware-management web apps; restricting browsing to trusted sites via SafeSites/URL allowlists reduces but does not eliminate exposure since user-interaction-driven exploitation only requires one untrusted page load.