← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11309 · CWE-346 · Disclosed 2026-06-05

Insufficient policy enforcement in History in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"This is a browser trust nudge, not a fleet-owning bug: patch it, but don't let 4.3 fool you."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a crafted page

The attacker needs a user to browse to malicious HTML under their control. This is classic web delivery, not self-propagation. Weaponized tool: a normal phishing or lure page; there is no public exploit framework tied to this CVE.
Conditions required:
  • Target runs Chrome before 149.0.7827.53
  • User can be enticed to open attacker-controlled content
Where this breaks in practice:
  • 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
Detection/coverage: Standard vuln scanners can inventory Chrome version, but they will not prove exploitability. Web/email controls may detect the lure; endpoint scanners mainly give version coverage.
STEP 02

Spoof browser trust cues

Once the page is open, the bug can manipulate History-related UI behavior to present misleading trust signals. The practical goal is to make the victim believe they are on a safe or expected page, or to disguise a malicious workflow behind browser-native looking UI. Weaponized tool: browser UI deception, not memory corruption.
Conditions required:
  • Victim must render the malicious page successfully
  • The spoof must be convincing enough to influence user decisions
Where this breaks in practice:
  • 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
Detection/coverage: There is little direct signature coverage for UI spoofing. Detection is mostly indirect via phishing telemetry, suspicious browsing destinations, and user reports.
STEP 03

Convert deception into action

The attacker still needs a second-stage outcome such as credential entry, unsafe download approval, or navigation to a more malicious site. The vulnerability itself does not steal data, execute code, or alter the OS. Weaponized tool: phishing workflow or social-engineering follow-on.
Conditions required:
  • User must trust the spoofed UI
  • A second malicious objective must be chained after the spoof
Where this breaks in practice:
  • 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
Detection/coverage: Credential theft or malicious download stages may be caught by IdP logs, CASB, email telemetry, EDR, or web proxy events; the CVE itself has weak standalone detection.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation located. CISA KEV does not list this CVE.
KEV statusNot listed in CISA Known Exploited Vulnerabilities as of 2026-06-05.
Proof-of-concept availabilityNo public PoC found in the sources reviewed. This matters because UI-spoof bugs often need tailoring to be believable.
EPSS0.00013 from the user-provided intel block, indicating a very low modeled likelihood of near-term exploitation.
CVSS interpretationAV: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 mismatchThe 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 versionsChrome 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 versionsUpgrade 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 realityThis 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 reportingGoogle's stable-channel post is dated 2026-06-02 and notes the underlying issue was reported by Google on 2026-04-25.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.8/10)

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.

HIGH Affected version range and fixed versions
HIGH Absence of KEV listing
MEDIUM Real-world exploitability without public bug details

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: treat this as browser patch hygiene, not an incident-grade patch sprint. Because the reassessed verdict is LOW, there is no noisgate mitigation SLA and noisgate remediation SLA is effectively backlog hygiene rather than a hard deadline; roll Chrome to 149.0.7827.53/.54+ through your normal browser-update ring, verify endpoint version coverage this cycle, and spend scarce emergency patch capacity on Chrome bugs with memory corruption, sandbox escape, active exploitation, or KEV status instead.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
  3. Canadian Centre for Cyber Security advisory AV26-544
  4. GovCERT.HK Security Alert A26-06-08
  5. Tenable Nessus Plugin 319116 for CVE-2026-11309
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. SecurityWeek coverage of Chrome 149 fixes
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.