This is a burglar getting into the building lobby, not the server room
The authoritative public record appears to be CVE-2026-10903, not CVE-2026-11003; as of 2026-06-05, NVD and Google both describe a use-after-free in WebRTC affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. The bug is reachable by getting a user to render attacker-controlled web content, which can drive memory corruption and achieve arbitrary code execution inside Chrome's sandboxed renderer.
Google's HIGH / 8.8 label is defensible in Chrome's own taxonomy because they rate sandboxed code execution as High. For enterprise patch triage, though, that overstates the operational blast radius: this is not a one-bug host takeover, it still needs user interaction, and there is no KEV listing, no vendor-stated in-the-wild exploitation, and a very low user-supplied EPSS value. Treat it as an important browser update, not an all-hands emergency.
4 steps from start to impact.
Land the victim on attacker-controlled content
- Unauthenticated remote attacker
- Victim uses affected Chrome version
- Victim visits attacker-controlled or attacker-influenced page
- Requires user interaction (
UI:R), not a passively exposed network service - Enterprise DNS filtering, SWG, and browser isolation can cut off many delivery paths
- Some desktops block or heavily restrict risky browsing categories
Trigger the WebRTC memory corruption
- WebRTC code path reachable from page content
- Exploit chain tailored to the target Chrome build and platform
- Modern Chrome hardening raises exploit engineering cost
- Restricted bug details mean public weaponization is not obvious yet
- Many memory corruption attempts manifest first as renderer crashes, not stable code execution
Execute code inside the renderer sandbox
- Exploit achieves reliable control of instruction flow
- Renderer sandbox remains the immediate execution context
- Sandbox containment sharply limits immediate host impact
- Site isolation and process separation reduce cross-origin blast radius
- EDR and application control have a better chance once behavior escapes normal renderer patterns
chrome renderer processes, but pure in-sandbox execution can be quiet.Convert browser foothold into useful impact
- Additional exploit or accessible high-value browser-resident data
- Target's browsing context contains something worth stealing or abusing
- No public evidence this bug ships with a paired escape
- Credential protections, HTTP-only cookies, and origin boundaries reduce simple smash-and-grab outcomes
- Enterprise browsers often run with sync, extension, and policy controls that limit abuse paths
The supporting signals.
| Record sanity check | The public authoritative record reviewed is CVE-2026-10903. I found no matching authoritative public record for CVE-2026-11003 as of 2026-06-05, so this looks like a likely transposition typo. |
|---|---|
| In-the-wild status | No public exploitation evidence found in reviewed primary sources. Google did not flag active exploitation in the release post, and CISA KEV does not list it. |
| Proof-of-concept availability | No public PoC located in reviewed sources. The Chromium issue link is access-restricted, which usually delays casual copycat weaponization. |
| EPSS | User-supplied EPSS: 0.00071; that is a very low absolute exploitation probability signal. Percentile was not independently verified from FIRST in the reviewed sources. |
| KEV status | Not listed in CISA's Known Exploited Vulnerabilities catalog as of 2026-06-05. |
| CVSS and what it really means | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H maps to an internet-deliverable bug that still needs a click/view. The big caveat is the impact is sandboxed code execution, not automatic host takeover. |
| Affected versions | Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. |
| Fixed versions | Update to 149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. I found no primary-source distro backport statement for this specific CVE in the reviewed material. |
| Scanning / exposure reality | This is client software, not an internet-facing service. Shodan/Censys/FOFA-style exposure counts are not a useful measure here, and external vuln scanners generally miss browser laggards unless they ingest endpoint inventory or EDR/MDM telemetry. |
| Disclosure / reporter | Publicly disclosed 2026-06-04 via the CVE/NVD record; Google's release post says it was reported on 2026-04-17 by c6eed09fc8b174b0f3eebedcceb1e792. |
noisgate verdict.
The decisive factor is sandbox-only execution: this bug compromises a renderer, not the endpoint, unless the attacker also has a second-stage escape or a very specific data target in-browser. That sharply narrows the practical blast radius compared with what the raw vendor CVSS suggests.
Why this verdict
- -1.4 for sandbox-only impact: Google's own severity guidance treats renderer code execution as High, but for enterprise patch prioritization a sandboxed foothold is materially less dangerous than direct host-native RCE.
- -0.6 for required victim participation: the attacker must get a user onto malicious content; this is not a remotely reachable daemon or appliance bug.
- -0.5 for weak exploitation signal: no KEV entry, no public vendor claim of active exploitation, and the supplied EPSS is extremely low.
Why not higher?
There is no public evidence of active exploitation, no KEV listing, and no indication this CVE includes a sandbox escape. If you strip away exploit-chain assumptions, the delivered impact is a contained browser-process compromise rather than immediate endpoint compromise.
Why not lower?
This is still a real memory corruption bug in a ubiquitous browser component with attacker-controlled web content as the delivery vehicle. If you run a large fleet, someone in it will hit hostile web content eventually, and browser bugs are often used as chain starters.
What to do — in priority order.
- Enforce browser auto-update — Use GPO/MDM/enterprise browser policy to ensure Chrome reaches 149.0.7827.53/.54 or later and that users cannot indefinitely defer restarts. For a MEDIUM verdict there is no mitigation SLA — use this as risk reduction while completing patching within 365 days.
- Inventory version laggards — Pull Chrome version telemetry from EDR, MDM, or software inventory and identify endpoints stuck below the fixed builds. For a MEDIUM verdict there is no mitigation SLA — focus on cleanup of unmanaged and non-updating exceptions inside the 365-day remediation window.
- Isolate risky browsing paths — Apply remote browser isolation, stricter URL filtering, or higher-friction browsing policies for high-risk users such as admins, finance, and executives. This does not replace patching, but for MEDIUM severity it is a sensible compensating layer while you work through the normal remediation cycle.
- Hunt for abnormal Chrome child-process behavior — Tune EDR for suspicious process creation, script interpreters, credential access, or unusual network activity launched from
chromerenderer trees. There is no MEDIUM mitigation SLA, so treat this as detection hardening while the fleet moves to patched builds within 365 days.
- Perimeter vulnerability scanning doesn't help much here because Chrome is client software, not an exposed service.
- MFA does not prevent memory corruption in the browser engine; it only helps on the account-abuse side after compromise.
- Generic network IPS signatures are weak coverage because exploit delivery is ordinary web content and the bug is in client-side parsing/runtime behavior.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/remote execution tool. Invoke it with python3 check_chrome_cve_2026_10903.py; it needs no admin rights for local version checks, but it must run in a user context that can read the Chrome binary paths.
#!/usr/bin/env python3
# check_chrome_cve_2026_10903.py
# Detects whether local Google Chrome is vulnerable to CVE-2026-10903
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
FIXED_LINUX = (149, 0, 7827, 53)
FIXED_WIN_MAC = (149, 0, 7827, 53) # advisory says .53/.54 for Win/Mac; .53 is acceptable floor
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_cmd(cmd):
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
return out.strip()
except Exception:
return None
def find_windows_chrome():
candidates = [
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for path in candidates:
if path and os.path.exists(path):
return path
return None
def find_macos_chrome():
path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
return path if os.path.exists(path) else None
def find_linux_chrome():
for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
p = which(name)
if p:
return p
for path in ['/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable']:
if os.path.exists(path):
return path
return None
def get_version_from_binary(path):
out = run_cmd([path, '--version'])
return parse_version(out), out
def compare(v, fixed):
if v is None:
return None
return v >= fixed
def main():
system = platform.system().lower()
chrome_path = None
fixed = None
if 'windows' in system:
chrome_path = find_windows_chrome()
fixed = FIXED_WIN_MAC
elif 'darwin' in system:
chrome_path = find_macos_chrome()
fixed = FIXED_WIN_MAC
elif 'linux' in system:
chrome_path = find_linux_chrome()
fixed = FIXED_LINUX
else:
print('UNKNOWN: unsupported platform')
sys.exit(2)
if not chrome_path:
print('UNKNOWN: Chrome binary not found')
sys.exit(2)
version, raw = get_version_from_binary(chrome_path)
if version is None:
print(f'UNKNOWN: unable to parse version from {chrome_path}')
sys.exit(2)
is_patched = compare(version, fixed)
ver_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in fixed)
if is_patched:
print(f'PATCHED: detected {ver_str} at {chrome_path} (fixed floor {fixed_str})')
sys.exit(0)
else:
print(f'VULNERABLE: detected {ver_str} at {chrome_path} (needs >= {fixed_str})')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.