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.
4 steps from start to impact.
Land on a reachable user segment
mdns-scan, nmap, or a custom mDNS/DNS-SD enumerator against _googlecast._tcp and Cast-adjacent ports.- 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
- 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
Reach the Cast surface
- Cast traffic is reachable across the local segment
- Ports and service discovery are not filtered
- The target host is actively running Chrome
- 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
Trigger the memory corruption
- 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
- No public PoC located
- Restricted bug details slow weaponization
- Use-after-free reliability across browser builds is rarely trivial
Convert code execution into business impact
- 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
- 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
The supporting signals.
| In-the-wild status | No public in-the-wild exploitation evidence found, and it is not listed in the CISA KEV catalog. |
|---|---|
| Proof-of-concept availability | No 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. |
| EPSS | User-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 dates | Not KEV-listed; there is no dateAdded or federal due date for this CVE in CISA's authoritative catalog. |
| CVSS vector readout | CVSS: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 versions | Supplied 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 versions | Vendor-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 reality | Google'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 timeline | Chromium 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. |
noisgate verdict.
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.
Why this verdict
- Downshift for attacker position
AV:Ais notAV: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.
What to do — in priority order.
- 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.
- 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. - 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Google Chrome Releases - Chrome for Android Update (June 2, 2026)
- Chromium Security
- Chromium issue 500075522
- Chrome Enterprise and Education Help - Network requirements for cast moderator
- FIRST EPSS
- FIRST API - EPSS endpoint documentation
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.