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.
4 steps from start to impact.
Land code execution in the renderer first
- Victim browses attacker-controlled or attacker-influenced content
- A separate renderer-compromise primitive already exists and works on the target build
- 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
Reach the vulnerable Chromecast code path
- Target runs a vulnerable Chrome build
- Relevant Cast/Chromecast code path is present and reachable from normal browsing context
- Restricted bug details slow opportunistic weaponization
- Not every browsing session will naturally exercise the exact lifetime sequence needed for a UAF
Convert the UAF into reliable corruption
- Predictable heap behavior on the target platform/build
- Successful grooming from renderer-controlled content
- Heap exploitation reliability varies by OS and patch level
- Browser hardening, sandboxing, and crash recovery can turn exploitation into mere browser crashes
Use the bug as a chain amplifier
- Successful memory corruption exploitation
- A path from corrupted state to meaningful post-renderer impact
- Impact is gated behind a full chain, not a single bug
- No confirmed active exploitation or turnkey public tooling lowers near-term fleet risk
The supporting signals.
| In-the-wild status | No 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 availability | No public PoC located. The backing Chromium issue is still access-restricted, which usually delays copycat weaponization. Source: Chromium issue 503617302 |
| EPSS | No 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 status | Not 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 check | CVSS: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 versions | Affected 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 versions | Upgrade 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 reporting | Publicly 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 population | Chrome 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 analog | This 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 |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue 503617302
- Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- Rapid7 historical analog - CVE-2023-5473 Cast use-after-free
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.