What is the CVSS score of EUVD-2026-33120?

EUVD-2026-33120 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 EUVD-2026-33120?

Google Chrome users across your organization are exposed to a high-severity vulnerability (CVE-2026-9978) that could allow attackers to compromise employee browsers and steal sensitive data when…. A patch is available.

How to fix or mitigate EUVD-2026-33120?

Within 24 hours: Assess your Chrome deployment footprint (on-premises systems, cloud-managed endpoints, BYOD) and verify your current auto-update configuration. Within 7 days: Ensure all Chrome installations are updated to version 148.0.7778.216 or later; use your MDM/patch management system to force deployment if auto-update is disabled. Within 30 days: Audit and remediate any non-compliant installations; consider policy controls to block versions prior to 148.0.7778.216.

Google Chrome EUVD-2026-33120

| CVE-2026-9978 HIGH

Use After Free (CWE-416)

2026-05-28 Chrome

GHSA-vv5x-2m86-4jv8

Use After Free RCE Memory Corruption Google Denial Of Service 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

8.8 HIGH

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:32 vuln.today

CVSS changed

May 29, 2026 - 12:22 NVD

8.8 (HIGH)

CVE Published

May 28, 2026 - 22:25 nvd

HIGH 8.8

CVE Published

May 28, 2026 - 22:25 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

Use after free in Glic in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

AnalysisAI

Sandboxed remote code execution in Google Chrome desktop versions prior to 148.0.7778.216 stems from a use-after-free defect in the Glic component, allowing a remote attacker to corrupt memory and execute arbitrary code within the renderer sandbox when a victim visits a crafted HTML page. Google has rated the Chromium severity as High and shipped a Stable channel update; no public exploit identified at time of analysis, and the issue is not currently listed in CISA KEV. The CVSS 8.8 score reflects network reachability and user interaction (loading a page), with full impact to confidentiality, integrity, and availability inside the sandboxed process.

Technical ContextAI

The flaw is a CWE-416 Use-After-Free in 'Glic', a Chrome component that processes content delivered via standard web navigation in the Blink/Chromium renderer. Use-after-free bugs occur when memory is freed but a dangling pointer is subsequently dereferenced, letting an attacker reuse the freed allocation with controlled data to hijack virtual function calls or other indirect dispatch and ultimately gain code execution in the affected process. The affected product per the supplied CPE is cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* (the desktop Stable channel), and per Chrome's standard architecture exploitation lands inside the renderer sandbox, meaning a second sandbox-escape bug would be required to reach the host OS with full privileges.

RemediationAI

Vendor-released patch: Chrome Stable 148.0.7778.216 - upgrade all desktop Chrome installations to this version or later by allowing Chrome's auto-update to complete and restarting the browser, or by pushing the update via enterprise management (Google Update / ADMX policy / MDM) per the Chrome Releases advisory at https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_0877304591.html. Downstream Chromium-based browsers should be updated as soon as their vendors ship the corresponding merge. Where immediate patching is not possible, compensating controls include restricting browsing to a known-good allowlist via proxy/SWG (trade-off: breaks general web usage), enforcing 'Site Isolation' and 'Strict Site Isolation' enterprise policies to limit cross-origin impact of a renderer compromise (already on by default; trade-off: higher memory use), and routing browsing through a remote browser isolation (RBI) solution for high-risk users (trade-off: latency and licensing cost); disabling JavaScript globally would substantially reduce risk but breaks most modern sites and is generally impractical.