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

CVE-2026-11009 is a use-after-free in Chrome's USB handling on Windows affecting Google Chrome before 149.0.7827.53. The public description says a remote attacker could *potentially* achieve a sandbox escape; that matters because crossing from a renderer-originated web bug into the browser or host boundary is the difference between a contained tab compromise and a real endpoint event.

What keeps this out of the top bucket is reachability, not impact. There is no vendor CVSS, no KEV listing, no public exploitation evidence, and the vulnerable surface appears tied to the USB/WebUSB path on Windows, which is a much smaller real-world population than 'any user who opens a web page'; in practice this looks more like a niche second-stage/browser-boundary flaw than a fleet-wide internet fire.

Why this verdict

• Downward pressure: USB/WebUSB is a niche surface — this is not the same as a renderer bug that every webpage can hit across every user population. Real exposure concentrates in kiosks, engineering workstations, hardware-admin tools, labs, smart-card flows, and other USB-heavy workflows.
• Downward pressure: browser-boundary flaws are harder to weaponize than they read on paper — a use-after-free inside modern Chrome on Windows still has to survive sandboxing, memory mitigations, and exploit reliability problems. With no public PoC and restricted bug detail, the practical bar is materially higher than the one-line CVE text suggests.
• Downward pressure: no field signal — EPSS 0.00035, no KEV, and no public campaign reporting all argue against emergency treatment.
• Upward pressure: the payoff is real if chained successfully — sandbox escape is a host-impact amplifier, not a cosmetic bug. If an attacker gets this working, the step from tab compromise to endpoint compromise is exactly why it cannot be scored LOW.

Why not higher?

I am not putting this at HIGH because the available public evidence does not show a mass-reachable, one-click browser RCE in the usual sense. The likely reachable population is narrower, the exploit chain is harder, the platform scope is Windows-only, and there is currently no exploitation evidence forcing an emergency override.

Why not lower?

I am not putting this at LOW because sandbox escape in a ubiquitous browser still matters, especially on managed Windows fleets where the browser is the daily attack surface. Even with narrow reachability, the consequence of a working exploit is meaningful endpoint compromise potential, so it deserves patching attention rather than backlog oblivion.

1. Disable WebUSB where the business does not need it — Set Chrome Enterprise policy DefaultWebUsbGuardSetting=2 for general-purpose users and only carve out exceptions for known business apps. This strips away the most plausible reachable surface while you work normal maintenance; because this is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window and apply this first to higher-risk or USB-irrelevant populations.
2. Target the real exposure population — Pull an inventory of Windows endpoints used for kiosks, industrial interfaces, hardware flashing, smart-card/token workflows, labs, and engineering benches, then verify their browser version and WebUSB policy state. That is where this CVE is most likely to matter operationally; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but prioritize those exception groups ahead of the rest of the estate.
3. Hunt for stalled browser updates — Use Intune, SCCM, EDR, or browser management to find chrome.exe versions below 149.0.7827.53 on Windows, especially VDI images, disconnected laptops, and gold images that miss auto-update. The control is simple: close the inventory gap and let managed rollout do the work; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
4. Tighten post-exploitation controls on Chrome-originated activity — Make sure EDR rules watch for suspicious child processes, script interpreters, LOLBins, or injection behavior originating from chrome.exe. This does not fix the memory bug, but it does cut the value of a successful sandbox escape; again, MEDIUM means no mitigation SLA — go straight to the 365-day remediation window rather than treating this as a weekend emergency.

Run this on the target Windows endpoint locally, through your RMM/EDR live response, or via Intune/SCCM. Invoke it with powershell -ExecutionPolicy Bypass -File .\Test-Chrome-CVE-2026-11009.ps1; administrator rights are not required because it only reads file/registry version data and reports VULNERABLE, PATCHED, or UNKNOWN.

# Test-Chrome-CVE-2026-11009.ps1

# Checks Google Chrome on Windows against the fixed version for CVE-2026-11009.

# Output: VULNERABLE / PATCHED / UNKNOWN

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


$ErrorActionPreference = 'SilentlyContinue'
$fixedVersion = [version]'149.0.7827.53'

function Get-ChromeVersion {
    $candidates = @(
        "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
        "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
        "$env:LocalAppData\Google\Chrome\Application\chrome.exe"
    )

    foreach ($path in $candidates) {
        if (Test-Path $path) {
            try {
                $ver = (Get-Item $path).VersionInfo.ProductVersion
                if ($ver) {
                    return [PSCustomObject]@{ Source = $path; Version = $ver }
                }
            } catch {}
        }
    }

    $regPaths = @(
        'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
        'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
        'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
    )

    foreach ($rp in $regPaths) {
        try {
            $item = Get-ItemProperty -Path $rp
            if ($item.version) {
                return [PSCustomObject]@{ Source = $rp; Version = $item.version }
            }
        } catch {}
    }

    return $null
}

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

$chrome = Get-ChromeVersion
if (-not $chrome) {
    Write-Output 'UNKNOWN - Google Chrome not found via common file paths or BLBeacon registry keys.'
    exit 2
}

$parsed = Test-VersionString -VersionString $chrome.Version
if (-not $parsed) {
    Write-Output ("UNKNOWN - Found Chrome version string '{0}' from {1}, but could not parse it." -f $chrome.Version, $chrome.Source)
    exit 2
}

# Optional visibility into WebUSB policy state, useful as compensating-control context.

$webUsbPolicy = $null
try {
    $policyKey = 'HKLM:\SOFTWARE\Policies\Google\Chrome'
    if (Test-Path $policyKey) {
        $policy = Get-ItemProperty -Path $policyKey
        if ($null -ne $policy.DefaultWebUsbGuardSetting) {
            $webUsbPolicy = $policy.DefaultWebUsbGuardSetting
        }
    }
} catch {}

if ($parsed -lt $fixedVersion) {
    if ($null -ne $webUsbPolicy) {
        Write-Output ("VULNERABLE - Chrome {0} detected from {1}. Fixed version is {2}. DefaultWebUsbGuardSetting={3}." -f $parsed, $chrome.Source, $fixedVersion, $webUsbPolicy)
    } else {
        Write-Output ("VULNERABLE - Chrome {0} detected from {1}. Fixed version is {2}." -f $parsed, $chrome.Source, $fixedVersion)
    }
    exit 1
}
else {
    if ($null -ne $webUsbPolicy) {
        Write-Output ("PATCHED - Chrome {0} detected from {1}, which is at or above {2}. DefaultWebUsbGuardSetting={3}." -f $parsed, $chrome.Source, $fixedVersion, $webUsbPolicy)
    } else {
        Write-Output ("PATCHED - Chrome {0} detected from {1}, which is at or above {2}." -f $parsed, $chrome.Source, $fixedVersion)
    }
    exit 0
}

Sources

1. Chrome Releases: Stable Channel Update for Desktop (June 2026)
2. Chrome 149 release notes
3. Chromium Security overview
4. Chromium Site Isolation
5. Chrome Enterprise policy: DefaultWebUsbGuardSetting
6. Chrome Enterprise admin help: set Chrome policies
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS API documentation