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.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.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.- 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.
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. |
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
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.
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
}