This is a loaded trapdoor, but only in a side hallway most Chrome users never open
CVE-2026-10978 is a use-after-free in Chrome's Chromoting component affecting Google Chrome on Windows before 149.0.7827.53. In plain English: if a victim on Windows processes attacker-controlled Chromoting / Chrome Remote Desktop-related network traffic, memory can be reused after release and turned into arbitrary code execution. The vendor text and the CVSS vector both imply no auth required but user interaction is required.
paragraph 2: Google's 8.8/HIGH baseline is technically defensible for a browser memory-corruption bug, but it overstates enterprise urgency for broad fleet patch triage. The key downward pressure is reach: this is Windows-only, tied to Chromoting rather than generic web rendering, and appears to need the victim to enter the relevant traffic path. With no KEV listing, no public PoC, and a very low EPSS, this looks more like a feature-scoped client RCE than a Monday-morning internet-fire drill.
3 steps from start to impact.
Get the victim into the Chromoting path
remotedesktop.google.com and related APIs.- Target is Windows
- Chrome version is earlier than 149.0.7827.53
- Chromoting / Chrome Remote Desktop use is allowed in the environment
- User performs the required interaction
- This is not a generic every-page browser drive-by based on the public description
- Many enterprises disable or heavily restrict Chrome Remote Desktop by policy
- Only a subset of users ever touch Chromoting at all
Deliver malicious network traffic to trigger UAF
- Attacker can influence the victim's Chromoting traffic
- The vulnerable code path is reachable in that session
- No public exploit chain or repro has surfaced yet
- Bug details are restricted by Google while the patch rolls out
- Modern browser hardening makes reliable UAF weaponization non-trivial
Convert memory corruption into code execution
- Successful exploit reliability on the target build
- The post-corruption payload survives browser mitigations
- Exploit reliability across Chrome point releases can be brittle
- EDR often catches the post-exploitation stage even when it misses the initial bug
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found. It is not listed in CISA KEV as of this assessment. |
|---|---|
| Proof-of-concept availability | No public PoC located in open web or GitHub searches. Google has kept bug details restricted in the release note workflow, which is normal for fresh Chrome fixes. |
| EPSS | 0.0008 per the provided intel, which is very low and consistent with a newly disclosed, non-weaponized client bug. I could not independently confirm a public percentile for this CVE from a primary EPSS query. |
| KEV status | Not KEV-listed. No CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = remote reach and high impact, but user interaction is required. That UI:R matters a lot here because the attacker appears to need the victim in a Chromoting-specific flow. |
| Affected versions | Google Chrome on Windows prior to 149.0.7827.53. Public vendor wording is Windows-specific for this CVE. |
| Fixed versions | Patched in the Chrome 149 stable train; Google announced 149.0.7827.53/54 for Windows/Mac on 2026-06-02. For this Windows CVE, treat 149.0.7827.53 or later as the safe floor. |
| Scanning / exposure reality | Shodan/Censys-style internet exposure counts are not meaningful because this is a client-side browser bug, not a server listening on a public port. The real exposure question is: *how many Windows endpoints run vulnerable Chrome, and how many of those users are allowed to use Chrome Remote Desktop / Chromoting?* |
| Disclosure and reporter | Google's stable desktop advisory was posted on 2026-06-02; third-party CVE/NVD indexing appeared on 2026-06-04 to 2026-06-05. The vendor lists it as reported by Google on 2026-05-15. |
noisgate verdict.
The decisive factor is reachability: the public record points to a Chromoting-specific Windows client path with required user interaction, not a broad unauthenticated web drive-by against every Chrome session. That sharply reduces exposed population and makes this a narrower fleet problem than the raw 8.8 suggests.
Why this verdict
- Feature-scoped attack surface: start from Google's 8.8/HIGH, then adjust down because this is tied to Chromoting, not the ordinary page-rendering path that every Chrome user hits all day.
- User interaction compounds the friction:
UI:Ris already in the CVSS, but in real deployments it implies social or operational positioning to get a user into the relevant CRD/Chromoting flow. - Reachable population is much smaller than 'all Chrome on Windows': many enterprises block or do not use Chrome Remote Desktop at all, which materially reduces exploitable exposure.
- Windows-only scope: this CVE's public description is specific to Windows, so mixed-platform fleets immediately shrink the patch universe.
- Threat intel is cold: no KEV, no public PoC found, and provided EPSS 0.0008 all push down from vendor baseline.
Why not higher?
There is no public evidence that attackers are exploiting this now, and the public description does not support treating it like a universal website-triggered Chrome zero-day. The combination of Chromoting-specific reachability, Windows-only scope, and required user interaction is too much friction for a HIGH or CRITICAL enterprise triage call.
Why not lower?
This is still a remote, no-privileges memory corruption bug in a massively deployed client. If the feature path is reachable in your environment, the end state is serious enough that it does not belong in backlog-hygiene LOW territory.
What to do — in priority order.
- Disable Chrome Remote Desktop where you do not need it — Use Google's enterprise controls to turn off or restrict Chrome Remote Desktop / Chromoting for users and hosts that do not need it. For a MEDIUM verdict there is no mitigation SLA; use this as immediate exposure reduction while you work inside the 365-day remediation window.
- Disable CRD firewall traversal — Set
RemoteAccessHostFirewallTraversalto0on managed Windows systems if CRD must remain available only for LAN/VPN use. This cuts off broader internet-mediated host reachability and is a practical scoping control when business teams insist on keeping CRD. - Block CRD service URLs for non-admin populations — Block
https://remotedesktop-pa.googleapis.comand, if appropriate,https://remotedesktop.google.comfor user groups that should never use the feature. There is no noisgate mitigation SLA for MEDIUM; apply this where the business case is weak and keep patching inside the 365-day remediation deadline. - Prioritize high-risk user cohorts first — If you cannot patch the whole Windows fleet at once, focus policy restrictions and accelerated patching on help-desk, MSP, contractor, and admin workstations that are more likely to use remote-support tooling. Those users are the most plausible reachable population for this bug.
- A generic web proxy URL filter alone does not fully solve this if users still have allowed access to the required CRD service endpoints or internal allowed flows.
- EDR alone is not a preventive control for the bug; it may catch payload execution after exploitation, but it does not remove the vulnerable memory-corruption condition.
- Internet exposure scans are the wrong measurement. This is not a public daemon you can count with Shodan.
Crowdsourced verification payload.
Run this on the target Windows endpoint or via your software deployment / EDR remote shell. Invoke it with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-10978.ps1; standard user rights are usually enough to read file versions, but local admin helps if your tooling blocks access to machine-wide install paths.
# check-chrome-cve-2026-10978.ps1
# Purpose: Detect likely exposure to CVE-2026-10978 on Windows by checking Chrome version
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'Stop'
function Get-VersionObject {
param([string]$VersionString)
try { return [version]$VersionString } catch { return $null }
}
function Get-ChromeCandidates {
$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 ($p -and (Test-Path $p)) {
try {
$ver = (Get-Item $p).VersionInfo.ProductVersion
if (-not [string]::IsNullOrWhiteSpace($ver)) {
$found += [pscustomobject]@{ Path = $p; Version = $ver }
}
} catch {}
}
}
return $found
}
function Test-CRDHostInstalled {
$hostPaths = @(
"$env:ProgramFiles(x86)\Google\Chrome Remote Desktop\CurrentVersion\remoting_host.exe",
"$env:ProgramFiles\Google\Chrome Remote Desktop\CurrentVersion\remoting_host.exe"
)
foreach ($hp in $hostPaths) {
if (Test-Path $hp) { return $true }
}
return $false
}
$fixedFloor = Get-VersionObject '149.0.7827.53'
$candidates = Get-ChromeCandidates
$crdInstalled = Test-CRDHostInstalled
if (-not $candidates -or $candidates.Count -eq 0) {
Write-Output 'UNKNOWN - Google Chrome not found in standard install paths.'
exit 2
}
$vulnerable = $false
$unknownSeen = $false
foreach ($c in $candidates) {
$v = Get-VersionObject $c.Version
if ($null -eq $v) {
Write-Output ("UNKNOWN - Could not parse version at {0}: {1}" -f $c.Path, $c.Version)
$unknownSeen = $true
continue
}
if ($v -lt $fixedFloor) {
$suffix = if ($crdInstalled) { ' Chrome Remote Desktop host appears installed.' } else { ' Chrome Remote Desktop host not detected in standard paths.' }
Write-Output ("VULNERABLE - Chrome version {0} at {1} is older than 149.0.7827.53.{2}" -f $v, $c.Path, $suffix)
$vulnerable = $true
} else {
Write-Output ("PATCHED-CANDIDATE - Chrome version {0} at {1} meets or exceeds 149.0.7827.53." -f $v, $c.Path)
}
}
if ($vulnerable) {
exit 1
}
if ($unknownSeen) {
Write-Output 'UNKNOWN - At least one Chrome install could not be evaluated, and none were confirmed vulnerable.'
exit 2
}
Write-Output 'PATCHED - All detected Chrome installs meet or exceed 149.0.7827.53.'
exit 0
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- NVD detail page for CVE-2026-10978
- Google Chrome Enterprise - Control use of Chrome Remote Desktop
- Google Chrome Enterprise - Network guide for Chrome Remote Desktop
- Google Chrome Help - Access another computer with Chrome Remote Desktop
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- VulDB entry for CVE-2026-10978
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.