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

CVE-2026-9880 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.0%.

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

Google Chrome versions prior to 148.0.7778.216 contain a sandbox escape vulnerability (no public exploit identified at time of analysis) that allows attackers with prior renderer process compromise…. A patch is available.

How to fix or mitigate CVE-2026-9880?

Within 24 hours: Inventory all Chrome deployments and identify systems running versions before 148.0.7778.216. Within 7 days: Deploy Chrome 148.0.7778.216 or later across all affected systems through your standard patch management process, prioritizing user-facing and high-risk endpoints. Within 30 days: Verify and audit 100% deployment completion via asset inventory and automated patch compliance reporting.

Google Chrome CVE-2026-9880

EUVD-2026-33175 HIGH

Improper Input Validation (CWE-20)

2026-05-28 Chrome

GHSA-7h3x-g348-3qm8

Information Disclosure Google

8.3

CVSS 3.1 · Vendor: Chrome

Severity by source

Vendor (Chrome) PRIMARY

8.3 HIGH

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

SUSE

HIGH

qualitative

Red Hat

8.2 CRITICAL

qualitative

Primary rating from Vendor (Chrome).

CVSS VectorVendor: Chrome

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

May 29, 2026 - 16:31 vuln.today

CVSS changed

May 29, 2026 - 16:27 NVD

8.3 (HIGH)

CVE Published

May 28, 2026 - 22:25 nvd

UNKNOWN (no severity yet)

CVE Published

May 28, 2026 - 22:25 nvd

HIGH 8.3

DescriptionCVE.org

Insufficient validation of untrusted input in WebGL in Google Chrome prior to 148.0.7778.216 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)

AnalysisAI

Sandbox escape in Google Chrome versions prior to 148.0.7778.216 enables a remote attacker who has already compromised the renderer process to break out of the browser sandbox via a crafted HTML page that abuses insufficient input validation in WebGL. Chromium rates the underlying severity as Critical, and while no public exploit is identified at time of analysis, the EPSS score is low (0.04%, 14th percentile) and the CVSS:3.1 base is 8.3 due to high attack complexity and required user interaction. The flaw is part of a multi-stage exploit chain rather than a one-shot RCE.

Technical ContextAI

The vulnerability resides in Chrome's WebGL implementation, the JavaScript API that exposes GPU-accelerated 2D/3D rendering primitives to web content through the renderer process. CWE-20 (Improper Input Validation) indicates that WebGL accepts attacker-controlled values from JavaScript without sufficient checks before passing them to lower-level GPU/IPC routines reachable from the sandboxed renderer. Because WebGL bridges untrusted JS into privileged graphics paths that cross the renderer/GPU process boundary, validation gaps here are a classic vector for sandbox escapes. The affected CPE is cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* with the EUVD constraint fixing Chrome at 148.0.7778.216.

RemediationAI

Vendor-released patch: Google Chrome 148.0.7778.216 - upgrade all desktop installations to this version or later via Chrome's auto-update mechanism, and force-restart the browser to apply the fix (auto-update stages the binary but does not activate until restart). Enterprise administrators should verify rollout via the Chrome Releases advisory at https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_0877304591.html and consult the Chromium bug at https://issues.chromium.org/issues/503615025 for tracking. Downstream Chromium-based browsers should be updated as their vendors publish corresponding releases. As a temporary compensating control where patching is delayed, WebGL can be disabled by setting the enterprise policy 'HardwareAccelerationModeEnabled' to false or via chrome://flags/#disable-webgl - trade-off is broken rendering on WebGL-dependent sites (mapping tools, 3D viewers, some games, and increasingly common WebGPU-fallback content). Restricting browsing to trusted sites via URL allowlists also reduces exposure since exploitation requires loading a crafted page.