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

Use after free in Chromoting in Google Chrome on Windows prior to 149

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

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.

"Real bug, real RCE potential, but the reach is narrowed hard by Windows-only + Chromoting path + user interaction."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Get the victim into the Chromoting path

The attacker first needs a Windows user running vulnerable Chrome to interact with the Chromoting / Chrome Remote Desktop workflow, not just browse an ordinary website. In practice that means steering the user into a CRD session or another code path that causes Chrome to process attacker-controlled Chromoting traffic, using the service flows documented by Google for remotedesktop.google.com and related APIs.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Vulnerability scanners can reliably flag outdated Chrome versions, but they generally cannot confirm reachability of the Chromoting code path without policy and usage telemetry.
STEP 02

Deliver malicious network traffic to trigger UAF

Once the victim is in scope, the attacker uses a custom malicious Chromoting traffic generator against the Chrome Remote Desktop protocol path to trigger the use-after-free. The public advisory does not publish crash details, so exploit development likely depends on private bug knowledge or significant reverse engineering of the patched build.
Conditions required:
  • Attacker can influence the victim's Chromoting traffic
  • The vulnerable code path is reachable in that session
Where this breaks in practice:
  • 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
Detection/coverage: Network IDS coverage is likely weak because the protocol is application-specific and exploit artifacts are not public. Expect version-based exposure detection to outperform signature-based exploit detection.
STEP 03

Convert memory corruption into code execution

If the memory corruption is stabilized, the attacker gains arbitrary code execution in the Chrome context on the Windows endpoint. That is serious, but the practical blast radius is still limited by the fact that the attacker had to first land in a narrow feature path rather than any ordinary web session.
Conditions required:
  • Successful exploit reliability on the target build
  • The post-corruption payload survives browser mitigations
Where this breaks in practice:
  • Exploit reliability across Chrome point releases can be brittle
  • EDR often catches the post-exploitation stage even when it misses the initial bug
Detection/coverage: Behavioral EDR is your best chance here: suspicious child processes from Chrome, unusual memory protections, or payload staging on the endpoint.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found. It is not listed in CISA KEV as of this assessment.
Proof-of-concept availabilityNo 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.
EPSS0.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 statusNot KEV-listed. No CISA due date applies.
CVSS vectorCVSS: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 versionsGoogle Chrome on Windows prior to 149.0.7827.53. Public vendor wording is Windows-specific for this CVE.
Fixed versionsPatched 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 realityShodan/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 reporterGoogle'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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.3/10)

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.

MEDIUM Severity downgrade from vendor HIGH to noisgate MEDIUM
HIGH Affected version floor and fixed version identification
MEDIUM Assessment that exposure is gated by Chromoting workflow usage

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:R is 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. Disable CRD firewall traversal — Set RemoteAccessHostFirewallTraversal to 0 on 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.
  3. Block CRD service URLs for non-admin populations — Block https://remotedesktop-pa.googleapis.com and, if appropriate, https://remotedesktop.google.com for 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning: inventory Windows Chrome installs below 149.0.7827.53 and intersect that with users or hosts allowed to use Chrome Remote Desktop / Chromoting. If CRD is already blocked by policy, document that as exposure reduction; for this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window. Under the noisgate remediation SLA, get remaining vulnerable Windows Chrome installs to 149.0.7827.53/54 or later within 365 days, with faster handling for remote-support staff, admins, and contractor endpoints that are more likely to hit the affected feature path.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. NVD detail page for CVE-2026-10978
  3. Google Chrome Enterprise - Control use of Chrome Remote Desktop
  4. Google Chrome Enterprise - Network guide for Chrome Remote Desktop
  5. Google Chrome Help - Access another computer with Chrome Remote Desktop
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS API documentation
  8. VulDB entry for CVE-2026-10978
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.