Insufficient validation of untrusted input in DevTools in Google Chrome prior to 149

CVE-2026-11189 is a Chrome DevTools input-validation flaw that can let a crafted Chrome extension bypass navigation restrictions. The authoritative public record does not describe a simple webpage exploit; it says the attacker must first convince a user to install a malicious extension. Affected desktop builds are Google Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS.

Google's Medium 6.5 rating is technically defensible in CVSS terms, but it overstates enterprise urgency. The decisive friction is the prerequisite chain: this is client-side, user-assisted, and gated behind extension installation. In a managed fleet, extension allowlisting, blocklisting, and normal browser auto-update behavior push this down into backlog-grade risk unless you already permit broad user-installed extensions.

Why this verdict

• Requires malicious extension install: this is not a drive-by browser bug; the attacker must get code accepted as an extension first.
• Exposure population is narrow: only users on vulnerable Chrome desktop builds *and* with permissive extension policy are materially exposed.
• Modern controls should break step 2: Chrome Enterprise allowlists, blocklists, external-extension blocking, and EDR/browser telemetry all create strong real-world friction before exploitation ever starts.

Why not higher?

A higher rating would fit a bug reachable by opening a page, previewing content, or receiving network traffic. That is not what the authoritative description says. The required extension-install step compounds with a lack of KEV, lack of public exploit evidence, and a user-context blast radius.

Why not lower?

This is still a real security boundary issue in a massively deployed browser, and unmanaged or lightly managed fleets do allow users to install extensions. If your environment is permissive on extensions, the reachable population goes up fast enough that this should not be waved away as IGNORE.

1. Lock down extension installs — Use ExtensionInstallAllowlist or ExtensionSettings so users cannot freely add arbitrary extensions. For a LOW verdict there is no mitigation SLA, so treat this as control hardening in normal operations; if you are currently permissive, move it into the next routine policy change window.
2. Block external extensions — Enable BlockExternalExtensions where business use permits it to cut off sideload paths that make this CVE reachable. For LOW, there is no emergency deadline, but this is the cleanest preventive control for unmanaged extension channels.
3. Inventory Chrome versions — Pull browser version inventory from endpoint management so you know which hosts remain below 149.0.7827.53. For LOW, use the normal patching process rather than an emergency campaign.
4. Review extension exceptions — Audit force-installed and user-approved extension IDs, especially broad-permission extensions and any non-store distribution. This should land in your routine browser governance cycle because the real risk driver here is extension trust, not raw browser version alone.

Run this on the target Windows endpoint or via your remote management tool. Invoke with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11189.ps1; no admin rights are usually needed to read the standard Chrome install paths, but elevated rights may help if your EDR or filesystem ACLs are strict.

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

# Exit codes:

#   0 = PATCHED

#   1 = VULNERABLE

#   2 = UNKNOWN


$ErrorActionPreference = 'Stop'
$fixedVersion = [version]'149.0.7827.53'
$paths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
    "$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)

function Get-ChromeVersionFromPath {
    param([string]$Path)
    if (-not (Test-Path -LiteralPath $Path)) { return $null }
    try {
        $item = Get-Item -LiteralPath $Path
        $ver = $item.VersionInfo.ProductVersion
        if (-not $ver) { $ver = $item.VersionInfo.FileVersion }
        if ($ver) { return [version]$ver }
    } catch {
        return $null
    }
    return $null
}

$found = @()
foreach ($p in $paths) {
    $v = Get-ChromeVersionFromPath -Path $p
    if ($v) {
        $found += [pscustomobject]@{ Path = $p; Version = $v }
    }
}

if ($found.Count -eq 0) {
    Write-Output 'UNKNOWN - Chrome executable not found in standard paths'
    exit 2
}

$minFound = ($found | Sort-Object Version | Select-Object -First 1)
if ($minFound.Version -lt $fixedVersion) {
    Write-Output ("VULNERABLE - Found Chrome {0} at {1}; fixed version is {2}" -f $minFound.Version, $minFound.Path, $fixedVersion)
    exit 1
} else {
    Write-Output ("PATCHED - Lowest detected Chrome version is {0}; fixed baseline is {1}" -f $minFound.Version, $fixedVersion)
    exit 0
}

Sources

1. NVD CVE-2026-11189
2. Chrome Releases - Stable Channel Update for Desktop (2026-06-02)
3. Chromium issue 503197481
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS data and stats
6. Chromium severity guidelines
7. Chrome Enterprise - Extension Install Allowlist policy
8. Chrome Enterprise - Block External Extensions policy