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
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. |
noisgate verdict.
The single biggest reason this lands in MEDIUM is that the reported outcome is code execution inside Chrome's sandbox, which materially cuts blast radius compared with true workstation RCE. Chrome's massive footprint keeps this from falling lower, but without exploitation evidence or a demonstrated sandbox escape, this is not a drop-everything event.
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.
What to do — in priority order.
- Force browser auto-update — Verify that enterprise Chrome update policy is functioning and that stragglers are not pinned below the fixed build. For a MEDIUM verdict there is no mitigation SLA, so use this immediately as operational hygiene while you work inside the 365-day remediation window.
- Hunt version drift — Query endpoint management, EDR, or software inventory for any host still below 149.0.7827.53/54 and for unmanaged portable/browser forks lagging behind upstream. This is the fastest way to reduce practical exposure on Monday morning when there is no formal mitigation deadline.
- Use browser isolation for high-risk users — Apply remote browser isolation or equivalent protected browsing for executives, administrators, researchers, and other high-click populations where a renderer exploit is more likely to be worth an attacker chain. Treat this as defense-in-depth rather than a substitute for patching.
- Block unmanaged Chromium variants — Enforce application control so users are not running stale Chromium-derived browsers outside your normal patch channel. This matters because attackers only need one lagging browser footprint, not your standard gold image.
- 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.
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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.