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

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

Google Chrome versions prior to 149.0.7827.103 contain a critical heap corruption vulnerability in the Ozone display server that allows remote attackers to compromise systems when users visit…. A patch is available.

How to fix or mitigate CVE-2026-11629?

Within 24 hours: Identify all Google Chrome installations and their versions across all endpoints and identify those prior to 149.0.7827.103. Within 7 days: Deploy Google Chrome version 149.0.7827.103 or later to all affected systems; enable automatic updates where feasible to prevent recurrence. Within 30 days: Audit patch deployment success and monitor endpoints for indicators of compromise (unusual process execution, network connections to known malicious IPs).

Google Chrome CVE-2026-11629

EUVD-2026-35229 HIGH

Use After Free (CWE-416)

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

GHSA-c729-j7cm-x9p7

Denial Of Service Use After Free Memory Corruption Google

8.8

CVSS 3.1 · Vendor: google

Severity by source

Vendor (google) PRIMARY

8.8 HIGH

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

SUSE

CRITICAL

qualitative

Red Hat

8.8 HIGH

qualitative

Primary rating from Vendor (google).

CVSS VectorVendor: google

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

Jun 09, 2026 - 11:22 vuln.today

CVSS changed

Jun 09, 2026 - 11:22 NVD

8.8 (HIGH)

CVE Published

Jun 09, 2026 - 00:16 nvd

UNKNOWN (no severity yet)

CVE Published

Jun 09, 2026 - 00:16 nvd

HIGH 8.8

DescriptionCVE.org

Use after free in Ozone in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Critical)

AnalysisAI

Heap corruption in Google Chrome's Ozone display server component prior to version 149.0.7827.103 allows remote attackers to exploit a use-after-free condition through a malicious web page, with Chromium rating this as Critical severity. Successful exploitation requires the victim to visit attacker-controlled HTML content, but yields high impact on confidentiality, integrity, and availability in the renderer process. No public exploit identified at time of analysis, and the issue is not currently listed in CISA KEV.

Technical ContextAI

Ozone is Chromium's platform abstraction layer that handles window-system integration, graphics buffer management, and input event routing across Linux, ChromeOS, and other platforms - it sits between Chrome's compositor and the underlying display server (X11, Wayland, DRM). CWE-416 (Use After Free) indicates the renderer or GPU process retains and dereferences a pointer to a heap object after it has been freed, typically when object lifetime is not correctly tracked across asynchronous graphics or input callbacks. Attacker-controlled HTML/JavaScript can shape the heap and trigger the dangling reference, allowing reuse of the freed allocation with attacker data and subsequent control-flow hijack within the sandboxed renderer.

RemediationAI

Vendor-released patch: update Google Chrome to 149.0.7827.103 or later on all desktop platforms, as published in the Chrome Releases stable-channel advisory (https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0153744567.html); the Chromium tracker entry is https://issues.chromium.org/issues/516674532. Force the update by restarting Chrome on managed endpoints and verify via chrome://settings/help, and apply equivalent updates to downstream Chromium browsers (Edge, Brave, Opera, Electron apps) as those vendors ship respins. As a temporary compensating control until patching completes, enable Enhanced Safe Browsing and consider enforcing Site Isolation via enterprise policy and blocking unknown-origin sites at the proxy - disabling JavaScript via policy would mitigate but breaks the modern web and is generally not viable.