This is a burglar locked in your lobby, not loose in the server room
Per the supplied intel, this is an *inappropriate implementation in V8* in Google Chrome that lets a remote attacker execute code inside Chrome's renderer sandbox after getting a user onto malicious content. The affected range is Chrome versions before 149.0.7827.53; public release coverage around the June 2026 Chrome 149 rollout shows fixes landing at 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.
Google's HIGH 8.8 baseline is too hot for enterprise patch triage if the practical outcome is only renderer compromise. The big downgrade factor is the sandbox: a renderer RCE is a foothold, not a workstation compromise, and the attacker still needs user interaction plus a second bug or design weakness to escape containment and get to meaningful host impact.
4 steps from start to impact.
Land malicious web content
- Target is running Chrome below the fixed build
- Victim browses to attacker-controlled or attacker-influenced content
- JavaScript or the vulnerable V8 path is reachable
- Requires *user interaction* rather than blind exploitation
- Many enterprise email/web gateways block obvious lure delivery
- High-value targets often browse behind additional isolation or filtering controls
Trigger V8 bug for renderer code execution
- Exact vulnerable Chrome build and code path are present
- Exploit reliability matches the victim platform and mitigations
- No crash-only behavior; attacker needs a stable primitive
- Modern Chrome exploit chains are hard to make reliable across Windows, macOS, and Linux
- Browser hardening, compiler mitigations, and V8 exploit instability reduce success rate
- No public exploit evidence lowers the odds of broad opportunistic abuse
Operate inside the sandbox
- Renderer compromise succeeds
- Desired data is reachable from the compromised renderer context
- Enterprise extensions or browser settings do not further constrain access
- Chrome's sandbox restricts filesystem, device, and privileged browser access
- Site Isolation reduces cross-site data exposure and process sharing
- Impact is often bounded to the active browsing context unless chained further
Chain to sandbox escape or accept limited impact
- A second exploit or trust boundary bypass is available
- OS/browser mitigations do not block the escape path
- Attacker has a reason to spend a higher-end chain on this target
- This is the decisive choke point: sandbox escape is a separate and much rarer capability
- EDR, Attack Surface Reduction, and OS hardening are more likely to catch post-sandbox behavior
- Most real attackers save full browser chains for high-value targets, not broad spray-and-pray
- A WAF or perimeter IPS does not solve endpoint browser memory corruption; the exploit lands in the client, not your server edge.
- Network vulnerability scanning will not meaningfully measure exploitability here because the vulnerable surface is local browser code on user endpoints.
- Antivirus alone is weak coverage for an in-memory renderer exploit that never drops a conventional payload or child process.
The supporting signals.
| In-the-wild status | No evidence located that this CVE is actively exploited as of 2026-06-05; it is not listed in CISA KEV. |
|---|---|
| Public record status | I could not independently locate a public NVD/MITRE/Chrome entry for this exact CVE ID on June 5, 2026, so this assessment leans on the user-supplied metadata plus Chrome 149 release/fix context. |
| PoC availability | No public PoC or exploit repo found in quick public web/GitHub search as of 2026-06-05. |
| EPSS | 0.00038 from the supplied intel, which is extremely low and consistent with *no observed broad exploitation pressure*. |
| KEV status | Not KEV-listed; no CISA catalog entry found for this CVE as of 2026-06-05. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H correctly captures *remote delivery with user interaction*, but the C:H/I:H/A:H impact looks overstated if execution is inside the sandbox rather than on the host. |
| Affected versions | Per supplied intel: Chrome prior to 149.0.7827.53. Public Chrome 149 rollout material indicates fixed desktop builds at 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. |
| Fixed versions | Upgrade to 149.0.7827.53 or later; for macOS specifically, advisory rollup material references 149.0.7827.54. |
| Exposure footprint | This is not an internet-facing service, so Shodan/Censys/FOFA exposure counts are not useful. The real exposure is endpoint footprint, and Chrome remains the dominant browser, so affected population can still be very large. |
| Disclosure / reporter | Supplied disclosure date is 2026-06-04. I did not find a public reporter attribution for this exact CVE; Chrome often restricts bug details until most users are patched. |
Sources.
- Chrome Releases 2026 archive
- Chrome Early Stable Update for Desktop (149.0.7827.53/.54)
- Canadian Centre for Cyber Security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- Chromium Site Isolation overview
- Chromium Site Isolation design document
- StatCounter browser market share in the United States
Why this verdict
- Start at vendor 8.8: fair baseline for a widely deployed browser bug with remote delivery and no auth requirement
- Down for sandbox-only execution: the reported impact is renderer compromise, not direct host compromise; that is the biggest real-world severity reducer
- Down for user interaction: attacker needs the victim to browse or open hostile content, which implies a delivery step that modern mail/web controls can disrupt
- Down for no exploitation signal: no KEV entry, no public PoC found, and supplied EPSS is extremely low
- Up slightly for exposure scale: Chrome's endpoint footprint is huge, so even a bounded bug can affect a very large population
Why not higher?
Because the chain as described stops inside the sandbox. A second exploit is typically required to turn renderer code execution into host takeover, and there is no evidence in the supplied intel of a paired escape, KEV listing, or active campaign pressure.
Why not lower?
Because Chrome is everywhere, remote delivery is straightforward, and browser compromises still matter even when contained. A renderer foothold can still enable session abuse, same-context data theft, or chaining in high-value targeting scenarios, so this is not backlog fluff.
Crowdsourced verification payload.
Run this on the target endpoint itself from your EDR live response shell, software distribution tool, or a local terminal. Invoke it with python3 chrome_cve_check.py or python chrome_cve_check.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; no admin rights are required unless your environment blocks process execution from standard user context.
#!/usr/bin/env python3
# chrome_cve_check.py
# Check whether the locally installed Google Chrome version is vulnerable to
# CVE-2026-10904 based on fixed versions discussed in Chrome 149 advisories.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import argparse
import os
import platform
import re
import shutil
import subprocess
import sys
FIXED_DEFAULT = (149, 0, 7827, 53)
FIXED_MAC = (149, 0, 7827, 54)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(text):
m = VERSION_RE.search(text or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_version(binary):
try:
cp = subprocess.run([binary, '--version'], capture_output=True, text=True, timeout=10)
out = (cp.stdout or '') + ' ' + (cp.stderr or '')
return parse_version(out.strip())
except Exception:
return None
def candidate_paths():
system = platform.system()
paths = []
if system == 'Windows':
envs = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LocalAppData'),
]
suffixes = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe',
]
for base in envs:
if base:
for suffix in suffixes:
paths.append(os.path.join(base, suffix))
elif system == 'Darwin':
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
'/Applications/Chromium.app/Contents/MacOS/Chromium',
])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
resolved = shutil.which(name)
if resolved:
paths.append(resolved)
paths.extend([
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
])
# De-duplicate while preserving order
seen = set()
ordered = []
for p in paths:
if p and p not in seen:
seen.add(p)
ordered.append(p)
return ordered
def main():
ap = argparse.ArgumentParser(description='Check local Chrome version against CVE-2026-10904 fixed builds.')
ap.add_argument('--path', help='Explicit path to Chrome binary/exe', default=None)
args = ap.parse_args()
system = platform.system()
fixed = FIXED_MAC if system == 'Darwin' else FIXED_DEFAULT
paths = [args.path] if args.path else candidate_paths()
found_any = False
for path in paths:
if not path:
continue
if not os.path.exists(path) and not shutil.which(path):
continue
found_any = True
version = run_version(path)
if not version:
continue
if version < fixed:
print(f'VULNERABLE - {path} version {".".join(map(str, version))} < fixed {".".join(map(str, fixed))}')
sys.exit(1)
else:
print(f'PATCHED - {path} version {".".join(map(str, version))} >= fixed {".".join(map(str, fixed))}')
sys.exit(0)
if not found_any:
print('UNKNOWN - Chrome binary not found in common locations')
else:
print('UNKNOWN - Chrome found but version could not be determined')
sys.exit(2)
if __name__ == '__main__':
main()