Use after free in Cast Streaming in Google Chrome prior to 149

CVE-2026-10888 is a use-after-free in Chrome Cast Streaming that affects Google Chrome builds before 149.0.7827.53; the June 2026 desktop rollout points to 149.0.7827.53/54 on Windows and macOS and 149.0.7827.53 on Linux as the fixed line. The bug sits on a local-network-facing Cast path, so the attacker is not driving this from the public internet; they need to be on the same local network segment and then feed Chrome malicious Cast-related traffic to reach code execution.

The vendor's HIGH 8.8 score is technically defensible in a lab because memory corruption plus no auth / no user interaction is serious. In enterprise reality, though, AV:A is doing a lot of work: this is a post-perimeter, same-LAN attack, impact is described as inside the sandbox, there is no KEV listing, and the supplied EPSS is effectively zero. That combination makes this a patch promptly but not pager-worthy browser issue.

Why this verdict

• Start at vendor 8.8, then subtract for AV:A: same-LAN access is a real prerequisite, not a rounding error. It implies either hostile guest/Wi-Fi proximity or an earlier foothold inside the enterprise.
• Subtract again for population narrowing: exploitation needs a vulnerable Chrome build *and* a reachable Cast Streaming path on an actively running browser, which is a much smaller target set than generic web-content RCE.
• Hold above LOW because no auth + no UI + memory corruption still matter: if an attacker is already on the segment, this is cleaner than phishing and can be abused without victim clicks.

Why not higher?

This is not broadly internet-reachable, not KEV-listed, and not backed by active exploitation evidence. Most importantly, the stated impact is inside Chrome's sandbox, so the blast radius is meaningfully smaller than a one-shot endpoint takeover.

Why not lower?

I am not pushing this to LOW because the bug still offers code execution potential with no credentials and no user interaction once the attacker reaches the right network position. In flat networks, shared Wi-Fi, labs, kiosks, or unmanaged branch environments, the adjacent-network hurdle is not hypothetical.

1. Segment user endpoints from untrusted local networks — Put guest Wi-Fi, contractor SSIDs, lab VLANs, and unmanaged IoT segments behind controls that prevent peer-to-peer reachability to employee endpoints. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control meaningfully reduces exposure while normal browser updates roll out.
2. Restrict Cast discovery and local service chatter where business-unneeded — Filter or tightly scope local multicast and Cast-adjacent traffic between endpoint segments when casting is not a business requirement. There is no mitigation SLA for this severity, but applying this during routine network-policy cycles cuts the reachable population before patch completion.
3. Enforce Chrome auto-update compliance — Use enterprise browser management to identify endpoints stuck below 149.0.7827.53 and remediate update drift. For MEDIUM, prioritize it through standard operations and finish actual patching inside the 365-day remediation window rather than emergency change management.
4. Watch for abnormal east-west discovery traffic — Baseline mDNS/SSDP/Cast-related traffic on corporate WLANs and alert on unusual bursts, spoofing behavior, or device-to-device traffic that should not exist. This will not prove exploitation, but it is the right compensating detection layer for a same-LAN browser bug.

Run this on the target Windows endpoint or through your fleet tool (for example: powershell.exe -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-10888.ps1). It needs only standard user rights because it reads file versions from common Chrome install paths; output is exactly VULNERABLE, PATCHED, or UNKNOWN.

# check-chrome-cve-2026-10888.ps1

# Purpose: Check whether Google Chrome on Windows is below the fixed version for CVE-2026-10888.

# Fixed baseline used here: 149.0.7827.53 (Windows)

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


$ErrorActionPreference = 'Stop'

function Get-VersionObject {
    param([string]$VersionString)
    try {
        return [version]$VersionString
    } catch {
        return $null
    }
}

$fixedVersion = Get-VersionObject '149.0.7827.53'
$chromePaths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
    "$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)

$found = @()
foreach ($path in $chromePaths) {
    if (Test-Path $path) {
        try {
            $item = Get-Item $path
            $ver = $item.VersionInfo.ProductVersion
            if (-not $ver) { $ver = $item.VersionInfo.FileVersion }
            $verClean = ($ver -split '\s+')[0]
            $verObj = Get-VersionObject $verClean
            if ($verObj) {
                $found += [pscustomobject]@{
                    Path = $path
                    Version = $verClean
                    VersionObject = $verObj
                }
            }
        } catch {
            # Ignore broken path/version reads and continue

        }
    }
}

if ($found.Count -eq 0) {
    Write-Output 'UNKNOWN'
    exit 2
}

# If any installed Chrome copy is below fixed, treat host as vulnerable.

$vuln = $found | Where-Object { $_.VersionObject -lt $fixedVersion }
if ($vuln.Count -gt 0) {
    Write-Output 'VULNERABLE'
    exit 1
}

Write-Output 'PATCHED'
exit 0

Sources

1. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
2. Canadian Centre for Cyber Security AV26-544
3. FIRST EPSS data and field definitions
4. CISA Known Exploited Vulnerabilities Catalog
5. Analogous Chrome Cast CVE-2026-7349 (same-LAN Cast RCE pattern)
6. Analogous Chrome Cast CVE-2026-7338 analysis
7. Censys overview of internet-exposed asset discovery limits
8. Chromecast-related port exposure background