Use after free in WebML in Google Chrome on Windows prior to 149

CVE-2026-11147 is a use-after-free in Chrome's WebML component on Windows. A malicious site can trigger memory corruption through crafted HTML and, if exploitation succeeds, execute code inside a sandboxed Chrome process on Windows versions prior to 149.0.7827.53. The available record does not describe host-level code execution, privilege escalation, or sandbox escape as part of this CVE.

The 8.8/HIGH CVSS baseline overstates real enterprise impact because it scores the memory-corruption primitive as if confidentiality, integrity, and availability of the endpoint are directly lost. In practice, the decisive friction is that the attacker lands inside Chrome's sandbox, which Chromium's own severity guidance treats as materially less severe than code execution on the underlying platform. That keeps this in MEDIUM unless you have evidence of exploitation chains, sandbox escapes, or a business case where exposed browser sessions themselves are the crown jewels.

Why this verdict

• Sandboxed outcome cuts the score down hard: the published description says arbitrary code runs *inside a sandbox*, not on the endpoint OS.
• User-browsing requirement adds friction: this is a drive-by/browser-delivery bug, not unauthenticated reachability to an exposed enterprise service.
• No exploitation signal: not in KEV, no public PoC found, and the provided EPSS is extremely low at 0.00071.
• Windows-only scope narrows population: Mac, Linux, ChromeOS, and server-side browserless estates are out of scope for this CVE as published.
• Browser ubiquity keeps it from dropping lower: Chrome is everywhere, and memory corruption in a renderer is still a valid first-stage foothold for exploit chains.

Why not higher?

A higher rating would need evidence that this CVE routinely becomes host compromise, such as a sandbox escape, active exploitation, or a public exploit chain. None of that is present in the verified sources. The record itself confines execution to the sandbox, which is exactly the sort of mitigating factor Chromium says can reduce severity.

Why not lower?

This is still remote, low-complexity, no-auth memory corruption delivered by normal browsing. Even sandboxed browser code execution can expose active session data, enable follow-on exploitation, or act as a chainable first stage, so writing it off as LOW would understate the risk on a large Windows fleet.

1. Inventory vulnerable Chrome builds — Use EDR, MDM, SCCM/Intune, or Chrome enterprise reporting to identify Windows hosts below 149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but you still need exposure numbers before you can manage rollout rationally.
2. Force automatic browser updates — Make sure Chrome auto-update is enabled and not blocked by stale enterprise policy, broken update services, or pinned version rings. This is the cleanest control because it removes the vulnerable code path rather than trying to detect exploit behavior after the fact; for this MEDIUM case, use it as part of normal patching and complete remediation within 365 days.
3. Tighten web delivery controls — Reduce drive-by exposure with URL filtering, Safe Browsing enforcement, ad/tracker blocking where policy allows, and isolation for high-risk browsing populations. These controls are only partial, but they cut the chance a user ever renders the malicious page while you work through the 365-day remediation window.
4. Watch Chrome child-process abuse — Tune EDR analytics for suspicious chrome.exe behavior such as unexpected child processes, script hosts, LOLBins, credential-store access, or bursty renderer crashes. This does not prevent the memory bug, but it helps catch the second-stage behavior that would matter most if an attacker chained beyond the sandbox during the 365-day remediation window.
5. Isolate risky user cohorts — Apply stricter browser isolation or hardened browsing profiles to admins, developers, finance, help desk, and users who regularly hit untrusted web content. The value here is blast-radius reduction: if this becomes part of a chain, you want the highest-value sessions least exposed while normal remediation completes within 365 days.

Run this on the target Windows endpoint or through your software-distribution/EDR remote shell. Invoke it with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11147.ps1; it needs only normal user rights to read file versions, but local admin helps if you want complete coverage of all install paths.

# check-chrome-cve-2026-11147.ps1

# Purpose: Determine whether Google Chrome on Windows is vulnerable to CVE-2026-11147

# Logic: Vulnerable if Chrome version is installed and is lower than 149.0.7827.53

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$ErrorActionPreference = 'SilentlyContinue'

function Get-ChromePaths {
    $paths = @(
        "$Env:ProgramFiles\Google\Chrome\Application\chrome.exe",
        "$Env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
        "$Env:LocalAppData\Google\Chrome\Application\chrome.exe"
    )

    $regPaths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
    )

    foreach ($reg in $regPaths) {
        $p = (Get-ItemProperty -Path $reg).'(default)'
        if ($p) { $paths += $p }
    }

    return $paths | Where-Object { $_ -and (Test-Path $_) } | Select-Object -Unique
}

function Get-VersionObject {
    param([string]$VersionString)
    try {
        return [version]$VersionString
    } catch {
        return $null
    }
}

$fixedVersion = Get-VersionObject '149.0.7827.53'
$chromePaths = Get-ChromePaths

if (-not $chromePaths -or $chromePaths.Count -eq 0) {
    Write-Output 'UNKNOWN: Google Chrome not found in common paths or registry.'
    exit 2
}

$foundAny = $false
$foundVulnerable = $false
$details = @()

foreach ($path in $chromePaths) {
    $file = Get-Item $path
    if (-not $file) { continue }

    $verString = $file.VersionInfo.ProductVersion
    if (-not $verString) { $verString = $file.VersionInfo.FileVersion }

    if (-not $verString) {
        $details += "UNKNOWN version at $path"
        continue
    }

    $ver = Get-VersionObject $verString
    if (-not $ver) {
        $details += "UNKNOWN parse failure at $path ($verString)"
        continue
    }

    $foundAny = $true

    if ($ver -lt $fixedVersion) {
        $foundVulnerable = $true
        $details += "VULNERABLE at $path ($ver)"
    } else {
        $details += "PATCHED at $path ($ver)"
    }
}

if (-not $foundAny) {
    Write-Output 'UNKNOWN: Chrome found, but version could not be determined.'
    $details | ForEach-Object { Write-Output $_ }
    exit 2
}

if ($foundVulnerable) {
    Write-Output 'VULNERABLE'
    $details | ForEach-Object { Write-Output $_ }
    exit 1
}

Write-Output 'PATCHED'
$details | ForEach-Object { Write-Output $_ }
exit 0

Sources

1. NVD CVE-2026-11147
2. Google Chrome stable channel update for Desktop - June 2, 2026
3. Google Chrome early stable update for Desktop - May 29, 2026
4. Chromium severity guidelines
5. Chrome sandbox diagnostics for Windows
6. Chromium memory safety overview
7. FIRST EPSS data and statistics
8. CISA Known Exploited Vulnerabilities catalog