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
- 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.
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 |
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
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.
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()