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.
3 steps from start to impact.
Deliver crafted web content
- Target is running Chrome on Windows
- Installed version is older than
149.0.7827.53 - User browses to attacker-controlled content
- 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
Reach the Chromoting code path
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.- The relevant
Chromotingfeature path is present and reachable in the victim build - Crafted input successfully hits the buggy validation logic
- 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
Turn bug trigger into security impact
- Attacker has a reliable exploitation primitive, not just a trigger
- Target defenses do not block the post-trigger behavior
- 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
chrome.exe spawning LOLBins; direct detection coverage for this exact CVE is presently low.The supporting signals.
| In-the-wild status | No confirmed active exploitation found during this assessment. It is not listed in CISA KEV. |
|---|---|
| PoC availability | No public PoC located in open-web searching for the exact CVE. That does *not* prove safety, but it does remove a major speed amplifier. |
| EPSS | 0.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 status | Not KEV-listed as checked against the current CISA catalog; no KEV add date or remediation due date applies. |
| Vendor classification mismatch | This 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 versions | Windows 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 versions | Google 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 reality | This 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 timing | Vendor 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. |
| Reporter | Google's release note attributes the issue as reported by Google on 2026-04-03. |
noisgate verdict.
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.
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.6enrichment 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.
What to do — in priority order.
- 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. - 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.
- Watch Chrome crash telemetry — Hunt for
chrome.execrashes, 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. - 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.
- 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.
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.
# 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
}
If you remember one thing.
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
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
- GovCERT.HK - Multiple Vulnerabilities in Google Chrome
- CISA Known Exploited Vulnerabilities Catalog
- FIRST - EPSS overview
- FIRST - EPSS API documentation
- Chrome Enterprise - Manage Chrome updates (Windows)
- Chromium issue reference for CVE-2026-11070
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.