This is a bad spark in the browser engine, not yet a clean path to burning down the whole workstation
CVE-2026-10903 is a use-after-free in Chrome's WebRTC stack affecting desktop Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The vendor description says a remote attacker can use a crafted HTML page to achieve arbitrary code execution inside the renderer sandbox, which means the first-stage win is in the browser process, not a full host takeover by itself.
Google scored it HIGH 8.8, which is defensible if you look only at remote code execution against a massively deployed client. In real enterprise conditions, that score needs a trim: the code exec is explicitly sandboxed, there is no KEV listing, no public exploitation evidence surfaced in primary sources, and the disclosed bug details remain restricted, all of which makes this serious but not an automatic top-of-the-pile emergency.
4 steps from start to impact.
Lure the user into hostile WebRTC content
- Target is running vulnerable Chrome desktop build
- User visits attacker-controlled or attacker-influenced page
- WebRTC is available and not disabled by policy
- Requires user interaction (
UI:R), even if only a page visit - Enterprise URL filtering, browser isolation, or safe browsing can block the lure before the bug is reached
Trigger the WebRTC lifetime bug
- Reachable vulnerable WebRTC code path
- Exploit tuned to the victim's Chrome build and platform
- No public proof-of-concept was located
- Chrome memory-hardening and exploit mitigations raise the bar from crash to controlled code execution
Land code execution in the renderer sandbox
- Successful memory-corruption exploitation
- Renderer process survives long enough for post-exploitation actions
- Sandbox confinement sharply limits direct host impact
- Site isolation, process boundaries, and broker restrictions complicate data reach and follow-on actions
Chain to bigger impact or settle for browser-scoped abuse
- Valuable target workflow in browser session
- Optional second bug or trusted-path abuse for breakout
- No sandbox escape is included in this CVE
- Modern EDR, application control, and least-privilege reduce post-sandbox payoff
The supporting signals.
| In-the-wild status | No current KEV listing and no primary-source evidence of active exploitation located as of 2026-06-05. |
|---|---|
| Public PoC status | No public PoC found. The Chromium issue exists but bug details appear restricted, which is normal until patch adoption improves. |
| EPSS | 0.00071 from the user intel block; that is a very low predicted near-term exploitation probability. |
| KEV status | Not listed in CISA KEV as of 2026-06-05. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — remote and low-complexity, but it still needs user interaction. |
| Affected versions | Chrome desktop before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. |
| Fixed versions | Fixed in the Chrome 149 stable desktop rollout: 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). Android 149.0.7827.59 states it carries the corresponding desktop security fixes. |
| Exposure / scanning reality | Shodan/Censys/FOFA are basically irrelevant here. This is a client-side browser bug, so exposure measurement comes from asset inventory, EDR software inventory, Chrome Enterprise reporting, or endpoint management, not internet scanning. |
| Timeline | Bug reported to Google on 2026-04-17; stable desktop fix shipped on 2026-06-02; user-supplied disclosure date is 2026-06-04. |
| Researcher / reporter | Reported by c6eed09fc8b174b0f3eebedcceb1e792 per Google's release advisory. |
noisgate verdict.
The decisive downgrade factor is sandbox confinement: Google's own wording limits code execution to the browser sandbox, which materially cuts host-level blast radius compared with a clean workstation RCE. It still stays HIGH because this is a remote, no-auth, drive-by bug in Chrome, one of the most exposed and most widely deployed attacker-fed parsers in the enterprise.
Why this verdict
- Baseline starts high at 8.8 because the target is Chrome, the attack is remote, and delivery is just hostile web content against a ubiquitous client surface
- Downgrade for sandbox-only impact: the vendor description explicitly says code execution is *inside a sandbox*, so this is not a full-host compromise on its own
- Further downward pressure from field reality: no KEV entry, no public exploitation evidence, and an EPSS of 0.00071 argue against treating this like an actively burning browser zero-day
Why not higher?
There is no evidence here of a sandbox escape, and that matters more than the scary phrase "arbitrary code execution" when you're triaging at scale. Without in-the-wild abuse or a public weaponized chain, this is not in the same bucket as a browser bug already being chained to full compromise.
Why not lower?
Do not overcorrect just because the first-stage impact is sandboxed. A remote, unauthenticated, web-delivered memory-corruption bug in Chrome is still prime initial-access material, and Chrome's enterprise exposure population is huge enough that even moderate exploit reliability can turn into real incident volume.
What to do — in priority order.
- Force Chrome auto-update compliance — Use endpoint management or Chrome Enterprise policy to eliminate lagging builds and enforce rapid uptake of 149.0.7827.53+. For a HIGH verdict, get this control in place within 30 days if you do not already have enforced browser updating.
- Disable or restrict WebRTC where the business can tolerate it — For kiosks, task-worker pools, admin jump boxes, and other low-media-use populations, reducing WebRTC availability trims reachable attack surface. Treat this as a compensating measure to deploy within 30 days on the highest-risk user groups first.
- Put risky browsing behind isolation — Browser isolation, VDI browsing, or remote rendering for unmanaged destinations cuts exploit payoff by moving renderer compromise off the user endpoint. For a HIGH verdict, prioritize deployment to executives, admins, finance, and help desk users within 30 days.
- Alert on browser spawn-and-breakout behavior — Tune EDR detections for
chromespawning unusual children, touching credential stores, or writing suspicious binaries. This does not stop the bug, but it improves chances of catching the second-stage breakout and should be tightened within 30 days.
- A perimeter vulnerability scanner will not help; this is a client-side browser issue, not a listen-service exposure problem
- A WAF does not protect endpoints from users browsing to hostile external pages outside your app stack
- Relying on MFA alone is irrelevant to the bug itself; it may reduce account abuse after session theft, but it does not block renderer compromise
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/RMM remote script runner. Invoke it with python3 check_chrome_cve_2026_10903.py; no admin rights are usually needed, but Windows registry reads may work more consistently in a normal user context with local software inventory access.
#!/usr/bin/env python3
# Check Chrome version for CVE-2026-10903
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIXED = (149, 0, 7827, 53)
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_and_get_version(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=10)
return parse_version(p.stdout)
except Exception:
return None
def windows_candidates():
candidates = []
local = os.environ.get('LOCALAPPDATA', '')
pf = os.environ.get('PROGRAMFILES', '')
pf86 = os.environ.get('PROGRAMFILES(X86)', '')
for path in [
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
]:
if path and os.path.exists(path):
candidates.append([path, '--version'])
return candidates
def mac_candidates():
candidates = []
for path in [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]:
if os.path.exists(path):
candidates.append([path, '--version'])
return candidates
def linux_candidates():
candidates = []
for name in ['google-chrome', 'google-chrome-stable', '/opt/google/chrome/google-chrome']:
resolved = shutil.which(name) if not name.startswith('/') else (name if os.path.exists(name) else None)
if resolved:
candidates.append([resolved, '--version'])
return candidates
def get_version():
system = platform.system().lower()
if system == 'windows':
cmds = windows_candidates()
elif system == 'darwin':
cmds = mac_candidates()
else:
cmds = linux_candidates()
for cmd in cmds:
ver = run_and_get_version(cmd)
if ver:
return ver, ' '.join(cmd)
return None, None
def main():
ver, source = get_version()
if not ver:
print('UNKNOWN: Google Chrome not found or version could not be determined')
sys.exit(2)
version_str = '.'.join(str(x) for x in ver)
if ver >= FIXED:
print(f'PATCHED: detected Chrome {version_str} via {source}; fixed threshold is 149.0.7827.53+')
sys.exit(0)
else:
print(f'VULNERABLE: detected Chrome {version_str} via {source}; requires 149.0.7827.53+ (Linux) or 149.0.7827.53/54+ (Windows/macOS)')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
- Google Chrome Releases - Chrome for Android Update (June 2, 2026)
- Chromium Security Page
- Chromium issue 503422316
- Chrome Enterprise and Education release notes
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.