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

Use after free in Cast in Google Chrome prior to 149

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

This is a loaded mousetrap hidden on the office Wi-Fi, not a sniper rifle pointed from the internet

CVE-2026-10926 is a use-after-free in Chrome's Cast component. Per the supplied intel and Google's June 2, 2026 stable release, affected builds are Chrome before 149.0.7827.53; Google shipped fixes in 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and Mac, with Android 149.0.7827.59 inheriting the same desktop security fixes. The important constraint is the attack vector: the adversary must be on the same local network segment and able to reach Cast-related traffic paths.

Google's HIGH 8.8 is technically defensible from raw impact math, but it runs hot for enterprise patch triage. The decisive friction is attacker position: adjacent-network exploitation means the attacker already has a foothold, rogue device, or physical presence on a reachable user segment. With no KEV entry, no public exploitation evidence, and an EPSS of 0.00008, this is a real bug worth fixing in the normal browser train, not an emergency change-window breaker.

"Scary bug class, wrong threat model: this is a same-LAN Chrome bug, not an internet-grade fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land on a reachable user segment

The attacker first needs to share the target's local network path or an L3 segment where Cast traffic is permitted. In practice that means a rogue device on office Wi-Fi, a compromised endpoint already inside, or a flat guest/BYOD network. Weaponized tooling at this stage is mundane discovery kit such as mdns-scan, nmap, or a custom mDNS/DNS-SD enumerator against _googlecast._tcp and Cast-adjacent ports.
Conditions required:
  • Attacker has presence on the same LAN or a routed segment that can reach Cast traffic
  • Target runs a vulnerable Chrome build
  • Segmentation or client isolation does not block relevant traffic
Where this breaks in practice:
  • Modern enterprises often separate guest, BYOD, corp, and kiosk networks
  • Client isolation and NAC kill a lot of adjacent-only attack paths before they start
  • This prerequisite already implies post-perimeter access or physical proximity
Detection/coverage: NDR can flag unusual mDNS/DNS-SD discovery bursts, scans touching TCP 8008/8009 from non-AV equipment, or east-west reconnaissance from guest/BYOD ranges.
STEP 02

Reach the Cast surface

Once adjacent, the attacker must actually talk to the Cast-related path Chrome uses. Google's own enterprise guidance says sender/receiver communication needs a routable path to the receiver IP on TCP 8008-8009 and no packet filtering; a plausible weaponized path is a custom Cast traffic generator that emits malformed network traffic after discovery.
Conditions required:
  • Cast traffic is reachable across the local segment
  • Ports and service discovery are not filtered
  • The target host is actively running Chrome
Where this breaks in practice:
  • Many enterprises block or rate-limit lateral user-to-user traffic
  • Some fleets disable Cast or Media Router features entirely
  • Cast visibility often breaks across VLANs and Wi-Fi isolation boundaries
Detection/coverage: Network controls can see unusual workstation-to-workstation Cast traffic; traditional vuln scanners will not reliably validate exploitability here, so version-based inventory beats probe-based detection.
STEP 03

Trigger the memory corruption

The exploit then needs to hit the Cast bug with the right malformed traffic and win the race/memory conditions needed for a use-after-free. Because Chromium keeps issue details restricted until users are patched, there is no public exploit recipe to lower the bar. Expect a working exploit to require custom dev work rather than copy-paste tradecraft.
Conditions required:
  • A precisely crafted network payload reaches the vulnerable code path
  • Exploit reliability matches the victim OS/build combination
  • Chrome process state lines up with the vulnerable path
Where this breaks in practice:
  • No public PoC located
  • Restricted bug details slow weaponization
  • Use-after-free reliability across browser builds is rarely trivial
Detection/coverage: Browser crash spikes, repeated renderer/network-service faults, and EDR telemetry around abnormal Chrome instability are your best hints before patch verification.
STEP 04

Convert code execution into business impact

Even after successful memory corruption, the attacker still has to turn that foothold into useful post-exploitation on the endpoint. Public materials do not currently show a broader chain, active campaign, or turnkey follow-on. That keeps blast radius below the usual unauthenticated remote browser panic level unless you also assume flat networks and weak endpoint controls.
Conditions required:
  • Exploit lands code execution in a useful browser context
  • Endpoint protections do not kill the post-exploitation stage
  • The compromised workstation has data or access worth pivoting from
Where this breaks in practice:
  • EDR and browser hardening can still contain the follow-on stage
  • No evidence yet of mass exploitation tradecraft
  • Adjacent-only bugs do not scale like internet-facing RCEs
Detection/coverage: Look for suspicious Chrome child processes, token theft behavior, unusual local network fan-out from a user workstation, and EDR alerts tied to browser-originated execution.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public in-the-wild exploitation evidence found, and it is not listed in the CISA KEV catalog.
Proof-of-concept availabilityNo public PoC, Metasploit module, or known nuclei template located. The Chromium issue remains access-restricted at issues.chromium.org/issues/500075522, which raises attacker effort.
EPSSUser-supplied EPSS is 0.00008 (~0.008%), which is extremely low. FIRST defines EPSS as the probability of exploitation being observed in the next 30 days: EPSS.
KEV status and datesNot KEV-listed; there is no dateAdded or federal due date for this CVE in CISA's authoritative catalog.
CVSS vector readoutCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H means adjacent network, low complexity, no auth, no clicks, high CIA impact. The whole reassessment turns on AV:A being materially narrower than AV:N in real enterprise networks.
Affected versionsSupplied intel says Chrome prior to 149.0.7827.53. Google's stable release on 2026-06-02 shipped 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac).
Fixed versionsVendor-fixed in 149.0.7827.53/54 for desktop, and Chrome for Android 149.0.7827.59 carries the same desktop security fixes. I found no authoritative vendor note on downstream distro backports for this specific CVE, so treat distro Chromium packages separately.
Exposure and scanning realityGoogle's enterprise Cast guidance says sender/receiver communication needs a routable path and TCP 8008-8009 without filtering. That makes this a local reachability problem, so Shodan/GreyNoise-style internet exposure is the wrong prioritization lens for most fleets.
Disclosure and reporting timelineChromium credits Google as reporter on 2026-04-06 in issue 500075522; Google patched stable desktop on 2026-06-02; the supplied CVE disclosure date is 2026-06-04.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.1/10)

The single most important driver is attacker position: exploitation requires adjacent network access, which usually means the adversary is already inside your perimeter or physically present on a reachable user segment. That sharply narrows the exposed population compared with classic browser RCEs delivered from the public internet, and the lack of KEV/PoC/exploitation evidence removes the main arguments for emergency treatment.

HIGH Adjacent-network attacker requirement materially lowers exposed population
MEDIUM Vendor-fixed version range and timeline from Google release notes
LOW Exact post-exploitation blast radius beyond initial code execution is not public because bug details are restricted

Why this verdict

  • Downshift for attacker position AV:A is not AV:N. The attacker must already share a reachable local segment or have an internal foothold, so I cut the vendor's 8.8 materially on real-world reachability grounds.
  • Downshift again for exposure fraction Cast paths depend on local routing, mDNS/service-discovery visibility, and permissive east-west traffic on ports like 8008/8009; segmentation, client isolation, NAC, and disabled Cast features remove a large share of enterprise endpoints from practical exposure.
  • No urgency amplifier present There is no KEV listing, no public exploitation evidence, no public PoC, and EPSS is 0.00008. Those are exactly the signals that would have kept this in HIGH if they existed.

Why not higher?

This is not an internet-reachable browser bug you should model as mass drive-by compromise. The adjacent-network prerequisite compounds with local traffic requirements, so the reachable population is much smaller than raw CVSS suggests. On top of that, public weaponization friction is non-trivial because Chromium has restricted bug details and no public exploit surfaced.

Why not lower?

I am not calling this LOW because the product footprint is enormous and the exploit needs no authentication and no user clicks once the attacker has local reachability. In flat office Wi-Fi, lab, kiosk, or mixed BYOD segments, one hostile device could still turn this into a meaningful workstation compromise path.

05 · Compensating Control

What to do — in priority order.

  1. Segment user networks — Separate guest, BYOD, corp, kiosk, and lab endpoints so adjacent-only bugs stay adjacent. For a MEDIUM verdict there is no mitigation SLA; use this where you already know user VLANs are flat, while planning vendor patching inside the 365-day remediation window.
  2. Block unnecessary Cast paths — If your business does not depend on Chrome casting, restrict east-west access to Cast discovery/control traffic, especially mDNS exposure and TCP 8008-8009. There is no mitigation SLA for MEDIUM, so do this opportunistically in higher-risk segments rather than as emergency change work.
  3. Disable Cast where unused — Use Chrome enterprise policy to reduce the reachable attack surface on kiosks, VDI, shared devices, and tightly managed user fleets that do not need Cast. Again, no mitigation SLA applies here; fold it into hardening work while the browser update rolls through normal channels.
  4. Hunt for browser instability — Watch EDR, crash telemetry, and helpdesk spikes for Chrome crashes or renderer/network-service faults on vulnerable builds, especially on shared Wi-Fi or conference-room networks. This is not a substitute for patching, but it can surface exploit testing during the remediation window.
What doesn't work
  • A perimeter WAF does not help; this is not a public web-app path.
  • MFA does nothing here because the exploit path does not require authentication.
  • Email filtering is irrelevant because there is no phishing or document-open step in the described attack chain.
  • Blindly prioritizing by internet exposure scanners is misleading because the exploit requires local network adjacency, not public reachability.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management runner, not from an auditor workstation. Invoke it with python3 check_cve_2026_10926.py on macOS/Linux or py check_cve_2026_10926.py on Windows; no admin rights are normally required because it only reads installed Chrome version metadata from standard paths or the registry.

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

import os
import platform
import plistlib
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


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


def version_str(v):
    return '.'.join(str(x) for x in v) if v else 'unknown'


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 check_linux():
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
        ['/snap/bin/chromium', '--version'],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return (' '.join(cmd[:-1]), v)
    return (None, None)


def check_macos():
    plist_paths = [
        '/Applications/Google Chrome.app/Contents/Info.plist',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/Info.plist'),
        '/Applications/Chromium.app/Contents/Info.plist',
        os.path.expanduser('~/Applications/Chromium.app/Contents/Info.plist'),
    ]
    for path in plist_paths:
        try:
            if os.path.exists(path):
                with open(path, 'rb') as f:
                    data = plistlib.load(f)
                v = parse_version(data.get('KSVersion') or data.get('CFBundleShortVersionString') or '')
                if v:
                    return (path, v)
        except Exception:
            pass
    return (None, None)


def check_windows():
    reg_queries = [
        r'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        r'HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        r'HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        r'HKLM\SOFTWARE\Google\Chrome\BLBeacon',
        r'HKCU\SOFTWARE\Google\Chrome\BLBeacon',
    ]

    for key in reg_queries:
        out = run_cmd(['reg', 'query', key])
        v = parse_version(out)
        if v:
            return (key, v)
        m = re.search(r'\s+REG_SZ\s+(.+chrome\.exe)\s*$', out, re.IGNORECASE | re.MULTILINE)
        if m:
            exe = m.group(1).strip()
            out2 = run_cmd([exe, '--version'])
            v2 = parse_version(out2)
            if v2:
                return (exe, v2)

    common_paths = [
        r'C:\Program Files\Google\Chrome\Application\chrome.exe',
        r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
        os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
    ]
    for path in common_paths:
        if path and os.path.exists(path):
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                return (path, v)
    return (None, None)


def main():
    system = platform.system().lower()
    source = None
    found = None

    if system == 'linux':
        source, found = check_linux()
    elif system == 'darwin':
        source, found = check_macos()
    elif system == 'windows':
        source, found = check_windows()
    else:
        print(f'UNKNOWN: unsupported platform {platform.system()}')
        sys.exit(2)

    if not found:
        print('UNKNOWN: Chrome/Chromium version not found')
        sys.exit(2)

    if found < FIXED:
        print(f'VULNERABLE: found {version_str(found)} via {source}; fixed is {version_str(FIXED)} or newer')
        sys.exit(1)
    else:
        print(f'PATCHED: found {version_str(found)} via {source}; fixed floor is {version_str(FIXED)}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: do not burn an emergency browser campaign on this one unless you know you have flat user networks, unmanaged BYOD on corp Wi-Fi, or heavy Cast usage in shared spaces. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; fold Chrome updates into your normal browser release ring and complete vendor patching within the noisgate remediation SLA of 365 days. If a later KEV entry, public PoC, or active exploitation report appears, revisit immediately and escalate out of the normal queue.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Google Chrome Releases - Chrome for Android Update (June 2, 2026)
  3. Chromium Security
  4. Chromium issue 500075522
  5. Chrome Enterprise and Education Help - Network requirements for cast moderator
  6. FIRST EPSS
  7. FIRST API - EPSS endpoint documentation
  8. CISA Known Exploited Vulnerabilities Catalog
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.