This is less a front-door break-in and more a forged contractor badge that only works after someone lets the contractor inside
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.
4 steps from start to impact.
Stage a malicious extension
- Attacker can create or host a Chrome extension
- Victim uses a vulnerable Chrome desktop build
- Many enterprises block sideloading or require extension allowlists
- Web Store review, domain controls, and user prompts add drag
Convince the user to install it
- User can install extensions or request them with weak approval
- Security awareness and browser policy do not stop the install
- Managed Chrome often restricts installs to approved IDs
- Users must click through an explicit extension install flow
Trigger the DevTools validation flaw
- Extension is installed and enabled
- Chrome version is below the fixed build
- Bug details remain restricted in Chromium issue tracking
- The exploit path appears narrower than a generic renderer bug or memory-corruption primitive
Abuse the bypass in the user context
- Victim continues using the compromised browser profile
- Attacker has a useful post-bypass objective
- No evidence of in-the-wild exploitation
- No public weaponized PoC found in primary-source review
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.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.149.0.7827.53. For LOW, use the normal patching process rather than an emergency campaign.- A WAF or network IPS does not meaningfully help; the exploit path depends on browser extension installation, not a server-side request pattern.
- Perimeter exposure management is mostly irrelevant; there is no internet-facing service to find or shield.
- MFA does nothing for the vulnerable code path itself; it may help downstream account abuse, but it does not stop the extension prerequisite or the DevTools bug.
The supporting signals.
| In-the-wild status | No public exploitation evidence found in primary-source review; not listed in CISA KEV. |
|---|---|
| Public PoC | No public PoC located from authoritative sources. Chromium issue 503197481 is referenced but not publicly readable without sign-in, which usually means technical detail is still restricted. |
| EPSS | 0.00019 — effectively background noise. Even without the exact percentile, this is a very low predicted 30-day exploitation probability. |
| KEV status | Absent from KEV; no CISA due date pressure. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N — the formal model captures user interaction, but it still misses the real-world malicious extension install prerequisite that materially narrows exposure. |
| Affected versions | Google Chrome desktop before 149.0.7827.53; release notes specify 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. |
| Fixed versions | Upgrade to 149.0.7827.53 or later on Linux and 149.0.7827.53/.54 or later on Windows/macOS. Distro/browser-package backports were not identified in the reviewed primary sources. |
| Exposure / scanning reality | This is a client application issue, not an internet-facing service flaw. Shodan/Censys/FOFA-style exposure counting is largely meaningless here; your real exposure metric is endpoint version inventory plus extension policy posture. |
| Disclosure timeline | Chrome stable release published 2026-06-02; CVE published in NVD on 2026-06-04; CISA-ADP CVSS/CWE enrichment landed 2026-06-05. |
| Reporter | lebr0nli of National Yang Ming Chiao Tung University, Dept. of CS, Security and Systems Lab, reported on 2026-04-16 per Chrome release notes. |
Sources.
- NVD CVE-2026-11189
- Chrome Releases - Stable Channel Update for Desktop (2026-06-02)
- Chromium issue 503197481
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS data and stats
- Chromium severity guidelines
- Chrome Enterprise - Extension Install Allowlist policy
- Chrome Enterprise - Block External Extensions policy
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.
Crowdsourced verification payload.
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
}