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

EUVD-2026-34366 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.1%.

Which versions of Google Chrome are affected by EUVD-2026-34366?

Google Chrome versions prior to 149.0.7827.53 contain a sandbox escape vulnerability (CVE-2026-10917, CVSS 8.3) that allows attackers to break out of Chrome's process isolation and execute arbitrary…. A patch is available.

How to fix or mitigate EUVD-2026-34366?

Within 24 hours: Inventory all Chrome installations and document current versions. Within 7 days: Mandatory deployment of Chrome 149.0.7827.53 or later; use automated update mechanisms where possible to force immediate patching. Within 30 days: Audit deployment logs to confirm 100% compliance and monitor for any remaining outdated versions.

Google Chrome EUVD-2026-34366

| CVE-2026-10917 HIGH

Improper Input Validation (CWE-20)

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

GHSA-cpgg-3mvc-rp6p

Information Disclosure Google Red Hat Suse Chrome

8.3

CVSS 3.1 · NVD

Severity by source

NVD 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 HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 05, 2026 - 02:35 vuln.today

CVSS changed

Jun 05, 2026 - 02:22 NVD

8.3 (HIGH)

CVE Published

Jun 04, 2026 - 23:16 nvd

HIGH 8.3

CVE Published

Jun 04, 2026 - 23:16 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

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

AnalysisAI

Sandbox escape in Google Chrome versions prior to 149.0.7827.53 allows a remote attacker who has already compromised the renderer process to break out of the browser sandbox via a crafted HTML page exploiting insufficient input validation in the Media component. Google rates the Chromium security severity as High, and no public exploit has been identified at time of analysis. Successful exploitation requires chaining with a separate renderer compromise plus user interaction, raising attack complexity but yielding full host-level impact if achieved.

Technical ContextAI

The flaw resides in Chrome's Media subsystem, which handles audio/video decoding, MediaStream, and related HTML5 media APIs exposed to web content. CWE-20 (Improper Input Validation) indicates the Media component fails to adequately sanitize or bounds-check untrusted data crossing the renderer-to-broker/GPU process boundary, which the Chromium sandbox architecture relies on to confine compromised renderers. By feeding malformed media data through this IPC path, an attacker already executing code in the lower-privileged renderer can influence a higher-privileged Chrome process and break the sandbox boundary that normally isolates web content from the host OS.

RemediationAI

Vendor-released patch: Google Chrome 149.0.7827.53. Update Chrome to 149.0.7827.53 or later on all desktop platforms via the stable-channel update documented at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html, and verify by navigating to chrome://settings/help to force the relaunch. Enterprises managing Chrome via policy should push the update through Google Update / Chrome Browser Cloud Management and audit fleet versions. For Chromium-derived browsers (Edge, Brave, Opera, Electron-based apps), apply vendor updates that incorporate the Chromium 149.0.7827.53 merge as soon as they ship. As a compensating control until patching, enterprises can enforce Site Isolation and SitePerProcess (already default but verify via policy), restrict media autoplay and MediaStream permissions via SitePermissionsAllowedForUrls / AutoplayAllowed=Disabled, and consider temporarily blocking untrusted external browsing via proxy/URL allowlists - accepting the usability cost of broken video/audio on legitimate sites; these do not fully neutralize the bug but reduce drive-by exposure.