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

Use after free in Chromecast in Google Chrome prior to 149

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

This is a second lock on the vault door, not the front gate

CVE-2026-10884 is a use-after-free in Chrome's Chromecast component affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and Mac. The key clause is the one most dashboards bury: exploitation assumes the attacker has already compromised the renderer process and can then drive a crafted HTML page into the vulnerable path. In plain English, this is not the initial foothold; it's a follow-on browser-chain bug.

The user-supplied vendor baseline of HIGH 8.3 overstates the enterprise patch urgency for standalone prioritization. Yes, memory corruption in a browser-side component matters, but the prerequisite of renderer compromise first is major friction, and there is no KEV listing, no public PoC, and no confirmed in-the-wild exploitation in the sources reviewed. For a fleet owner, this lands as a meaningful chain hardener rather than a drop-everything internet-edge emergency.

"Real bug, wrong panic level: this is a post-renderer-compromise chain, not a clean drive-by on 10,000 desktops."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code execution in the renderer first

The attacker needs an independent bug or chain to gain execution inside Chrome's renderer process. That could be a separate V8, Blink, media, or scripting bug delivered through a malicious site or ad. CVE-2026-10884 does not provide this initial compromise by itself.
Conditions required:
  • Victim browses attacker-controlled or attacker-influenced content
  • A separate renderer-compromise primitive already exists and works on the target build
Where this breaks in practice:
  • This is a post-exploitation prerequisite; many campaigns never get past the renderer boundary
  • Modern browser exploit chains increasingly require multiple bugs and high reliability
Detection/coverage: No vulnerability scanner can prove this step from versioning alone; this is exploit-chain behavior more than inventory state.
STEP 02

Reach the vulnerable Chromecast code path

Once inside the renderer, the attacker must steer execution into the Chromecast feature path with crafted page content that exercises the freed object. Because bug details are still restricted, the exact trigger surface is not public, which raises attacker cost. The likely weapon is bespoke HTML/JS tailored to the target build.
Conditions required:
  • Target runs a vulnerable Chrome build
  • Relevant Cast/Chromecast code path is present and reachable from normal browsing context
Where this breaks in practice:
  • Restricted bug details slow opportunistic weaponization
  • Not every browsing session will naturally exercise the exact lifetime sequence needed for a UAF
Detection/coverage: Version scanners can flag vulnerable builds, but they cannot verify trigger reachability. Expect broad asset detection, weak exploit-path detection.
STEP 03

Convert the UAF into reliable corruption

A use-after-free is only valuable if the attacker can shape allocator state and reclaim the freed object with controlled data. In real deployments, browser mitigations, allocator behavior, and version drift often make this unreliable. The absence of a public exploit strongly suggests this step is non-trivial today.
Conditions required:
  • Predictable heap behavior on the target platform/build
  • Successful grooming from renderer-controlled content
Where this breaks in practice:
  • Heap exploitation reliability varies by OS and patch level
  • Browser hardening, sandboxing, and crash recovery can turn exploitation into mere browser crashes
Detection/coverage: EDR may only see renderer/browser crashes or child-process instability. Signature-based detection for the exploit itself is unlikely.
STEP 04

Use the bug as a chain amplifier

If exploitation succeeds, the attacker may extend control beyond the original renderer foothold, likely toward a sandbox escape or higher-value browser process impact. That is why the bug matters. But the blast radius is contingent on step 1 already being true, which keeps this from being a top-of-queue standalone patch event.
Conditions required:
  • Successful memory corruption exploitation
  • A path from corrupted state to meaningful post-renderer impact
Where this breaks in practice:
  • Impact is gated behind a full chain, not a single bug
  • No confirmed active exploitation or turnkey public tooling lowers near-term fleet risk
Detection/coverage: Most enterprise tools detect the aftermath better than the exploit: browser crashes, abnormal child-process trees, and follow-on endpoint activity.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation in reviewed sources, and not listed in CISA KEV as of review. Google/Chrome release notes do not call out active exploitation for this release. Sources: Chrome release, CISA KEV
Public PoC availabilityNo public PoC located. The backing Chromium issue is still access-restricted, which usually delays copycat weaponization. Source: Chromium issue 503617302
EPSSNo CVE-specific EPSS value was surfaced in the primary sources reviewed at write time; treat EPSS as not yet available / not yet indexed for this CVE rather than as zero. Sources: FIRST EPSS, FIRST EPSS API docs
KEV statusNot KEV-listed. That matters because KEV is the clearest public signal that defenders are already losing this fight in the wild. Source: CISA KEV catalog
CVSS vector reality checkCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H bakes in big impact, but also admits high complexity and user interaction. The bigger real-world friction is the description itself: attacker must already have compromised the renderer process.
Affected versionsAffected on desktop Chrome before 149.0.7827.53 (Linux) and before 149.0.7827.53/54 (Windows/Mac). Sources: Chrome release, Canadian Centre advisory AV26-544
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux and 149.0.7827.54 or later on Windows/Mac for the stable fix line. Source: Chrome release
Disclosure and reportingPublicly disclosed 2026-06-04 in the CVE stream surrounding Chrome 149; the Chrome release note says it was reported by Google on 2026-04-17. Source: Chrome release
Exposure populationChrome is ubiquitous, but this vuln is not an internet-exposed service. Shodan/Censys-style exposure counts are not meaningful here; the relevant population is managed desktop/browser estate, not open ports. That's a real downgrade versus server-side RCEs.
Historical analogThis looks operationally similar to earlier Chrome Cast bugs that also required prior renderer compromise, such as CVE-2023-5473. Those patterns are serious for exploit developers but weaker as standalone enterprise patch fire alarms. Source: Rapid7 CVE-2023-5473
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The single decisive factor is the renderer-compromise prerequisite. That makes this a chain-enabling browser bug, not a clean unauthenticated drive-by against your whole fleet, and that sharply narrows real-world exploit reach despite the ugly memory-corruption class.

HIGH Prerequisite analysis: attacker already needs renderer compromise
MEDIUM Final impact assessment despite restricted Chromium bug details
HIGH No-KEV / no-public-PoC / no-confirmed-active-exploitation readout

Why this verdict

  • Major downward pressure: requires prior renderer compromise. This is already post-initial-exploitation, which means the attacker has to win a separate browser bug first.
  • Further downward pressure: no KEV, no public PoC, no active exploitation evidence. That keeps this out of the emergency browser patch bucket.
  • Still not low: Chrome is everywhere and sandbox-boundary bugs matter. If paired with a renderer exploit, this can materially improve attacker outcomes on a large employee fleet.

Why not higher?

If this were a one-bug remote compromise from a crafted page, or if Google/CISA were signaling in-the-wild abuse, this would sit much higher. Instead, the exploit chain starts with a different vulnerability, and the restricted bug details plus lack of public weaponization materially reduce present-day operational risk.

Why not lower?

A use-after-free in a ubiquitous browser component is never pure backlog fluff. Once an attacker has renderer control, second-stage browser bugs that can extend impact are exactly the kind of chain pieces high-end operators prize, so dismissing it as LOW would understate the blast-radius potential.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update — Verify enterprise policy is actually enforcing Chrome updates and relaunch prompts across the fleet. For a MEDIUM finding there is no mitigation SLA — use this as hardening while you work inside the 365-day remediation window.
  2. Disable Cast features where unused — If your user base does not need browser casting, disable Cast/Chromecast-related functionality through managed browser policy on high-risk groups first. This reduces reachable attack surface without waiting for perfect patch coverage; for MEDIUM, there is no mitigation SLA, so deploy as practical before the remediation deadline.
  3. Protect the front half of the chain — Keep Safe Browsing, site isolation, sandboxing, exploit protection, and modern EDR browser monitoring enabled, because the real friction here is stopping the renderer compromise that must come first. This is the control layer most likely to break the chain before CVE-2026-10884 ever matters.
  4. Watch for browser crash clusters — Centralize crash telemetry for Chrome processes and look for version-specific spikes after suspicious browsing activity. That will not confirm exploitation on its own, but it is one of the few practical fleet-wide signals for failed memory-corruption attempts.
What doesn't work
  • Blocking inbound network exposure does not solve this; Chrome desktop is not being attacked as a listening service.
  • Relying on vulnerability scanners alone does not prove exploitability; they can tell you the version is old, not whether the attacker can satisfy the prior renderer-compromise prerequisite.
  • Treating generic web filtering as sufficient is weak here; once a malicious page lands and a renderer bug exists, this CVE is a chain step, not a domain reputation problem.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-inventory agent. Invoke it as python3 check_chrome_149_cast_uaf.py with standard user rights; admin is not required. It checks common install locations for Chrome/Chromium on Windows, macOS, and Linux and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_149_cast_uaf.py
# Detects whether locally installed Google Chrome / Chromium is below the fixed version
# for CVE-2026-10884.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

FIX_LINUX = (149, 0, 7827, 53)
FIX_MAC = (149, 0, 7827, 54)
FIX_WINDOWS = (149, 0, 7827, 54)


def parse_ver(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def find_linux():
    candidates = [
        'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser'
    ]
    for c in candidates:
        path = shutil.which(c)
        if path:
            out = run_cmd([path, '--version'])
            ver = parse_ver(out)
            if ver:
                return c, path, ver
    return None, None, None


def find_mac():
    apps = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium'
    ]
    for app in apps:
        if Path(app).exists():
            out = run_cmd([app, '--version'])
            ver = parse_ver(out)
            if ver:
                return Path(app).name, app, ver
    return None, None, None


def find_windows():
    local = os.environ.get('LOCALAPPDATA', '')
    pf = os.environ.get('PROGRAMFILES', '')
    pfx86 = os.environ.get('PROGRAMFILES(X86)', '')
    candidates = [
        os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(local, 'Chromium', 'Application', 'chrome.exe'),
        os.path.join(pf, 'Chromium', 'Application', 'chrome.exe'),
        os.path.join(pfx86, 'Chromium', 'Application', 'chrome.exe'),
    ]
    for exe in candidates:
        if exe and Path(exe).exists():
            out = run_cmd([exe, '--version'])
            ver = parse_ver(out)
            if ver:
                return Path(exe).name, exe, ver
    return None, None, None


def cmp_ver(a, b):
    return (a > b) - (a < b)


def main():
    system = platform.system()
    name = path = None
    ver = None
    fixed = None

    if system == 'Linux':
        name, path, ver = find_linux()
        fixed = FIX_LINUX
    elif system == 'Darwin':
        name, path, ver = find_mac()
        fixed = FIX_MAC
    elif system == 'Windows':
        name, path, ver = find_windows()
        fixed = FIX_WINDOWS
    else:
        print('UNKNOWN - unsupported operating system: {}'.format(system))
        sys.exit(2)

    if not ver:
        print('UNKNOWN - Chrome/Chromium not found in common locations')
        sys.exit(2)

    status = 'PATCHED' if cmp_ver(ver, fixed) >= 0 else 'VULNERABLE'
    print('{} - product={} path="{}" version={} fixed_threshold={}'.format(
        status,
        name,
        path,
        '.'.join(map(str, ver)),
        '.'.join(map(str, fixed))
    ))

    if status == 'PATCHED':
        sys.exit(0)
    else:
        sys.exit(1)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a browser-chain hardening item, not a fleet-wide fire drill: inventory all Chrome desktop installs below 149.0.7827.53 (Linux) and 149.0.7827.54 (Windows/Mac), fold them into normal browser patch governance, and optionally disable Cast where the feature is unused. Because this verdict is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; your noisgate remediation SLA is ≤ 365 days for the vendor patch, with faster cleanup on admin workstations, developer browsing endpoints, and other high-risk user tiers if you have the operational room.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue 503617302
  3. Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. Rapid7 historical analog - CVE-2023-5473 Cast use-after-free
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.