Like a fake name badge at the lobby, this bug helps an attacker look trusted without giving them the keys
CVE-2026-11309 is a UI spoofing flaw in Chrome's History component. Google says Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS contain the fix, so anything earlier is affected. The attacker path is simple in theory: host a crafted page, get a user to open it, and abuse weak policy enforcement around History UI behavior to make browser chrome or trust cues look more legitimate than they are.
The vendor-style CVSS 4.3 / MEDIUM overstates enterprise urgency because it scores the *possibility* of integrity impact but ignores the real-world friction: user interaction is mandatory, impact is limited to spoofing, and there is no code execution, sandbox escape, or privilege gain. Google itself classified this specific bug as Low in the June 2, 2026 stable-channel advisory, which matches operational reality much better than the generic CVSS label.
3 steps from start to impact.
Deliver a crafted page
- Target runs Chrome before 149.0.7827.53
- User can be enticed to open attacker-controlled content
- Requires user interaction
- Enterprise web filtering, Safe Browsing, secure email gateways, and user training cut down the reachable population
- No evidence this CVE bypasses browser sandboxing or same-origin boundaries
Spoof browser trust cues
- Victim must render the malicious page successfully
- The spoof must be convincing enough to influence user decisions
- UI spoofing is brittle across screen sizes, languages, themes, and browser state
- Many enterprise users run password managers, SSO prompts, or security awareness overlays that make crude spoofing stand out
- A spoof is only useful if the victim acts on it
Convert deception into action
- User must trust the spoofed UI
- A second malicious objective must be chained after the spoof
- Modern IdP MFA, passwordless auth, browser download warnings, and EDR reduce payoff
- Blast radius is per-user and per-session rather than fleet-wide
- No known in-the-wild exploitation or KEV listing
The supporting signals.
| In-the-wild status | No public evidence of active exploitation located. CISA KEV does not list this CVE. |
|---|---|
| KEV status | Not listed in CISA Known Exploited Vulnerabilities as of 2026-06-05. |
| Proof-of-concept availability | No public PoC found in the sources reviewed. This matters because UI-spoof bugs often need tailoring to be believable. |
| EPSS | 0.00013 from the user-provided intel block, indicating a very low modeled likelihood of near-term exploitation. |
| CVSS interpretation | AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N means remote and unauthenticated, but only with user interaction, and the direct impact is just low integrity. |
| Vendor severity mismatch | The prompt supplied MEDIUM 4.3, but Google's June 2, 2026 advisory labels CVE-2026-11309 as Low. That's the more operationally accurate signal here. |
| Affected versions | Chrome before 149.0.7827.53; Google lists fixed desktop builds as 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac). |
| Fixed versions | Upgrade to 149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. Distro Chromium backports may differ by package version and should be validated against vendor package advisories. |
| Scanning and exposure reality | This is a client-side browser issue, so there is no meaningful Shodan/Censys/FOFA internet census of exposed hosts. Exposure must be measured from endpoint inventory, not external attack-surface scans. |
| Disclosure and reporting | Google's stable-channel post is dated 2026-06-02 and notes the underlying issue was reported by Google on 2026-04-25. |
noisgate verdict.
The decisive factor is that this bug does not compromise the endpoint by itself; it only helps an attacker make a malicious page look more trustworthy after the user opens it. That is materially weaker than the average remotely triggerable Chrome CVE because the attacker still has to win a separate social-engineering step to get any payoff.
Why this verdict
- Downgrade from CVSS MEDIUM: Google itself tagged this exact bug Low in the June 2, 2026 stable release, which is a better fit for a pure UI-spoof issue than a mechanical 4.3 score.
- User interaction is mandatory: the attacker needs the victim to open a crafted page first, which means this is not a drive-by fleet event in the same class as memory-corruption Chrome bugs.
- Impact is indirect, not terminal: the CVE does not give code execution, sandbox escape, credential extraction, or privilege elevation on its own; it only improves the odds of a phishing-style follow-on.
- Reachable population is narrower than 'all Chrome users': enterprises with Safe Browsing, web filtering, password managers, and MFA blunt spoofing attacks significantly.
- No exploitation signal: no KEV entry, no public campaign reporting found, and the supplied EPSS 0.00013 is extremely low.
Why not higher?
If this were a no-click renderer bug, sandbox escape, credential theft primitive, or something already used in campaigns, the score would jump fast. But this one stops at deception and still depends on the victim taking a second unsafe action, which is a major real-world brake.
Why not lower?
It is still a remote, unauthenticated browser flaw in one of the most widely deployed enterprise applications. Even low-grade trust-boundary bugs in browsers can improve phishing success, so this is not something to ignore completely if you already patch Chrome routinely.
What to do — in priority order.
- Force browser auto-update — Make sure managed Chrome channels are actually pulling 149.0.7827.53/.54 or later. For a LOW noisgate rating there is no formal mitigation SLA, but this is still worth cleaning up as normal browser hygiene while you work through the remediation backlog.
- Keep Safe Browsing and URL filtering on — This bug needs a user to land on an attacker-controlled page first, so blocking bad destinations removes the attacker from step one of the chain. Maintain those controls continuously; for LOW, use them as steady-state protection rather than emergency mitigation.
- Harden identity prompts — Enforce phishing-resistant MFA or at least strong MFA for sensitive apps so a spoofed browser UI cannot easily convert into account compromise. Keep this in place permanently; it is the best compensating control when the vulnerability's value is mostly social-engineering amplification.
- Inventory Chrome from endpoints, not the edge — Because this is a client-side browser issue, your exposure picture comes from MDM, EDR, SCCM/Intune, or package management data, not internet scanning. Use endpoint version reporting to close the remediation loop as backlog hygiene.
- A network IDS signature for the CVE itself does not help much because the attack is just a crafted webpage and the exploit value is in what the UI looks like to the user.
- Perimeter exposure management tools like Shodan/Censys do not measure this risk because browser versions on user endpoints are not meaningfully externally enumerable.
- EDR alone will not stop the spoofing stage if no malicious binary or post-exploitation behavior occurs.
Crowdsourced verification payload.
Run this on the target Windows endpoint or through your EDR/management tooling. Invoke with powershell.exe -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11309.ps1; no admin rights are required if Chrome is installed in a standard location. The script checks installed Google Chrome file versions and returns VULNERABLE, PATCHED, or UNKNOWN.
# check-chrome-cve-2026-11309.ps1
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
$ErrorActionPreference = 'Stop'
function Parse-Version($v) {
try { return [version]$v } catch { return $null }
}
function Test-Patched($versionString) {
$v = Parse-Version $versionString
if ($null -eq $v) { return $null }
# Fixed desktop builds per Google:
# Windows/Mac: 149.0.7827.53/.54
# Treat 149.0.7827.53 and later as patched on Windows.
$fixed = [version]'149.0.7827.53'
if ($v -ge $fixed) { return $true } else { return $false }
}
$paths = @(
"$Env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$Env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$Env:LocalAppData\Google\Chrome\Application\chrome.exe"
)
$found = @()
foreach ($p in $paths) {
if (Test-Path $p) {
try {
$item = Get-Item $p
$ver = $item.VersionInfo.ProductVersion
if (-not [string]::IsNullOrWhiteSpace($ver)) {
$found += [pscustomobject]@{ Path = $p; Version = $ver }
}
} catch {
# ignore and continue
}
}
}
if ($found.Count -eq 0) {
Write-Output 'UNKNOWN - Google Chrome not found in standard paths'
exit 2
}
$results = @()
foreach ($f in $found) {
$patched = Test-Patched $f.Version
$results += [pscustomobject]@{ Path = $f.Path; Version = $f.Version; Patched = $patched }
}
$unknown = $results | Where-Object { $null -eq $_.Patched }
if ($unknown.Count -gt 0) {
$unknown | ForEach-Object { Write-Output ("UNKNOWN - Could not parse version '{0}' at {1}" -f $_.Version, $_.Path) }
exit 2
}
$vuln = $results | Where-Object { $_.Patched -eq $false }
if ($vuln.Count -gt 0) {
$vuln | ForEach-Object { Write-Output ("VULNERABLE - Chrome {0} at {1}" -f $_.Version, $_.Path) }
exit 1
}
$results | ForEach-Object { Write-Output ("PATCHED - Chrome {0} at {1}" -f $_.Version, $_.Path) }
exit 0
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
- Canadian Centre for Cyber Security advisory AV26-544
- GovCERT.HK Security Alert A26-06-08
- Tenable Nessus Plugin 319116 for CVE-2026-11309
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- SecurityWeek coverage of Chrome 149 fixes
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.