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

Insufficient validation of untrusted input in Chromoting in Google Chrome on Windows prior to 149

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

This is more like a loose hinge on a side door than a blown-open front gate

CVE-2026-11070 is an *insufficient validation of untrusted input* flaw in Chrome's Chromoting component on Windows. Public advisories place affected builds before the Chrome 149 desktop release, with Windows fixed in the 149.0.7827.53/.54 train; for enterprise validation, 149.0.7827.53 is the safe floor and anything older should be treated as exposed.

The big story is the severity mismatch: the prompt carries a CRITICAL 9.6 label, but Google's own June 2, 2026 Chrome stable advisory lists CVE-2026-11070 as Medium, not Critical. That matters. With no KEV entry, no public exploit evidence, no public PoC, Windows-only scope, and user interaction implied by the broader browser exploitation model, this looks like a *chain component or hardening issue* rather than a one-click fleet-wide catastrophe.

"Treat this as a browser hardening fix, not a drop-everything Chrome zero-day."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver crafted web content

The attacker needs a user on Windows Chrome to open attacker-controlled content, typically a malicious page or redirected site. Public government advisories for the June 2026 Chrome release describe the overall class as exploitation through specially crafted web content rather than a remotely reachable service.
Conditions required:
  • Target is running Chrome on Windows
  • Installed version is older than 149.0.7827.53
  • User browses to attacker-controlled content
Where this breaks in practice:
  • Requires user interaction rather than blind internet exploitation
  • Windows-only; Mac/Linux fleet share is out of scope for this CVE
  • Enterprise browser isolation, URL filtering, and safe browsing controls can reduce reach
Detection/coverage: Generic vuln scanners can version-match Chrome reliably; network IDS usually cannot see a signature for this specific bug because the vulnerable surface is client-side browser parsing/logic.
STEP 02

Reach the Chromoting code path

The malicious content must exercise the vulnerable Chromoting input-validation path on Windows. Google has not publicly exposed enough root-cause detail to prove whether this is directly exploitable alone; based on the official Medium rating, the more realistic interpretation is that reaching impact requires a narrow trigger or an additional primitive.
Conditions required:
  • The relevant Chromoting feature path is present and reachable in the victim build
  • Crafted input successfully hits the buggy validation logic
Where this breaks in practice:
  • No public root-cause write-up or exploit recipe
  • Feature/path reachability is usually much narrower than 'any page equals compromise'
  • Modern browser mitigations can turn many logic bugs into non-exploitable crashes or dead ends
Detection/coverage: EDR may only see a browser crash or abnormal child-process behavior; there is no dependable public IOC set for CVE-2026-11070 specifically.
STEP 03

Turn bug trigger into security impact

For this CVE to matter operationally, the attacker still has to convert the validation flaw into something useful: code execution, sandbox weakening, data access, or another boundary bypass. The official Google classification being Medium is strong evidence that this conversion is *not* straightforward in real deployments.
Conditions required:
  • Attacker has a reliable exploitation primitive, not just a trigger
  • Target defenses do not block the post-trigger behavior
Where this breaks in practice:
  • No public PoC or in-the-wild exploitation evidence
  • Exploit reliability against modern Chrome sandboxing on Windows is usually non-trivial
  • EDR/ASR/Exploit Guard commonly stop or surface the post-exploit stage even if initial trigger lands
Detection/coverage: Look for Chrome crashes followed by unusual child processes, memory-corruption telemetry, or chrome.exe spawning LOLBins; direct detection coverage for this exact CVE is presently low.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found during this assessment. It is not listed in CISA KEV.
PoC availabilityNo public PoC located in open-web searching for the exact CVE. That does *not* prove safety, but it does remove a major speed amplifier.
EPSS0.00047 from the user intel block — extremely low predicted near-term exploitation probability. Percentile was not provided and was not confirmed from a primary-source CVE-specific API response in this assessment.
KEV statusNot KEV-listed as checked against the current CISA catalog; no KEV add date or remediation due date applies.
Vendor classification mismatchThis is the key fact: Google's June 2, 2026 Chrome stable post lists CVE-2026-11070 as Medium, while third-party enrichment in the prompt labels it Critical 9.6. I trust the vendor's own bug bucket here.
Affected versionsWindows Chrome before 149.0.7827.53 should be treated as vulnerable. Government advisories also phrase the desktop release as 149.0.7827.53/.54 for Windows/Mac, so the practical enterprise rule is upgrade to 149.0.7827.53 or later.
Fixed versionsGoogle shipped the fix in the Chrome 149 desktop stable rollout on 2026-06-02: Linux 149.0.7827.53; Windows/Mac 149.0.7827.53/.54.
Exposure realityThis is a client-side browser bug, so Shodan/Censys/FOFA-style internet counts are mostly irrelevant. Your exposure is driven by installed Windows Chrome population, not open ports.
Disclosure timingVendor release post is dated 2026-06-02; the Canadian advisory is 2026-06-03; the Hong Kong alert is 2026-06-05. The prompt's 2026-06-04 date looks like downstream feed timing rather than the original vendor publication date.
ReporterGoogle's release note attributes the issue as reported by Google on 2026-04-03.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The decisive factor is exploit-chain friction: the official Google advisory classifies this bug as *Medium*, which strongly suggests it is not a clean, one-bug, internet-scale RCE despite aggressive third-party enrichment. With no KEV entry, no public PoC, no public exploitation evidence, and Windows-only/browser-user reach, this is a real patch item but not a fleet-emergency event.

HIGH Affected version range and fixed build floor
HIGH Official vendor severity bucket is Medium, not Critical
MEDIUM Operational severity downgrade based on missing exploit evidence and likely chain dependence
LOW Exact root-cause exploit mechanics, because Google has not published full technical detail

Why this verdict

  • Vendor baseline correction: Google's own Chrome stable advisory on 2026-06-02 lists CVE-2026-11070 as Medium, so the prompt's Critical 9.6 enrichment is not a trustworthy vendor baseline.
  • User-driven client exploit path: attacker success starts with a Windows user opening crafted content, which is meaningfully narrower than an unauthenticated remote service bug.
  • No exploitation heat: no KEV, no public PoC, and no observed campaign reporting means there is no current evidence this bug is being operationalized at scale.
  • Windows-only narrowing: this is not a whole-Chrome-all-platforms event; it trims the reachable population in mixed estates.
  • Likely chain component, not stand-alone takeover: the combination of insufficient validation, sparse public detail, and Google's Medium bucket implies downward pressure because practical impact probably depends on additional conditions or a second bug.

Why not higher?

I am not scoring this HIGH or CRITICAL because the public evidence does not support an active, reliable, one-step browser-to-host compromise story. If this were a proven in-the-wild Chrome RCE/sandbox-escape primitive, it would almost certainly show up with a stronger vendor bucket, KEV traction, or public exploit attention very quickly.

Why not lower?

I am not dropping this to LOW or IGNORE because Chrome on Windows is massively deployed and the vulnerable surface is attacker-reachable through ordinary browsing. Even a medium-grade browser bug deserves cleanup through managed browser updates, especially on high-risk user populations.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome auto-update health — Validate Google Update, WSUS-equivalent packaging, or your browser management tooling so Windows endpoints converge to 149.0.7827.53+. For a MEDIUM finding there is no mitigation SLA, so use the next normal browser maintenance cycle rather than emergency change control.
  2. Tighten risky browsing paths — Apply or verify web filtering, Safe Browsing enforcement, and attachment detonation for users most likely to hit opportunistic exploit delivery. This is a sensible exposure reducer while patch rollout completes, but for MEDIUM there is no noisgate mitigation SLA — go straight to the remediation window.
  3. Watch Chrome crash telemetry — Hunt for chrome.exe crashes, abnormal child processes, or repeated browser faulting on Windows endpoints to catch exploit development or unstable triggering. Use this as detection enrichment during the normal remediation cycle.
  4. Prioritize admin and privileged workstations — Patch jump hosts, admin laptops, help-desk endpoints, and developer workstations first because browser compromise on privileged users carries outsized blast radius. Even without a mitigation SLA, front-loading high-value users is the right operational move.
What doesn't work
  • Perimeter firewall rules do not solve this; the exploit path is normal outbound web browsing, not inbound service exposure.
  • Network vulnerability scanners will only tell you the Chrome version state; they will not prove exploitability or catch weaponized page delivery.
  • MFA does not stop browser memory/logic exploitation on the endpoint; it only helps after credential theft, if that ever becomes the follow-on objective.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows host from an elevated PowerShell prompt so it can inspect machine-wide and per-user Chrome installs. Example: powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11070.ps1; it needs local admin to enumerate all user profile installs reliably.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-chrome-cve-2026-11070.ps1

# Purpose: Determine whether a Windows host is vulnerable to CVE-2026-11070 based on installed Chrome version.

# Output: VULNERABLE / PATCHED / UNKNOWN

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


$ErrorActionPreference = 'Stop'
$MinimumSafeVersion = [version]'149.0.7827.53'

function Compare-Version {
    param(
        [Parameter(Mandatory=$true)][string]$VersionString,
        [Parameter(Mandatory=$true)][version]$MinimumVersion
    )
    try {
        $v = [version]$VersionString
        return ($v -ge $MinimumVersion)
    } catch {
        return $null
    }
}

function Get-ChromeCandidates {
    $paths = New-Object System.Collections.Generic.List[string]

    $machinePaths = @(
        "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
        "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe"
    )

    foreach ($p in $machinePaths) {
        if ($p -and (Test-Path $p)) { [void]$paths.Add($p) }
    }

    $userRoot = 'C:\Users'
    if (Test-Path $userRoot) {
        Get-ChildItem -Path $userRoot -Directory -ErrorAction SilentlyContinue | ForEach-Object {
            $userChrome = Join-Path $_.FullName 'AppData\Local\Google\Chrome\Application\chrome.exe'
            if (Test-Path $userChrome) { [void]$paths.Add($userChrome) }
        }
    }

    return $paths | Sort-Object -Unique
}

try {
    $candidates = Get-ChromeCandidates

    if (-not $candidates -or $candidates.Count -eq 0) {
        Write-Output 'UNKNOWN: Google Chrome not found in standard machine-wide or per-user paths.'
        exit 2
    }

    $results = @()
    foreach ($path in $candidates) {
        try {
            $item = Get-Item $path
            $versionString = $item.VersionInfo.ProductVersion
            if (-not $versionString) { $versionString = $item.VersionInfo.FileVersion }

            $isSafe = Compare-Version -VersionString $versionString -MinimumVersion $MinimumSafeVersion

            $results += [pscustomobject]@{
                Path       = $path
                Version    = $versionString
                IsPatched  = $isSafe
            }
        } catch {
            $results += [pscustomobject]@{
                Path       = $path
                Version    = 'UNKNOWN'
                IsPatched  = $null
            }
        }
    }

    $vuln = $results | Where-Object { $_.IsPatched -eq $false }
    $unknown = $results | Where-Object { $_.IsPatched -eq $null }

    if ($vuln.Count -gt 0) {
        Write-Output 'VULNERABLE'
        $results | ForEach-Object {
            Write-Output ("{0} :: Version={1} :: Patched={2}" -f $_.Path, $_.Version, $_.IsPatched)
        }
        exit 1
    }

    if ($unknown.Count -gt 0 -and ($results | Where-Object { $_.IsPatched -eq $true }).Count -eq 0) {
        Write-Output 'UNKNOWN'
        $results | ForEach-Object {
            Write-Output ("{0} :: Version={1} :: Patched={2}" -f $_.Path, $_.Version, $_.IsPatched)
        }
        exit 2
    }

    Write-Output 'PATCHED'
    $results | ForEach-Object {
        Write-Output ("{0} :: Version={1} :: Patched={2}" -f $_.Path, $_.Version, $_.IsPatched)
    }
    exit 0

} catch {
    Write-Output ('UNKNOWN: error while checking Chrome version - ' + $_.Exception.Message)
    exit 3
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: correct your triage data first — this is not a vendor-declared critical Chrome emergency, it is a vendor-listed Medium Windows browser fix in the Chrome 149 release. There is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, fold it into your standard managed Chrome rollout, verify Windows endpoints reach 149.0.7827.53 or later, and complete patch adoption inside the noisgate remediation SLA of ≤ 365 days unless new exploitation evidence appears, in which case you should immediately reclassify and accelerate.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
  3. GovCERT.HK - Multiple Vulnerabilities in Google Chrome
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST - EPSS overview
  6. FIRST - EPSS API documentation
  7. Chrome Enterprise - Manage Chrome updates (Windows)
  8. Chromium issue reference for CVE-2026-11070
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.