This is a second lock on the same door, not a front-door break-in
CVE-2026-11173 is an out-of-bounds write in V8 affecting Google Chrome versions before 149.0.7827.53; Google's May 29, 2026 early-stable release moved desktop builds to 149.0.7827.53/.54. The key detail is the prerequisite baked into the description: the attacker must already have *compromised the renderer process* before this bug becomes useful.
That makes the vendor's HIGH 8.8 look overstated for patch-priority purposes in a large enterprise. Technically, the bug may be valuable as a sandbox-escape or privilege-step inside a browser exploit chain, but operationally it is not a standalone drive-by RCE against a fully patched workstation; it requires a prior exploit stage, has no KEV entry, no public exploitation evidence in the supplied intel, and an extremely low EPSS.
4 steps from start to impact.
Land the first-stage renderer compromise
- Victim must browse attacker-controlled content or otherwise render hostile web content
- Attacker needs a separate working renderer compromise first
- This is a hard prerequisite: no initial renderer bug, no path to this CVE
- Modern browser hardening, Safe Browsing, and exploit mitigations filter out a lot of opportunistic chains
Trigger the V8 out-of-bounds write from inside the compromised renderer
- Attacker already controls execution flow or strong primitives inside the renderer
- Target is running a vulnerable Chrome build before
149.0.7827.53
- The bug adds value only after a prior compromise stage
- Exploit reliability typically varies by OS build, Chrome build, and mitigation state
Cross the sandbox boundary
- A workable post-corruption primitive is needed, not just a crash
- A reachable broker or sandbox boundary crossing path must exist
- Chromium's sandbox is specifically designed to constrain compromised renderers
- OS exploit mitigations and broker policy checks reduce the success rate of generic payloads
Run code with user-context impact
- Successful exploitation of all prior stages
- Endpoint protections do not block the final payload
- EDR, application control, and downstream privilege barriers still matter after sandbox escape
- The result is typically user-context compromise, not automatic domain-wide blast radius
The supporting signals.
| In-the-wild status | No evidence supplied of active exploitation, and not KEV-listed in CISA's catalog as reviewed. |
|---|---|
| Proof-of-concept availability | No public PoC, Metasploit module, or mainstream GitHub exploit surfaced in primary-source review. This looks like private-chain material, not commodity tradecraft. |
| EPSS | 0.0008 from the supplied intel; that is effectively near-floor probability and argues against urgent broad-sweep prioritization. |
| KEV status | Not listed in CISA KEV; no KEV added date. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — this scores like a classic remote user-interaction browser bug, but the real-world description adds a crucial hidden prerequisite: prior renderer compromise. |
| Affected versions | Google Chrome before 149.0.7827.53 per the supplied intel. |
| Fixed versions | Patch floor is 149.0.7827.53 from the supplied intel; Google's desktop early-stable post says 149.0.7827.53/.54 on Windows and Mac on 2026-05-29. |
| Exposure / scanning reality | Shodan/Censys/GreyNoise-style internet exposure data is not very meaningful here because Chrome is endpoint client software, not a server-side listener. This is an endpoint hygiene and exploit-chain problem, not an exposed-service problem. |
| Disclosure date | 2026-06-04 from the supplied intel. |
| Reporter / credit | No authoritative public reporter credit was identified in the sources reviewed. |
noisgate verdict.
The decisive factor is the attacker-position requirement: this bug only matters after the renderer is already compromised, which means it is post-initial-access inside the browser exploit chain. That sharply narrows the reachable population compared with a true standalone drive-by Chrome RCE, so it does not deserve emergency fleet-wide treatment absent exploitation evidence.
Why this verdict
- Start from the vendor's 8.8 baseline, then subtract for attacker position: this is not unauthenticated internet-to-host by itself; it requires a separate renderer compromise first, which is a major downward adjustment of roughly -2.0.
- Subtract for weak threat heat: no KEV listing, no public exploitation evidence in the supplied intel, and
EPSS 0.0008justify another -0.7. - Subtract for limited practical reach: Chrome is everywhere, but this CVE is useful mainly to attackers already building reliable multi-stage browser chains rather than opportunistic mass exploitation, which trims another -0.5.
Why not higher?
If this were a standalone remote browser RCE from a crafted page, the vendor's HIGH would be fair and maybe conservative. But the explicit need for a prior renderer compromise means the exploit chain already depends on another bug, which is exactly the kind of compounding friction that should push severity down for enterprise triage.
Why not lower?
This is still an out-of-bounds write in a massively deployed browser engine, and if it completes a chain the impact on a workstation is real. For targeted attackers who already have the first-stage renderer foothold, this kind of bug can be the difference between a harmless sandboxed crash and meaningful endpoint compromise.
What to do — in priority order.
- Enforce a Chrome version floor — Use your browser management stack, EDR software inventory, or endpoint config management to flag any Chrome build below
149.0.7827.53as noncompliant. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window and clear the long tail through normal client patch hygiene. - Kill
--no-sandboxexceptions — Audit shortcuts, app wrappers, VDI launchers, kiosk configs, and developer images for Chrome launched with--no-sandboxor similar weakened configurations. That setting removes the exact friction that keeps this CVE from being a bigger operational problem; fix it during the same standard remediation cycle. - Prefer managed browser channels only — Block unmanaged portable browsers and stale side-loaded Chrome installs so you are not chasing invisible laggards outside normal auto-update. This should be folded into standard endpoint governance during the same remediation window.
- Watch for browser exploit signals — Make sure EDR captures browser child-process anomalies, memory-protection alerts, and repeated renderer crashes. It will not prevent the bug, but it gives you the best detection chance if an attacker is actually using a chain involving this issue.
- Perimeter vulnerability scanning doesn't help much because this is endpoint client software, not an exposed server surface.
- A WAF or reverse proxy does not meaningfully mitigate a local browser-engine memory corruption bug triggered in the client.
- MFA and password rotation are good hygiene but do not block renderer-to-sandbox-escape exploit chains on the endpoint.
Crowdsourced verification payload.
Run this on the target endpoint or through your remote execution platform as a normal user; admin rights are usually not required. Save it as check_chrome_cve_2026_11173.py and run python3 check_chrome_cve_2026_11173.py on macOS/Linux or py check_chrome_cve_2026_11173.py on Windows.
#!/usr/bin/env python3
# Check for CVE-2026-11173 exposure by local Chrome version
# 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)
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def run_version(cmd):
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
return out.strip()
except Exception:
return None
def candidate_commands():
system = platform.system()
cmds = []
if system == 'Windows':
paths = [
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 p in paths:
if p and os.path.exists(p):
cmds.append([p, '--version'])
elif system == 'Darwin':
mac_path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(mac_path):
cmds.append([mac_path, '--version'])
for name in ['google-chrome', 'chrome', 'chromium', 'chromium-browser']:
found = shutil.which(name)
if found:
cmds.append([found, '--version'])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
found = shutil.which(name)
if found:
cmds.append([found, '--version'])
return cmds
def main():
seen = []
for cmd in candidate_commands():
out = run_version(cmd)
if not out:
continue
ver = parse_version(out)
if ver:
seen.append((cmd[0], ver, out))
if not seen:
print('UNKNOWN - Google Chrome executable not found or version could not be parsed')
sys.exit(2)
# Pick the highest discovered version if multiple installs exist
path, ver, raw = sorted(seen, key=lambda x: x[1], reverse=True)[0]
print(f'Detected: {path} -> {raw}')
print(f'Fixed floor: {".".join(map(str, FIXED))}')
if ver < FIXED:
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53 (and account for the desktop early-stable 149.0.7827.53/.54 release nuance on Windows/Mac), and clean up any --no-sandbox or unmanaged-browser exceptions; because this reassesses to MEDIUM with no KEV or active exploitation evidence, there is noisgate mitigation SLA — go straight to the 365-day remediation window, and complete patch rollout inside the noisgate remediation SLA of 365 days.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.