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

CVE-2026-10990 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 CVE-2026-10990?

Google Chrome versions prior to 149.0.7827.53 contain a critical sandbox bypass vulnerability that could enable attackers with a pre-compromised renderer process to gain system-level access.. A patch is available.

How to fix or mitigate CVE-2026-10990?

Within 24 hours: Inventory Chrome versions across the organization and notify users of the update requirement. Within 7 days: Deploy Chrome 149.0.7827.53 or later across all endpoints via your software distribution mechanism (Microsoft Intune, Jamf, Google Admin Console, or manual update prompts). Within 30 days: Verify completion through endpoint management telemetry with a target of ≥95% compliance.

Google Chrome CVE-2026-10990

EUVD-2026-34439 CRITICAL

Use After Free (CWE-416)

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

GHSA-cc8p-4rrq-88pq

Denial Of Service Use After Free Memory Corruption Google Red Hat Suse Chrome

Critical

Disputed · 9.6 NVD

Severity by source

Sources disagree (Medium–Critical)

NVD PRIMARY

9.6 CRITICAL

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

Red Hat

8.2 MEDIUM

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 06, 2026 - 04:00 vuln.today

CVSS changed

Jun 06, 2026 - 01:52 NVD

9.6 (CRITICAL)

CVE Published

Jun 04, 2026 - 23:17 nvd

UNKNOWN (no severity yet)

CVE Published

Jun 04, 2026 - 23:17 nvd

CRITICAL 9.6

DescriptionCVE.org

Use after free in Glic 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: Medium)

AnalysisAI

Sandbox escape in Google Chrome's Glic component 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. The flaw is a use-after-free memory corruption issue (CWE-416) requiring user interaction and a chained renderer compromise; no public exploit identified at time of analysis and EPSS exploitation probability is very low at 0.03%.

Technical ContextAI

The vulnerability resides in Glic, a component within Chromium's multi-process architecture, and is classified as CWE-416 (Use After Free) - a memory corruption class where freed heap memory is referenced again, enabling attacker-controlled data to be interpreted as valid object state. Per the CPE (cpe:2.3:a:google:chrome:*), all Chrome desktop builds before 149.0.7827.53 are affected. Because the CVSS scope is Changed (S:C) and impacts confidentiality, integrity, and availability at High, successful exploitation lets attacker code in the constrained renderer process cross the sandbox trust boundary into the more privileged browser process, which has broader OS access.

RemediationAI

Apply the vendor-released patch by upgrading Google Chrome to 149.0.7827.53 or later on all desktop platforms; Chrome's default auto-update will deliver this via the Stable channel update referenced at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html, but managed enterprise fleets should verify rollout through their update policy (Group Policy/MDM) and force a restart since pending updates do not take effect until the browser is relaunched. Downstream Chromium-based browsers should be updated once their vendors ship the corresponding fix. As compensating controls while patching is in flight, restrict user browsing to trusted sites via enterprise URL allowlists, enable site isolation (on by default but verify chrome://flags has not been altered), and consider deploying browser-based attack-surface reduction such as disabling unneeded experimental features - these reduce the odds of the prerequisite renderer compromise but at the cost of breaking some web apps and developer workflows.