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

CVE-2026-10969 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/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-10969?

Google Chrome versions prior to 149.0.7827.53 contain a privilege escalation vulnerability in the Extensions component that could allow compromised renderer processes to escape sandbox restrictions.. A patch is available.

How to fix or mitigate CVE-2026-10969?

24 hours: Audit deployed Chrome versions across endpoints and document current inventory. 7 days: Deploy Google Chrome 149.0.7827.53 or later to all organizational devices through your standard update mechanism. 30 days: Verify patch deployment across 100% of Chrome instances and validate that auto-update policies are functioning.

Google Chrome CVE-2026-10969

EUVD-2026-34418 HIGH

Improper Input Validation (CWE-20)

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

GHSA-9crv-2mc9-w5vj

Google Privilege Escalation Red Hat Suse Chrome

7.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.5 HIGH

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

SUSE

HIGH

qualitative

Red Hat

9.0 HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 05, 2026 - 02:56 vuln.today

CVSS changed

Jun 05, 2026 - 02:22 NVD

7.5 (HIGH)

CVE Published

Jun 04, 2026 - 23:17 nvd

UNKNOWN (no severity yet)

CVE Published

Jun 04, 2026 - 23:17 nvd

HIGH 7.5

DescriptionCVE.org

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

AnalysisAI

Privilege escalation in Google Chrome's Extensions component prior to version 149.0.7827.53 allows a remote attacker who has already compromised the renderer process to escape sandbox restrictions via a crafted HTML page. Chromium rates the issue High severity; no public exploit has been identified at time of analysis and SSVC reports exploitation status as none, though the technical impact is total if chained successfully.

Technical ContextAI

The flaw resides in Chrome's Extensions subsystem, which mediates privileged browser APIs available to installed extensions and brokers messages between the lower-privileged renderer process and the higher-privileged browser process. CWE-20 (Improper Input Validation) indicates the Extensions code fails to adequately validate data received from an untrusted source - specifically a renderer that an attacker has already taken over - allowing that input to be processed in a privileged context. Because Chromium's security model assumes the renderer is hostile and relies on IPC validation to maintain the sandbox boundary, a validation gap in Extensions effectively becomes a sandbox-escape primitive that elevates a renderer compromise into broader browser-process privileges.

RemediationAI

Vendor-released patch: update Google Chrome to 149.0.7827.53 or later via the Stable channel update documented at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html; on managed fleets, force a restart so the new binary is loaded rather than relying on background updater rollout. Users of Chromium-based browsers (Edge, Brave, Opera, Vivaldi) should install the corresponding upstream-pickup release from their vendor, and Electron-based applications should be rebuilt against a patched Chromium. As compensating controls while patching is pending, restrict installation of untrusted browser extensions via enterprise policy (ExtensionInstallAllowlist/Blocklist) to reduce the attack surface in the Extensions code path, and consider enabling site isolation strict mode if not already on; broad URL filtering will not stop this bug since the crafted HTML is delivered after a renderer compromise, so blunt URL blocks have limited value and high false-positive cost.