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

EUVD-2026-34711 has a contested CVSS base score of 9.6 from a third party (e.g. CISA-ADP), while the vendor rates it Critical. vuln.today uses the vendor rating as authoritative.

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

Google Chrome DevTools prior to version 149.0.7827.53 contains a critical information disclosure vulnerability (CVSS 9.6) that could allow attackers to extract sensitive data from process memory…. A patch is available.

How to fix or mitigate EUVD-2026-34711?

24 hours: Identify all systems running Chrome versions prior to 149.0.7827.53 across your organization. 7 days: Deploy Chrome version 149.0.7827.53 or later to all managed endpoints using your standard patch management process. 30 days: Verify 100% compliance and document remediation completion.

Google Chrome EUVD-2026-34711

| CVE-2026-11250 CRITICAL

Use After Free (CWE-416)

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

GHSA-62v9-gfp5-v299

Information Disclosure Use After Free Memory Corruption Google Red Hat Suse Chrome

Critical

Disputed · 9.6 NVD

Severity by source

Sources disagree (Low–Critical)

NVD PRIMARY

9.6 CRITICAL

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

SUSE

CRITICAL

qualitative

Red Hat

3.5 LOW

qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 05, 2026 - 13:25 vuln.today

CVSS changed

Jun 05, 2026 - 13:22 NVD

9.6 (CRITICAL)

CVE Published

Jun 05, 2026 - 00:17 nvd

UNKNOWN (no severity yet)

CVE Published

Jun 05, 2026 - 00:17 nvd

CRITICAL 9.6

DescriptionCVE.org

Inappropriate implementation in DevTools in Google Chrome prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low)

AnalysisAI

Information disclosure in Google Chrome DevTools prior to version 149.0.7827.53 allows a remote attacker who has already compromised the renderer process to read potentially sensitive data from process memory by serving a crafted HTML page. The flaw stems from a use-after-free condition (CWE-416) in DevTools, and while Google rates the underlying Chromium severity as Low, the NVD CVSS of 9.6 reflects the cross-origin scope change possible when chained with a prior renderer compromise. No public exploit identified at time of analysis.

Technical ContextAI

The vulnerability resides in Chrome's DevTools subsystem, the in-browser debugging and inspection tooling exposed to web content through internal IPC channels. CWE-416 (Use After Free) indicates the code path frees a memory object but later dereferences a dangling pointer, allowing attacker-controlled or stale memory contents to be read or repurposed. Because DevTools operates with elevated privileges relative to ordinary renderer content, a UAF reachable from a compromised renderer can leak data across Chrome's sandbox or process boundaries, which is reflected in the CVSS Scope:Changed designation. The affected CPE per EUVD is Chrome builds below 149.0.7827.53 across the Stable desktop channel.

RemediationAI

Upgrade Google Chrome to the Stable channel build 149.0.7827.53 or later, as released in the June 2026 Stable Channel Update for Desktop (https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html); Chrome's auto-update mechanism will deliver this on browser restart, so enterprises should enforce a restart policy rather than rely on user action. Confirm the deployed build via chrome://settings/help across managed fleets and update embedded Chromium-based applications (Electron, CEF, browser shells) once their upstream rolls in the same patch. No specific workaround is published; as a compensating control until the patch is deployed, disabling the renderer-exposed DevTools surface via the DeveloperToolsAvailability enterprise policy set to DeveloperToolsDisallowed reduces the attack surface but at the cost of breaking developer and support workflows that rely on DevTools.