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

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

Google Chrome on Windows versions prior to 149.0.7827.53 contains a high-severity remote code execution vulnerability that allows attackers to execute arbitrary code within the browser sandbox when…. A patch is available.

How to fix or mitigate CVE-2026-11147?

Within 24 hours: Identify all Windows systems running Chrome and begin testing deployment of Chrome 149.0.7827.53 in a controlled environment. Within 7 days: Deploy Chrome 149.0.7827.53 or later to all systems with critical business functions and high-risk user populations. Within 30 days: Complete organization-wide deployment and verify 100% compliance through endpoint management tools.

Google Chrome CVE-2026-11147

EUVD-2026-34608 HIGH

Use After Free (CWE-416)

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

GHSA-h8pj-vv8c-5x5x

RCE Denial Of Service Google Use After Free Memory Corruption Microsoft

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

HIGH

qualitative

Red Hat

8.8 MEDIUM

qualitative

Primary rating from Vendor (google).

CVSS VectorVendor: google

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 05, 2026 - 03:10 vuln.today

CVSS changed

Jun 05, 2026 - 02:22 NVD

8.8 (HIGH)

CVE Published

Jun 04, 2026 - 23:17 nvd

UNKNOWN (no severity yet)

CVE Published

Jun 04, 2026 - 23:17 nvd

HIGH 8.8

DescriptionCVE.org

Use after free in WebML in Google Chrome on Windows prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium)

AnalysisAI

Remote code execution in Google Chrome on Windows prior to 149.0.7827.53 allows attackers to run arbitrary code within the browser sandbox by enticing a user to visit a crafted HTML page that triggers a use-after-free in the WebML component. Although Chromium rates the severity as Medium, the CVSS 3.1 base score is 8.8 (High), reflecting high impact across confidentiality, integrity, and availability with low attack complexity. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

Technical ContextAI

WebML is Chrome's Web Machine Learning subsystem, which exposes neural-network inference primitives to JavaScript and integrates with browser-side ML model execution. The root cause is CWE-416 (Use After Free): code retains and dereferences a pointer to memory that has already been freed, enabling attacker-controlled heap reuse to corrupt object state or hijack control flow. In Chrome's renderer process this typically yields code execution constrained by the sandbox, requiring a second sandbox-escape bug to reach the host OS. The affected build is the Windows Stable channel before 149.0.7827.53, as indicated by the EUVD CPE-equivalent range and the Chrome Releases advisory.

RemediationAI

Vendor-released patch: Google Chrome 149.0.7827.53 for Windows - upgrade immediately via the Stable channel update described at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html, then relaunch the browser to ensure the new build is loaded. For managed fleets, push the update through enterprise channels (Google Update / MSI, Microsoft Intune, or equivalent) and verify version compliance via chrome://version or registry/version inventory. Until patching completes, compensating controls include restricting browsing to trusted sites via enterprise policy (URLBlocklist/URLAllowlist), disabling WebML where exposed as a policy or origin trial (trade-off: breaks sites depending on Web Machine Learning APIs), and enabling Site Isolation and the Windows renderer App Container sandbox if not already on (negligible trade-off for most users). Application-layer controls such as web filtering proxies and disabling JIT via the JavaScriptJitDisabledForSites policy can further reduce renderer attack surface at the cost of slower JavaScript performance.