This is a cracked windshield in a moving car, not a missing front axle
CVE-2026-11191 is an out-of-bounds memory access bug in ANGLE, Chrome's graphics translation layer, reachable by getting a user to render attacker-controlled web content. The authoritative affected range is Google Chrome before 149.0.7827.53 on Linux and Windows, and before 149.0.7827.54 on Mac, based on Google's June 2, 2026 stable release and the earlier May 29, 2026 early-stable push.
The vendor baseline of 8.8/HIGH overstates enterprise urgency. In practice this is a client-side, user-driven, single-bug browser memory issue with no KEV listing, no confirmed in-the-wild exploitation, no public PoC, and an important vendor-side tell: Google itself labeled the bug's Chromium security severity as Medium. The big downward pressure is that a lone browser renderer/GPU bug usually needs a second-stage primitive or sandbox escape to become an estate-wide emergency.
4 steps from start to impact.
Land the victim on malicious content
- Victim is running Chrome below 149.0.7827.53/54
- Victim visits attacker-controlled or attacker-influenced web content
- Relevant graphics path is reachable in that browser session
- Requires user interaction
- Email/web filtering and safe browsing controls can break delivery
- Not an unauthenticated hit-against-a-server condition
Trigger ANGLE memory misuse
- ANGLE code path must be exercised
- Attacker can shape inputs enough to hit the vulnerable condition
- Bug details remain restricted in Google's tracker
- No public PoC lowers copycat risk
- Exploit reliability across GPU drivers and OS variants is usually messy
Turn memory corruption into useful control
- Primitive is strong enough for control rather than only crash
- Target-specific exploit reliability is achieved
- Many browser memory bugs die as crashes
- Modern mitigations and partitioning reduce exploit reliability
- The CNA wording says 'potentially' perform out-of-bounds access, which is weaker than confirmed RCE language
Escape browser containment for real host impact
- Successful post-corruption execution in a constrained browser process
- A sandbox bypass, broker abuse, or second bug if host-level compromise is desired
- This CVE by itself is not described as a sandbox escape
- Browser process isolation is a major real-world severity brake
- No evidence of an active exploit chain paired with this bug
The supporting signals.
| In-the-wild status | No public exploitation evidence found. Not in CISA KEV, and Google did not flag it as exploited in the release notes. |
|---|---|
| Proof-of-concept availability | No public PoC located. Google's issue is still referenced but details may remain restricted until most users are patched, which meaningfully slows copycat weaponization. |
| EPSS | Low signal. Prompt supplied 0.00068; CIRCL's June 5, 2026 mirror shows 0.00035 / 10.8th percentile, so either way this sits in the *very low* exploit-likelihood bucket. |
| KEV status | Not KEV-listed as of June 2026. That removes the strongest urgency override. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = remotely triggerable through web content, but user interaction is required and the vector assumes full CIA impact that is not proven by the published bug details. |
| Vendor/CNA characterization | Important nuance: the CVE text says '(Chromium security severity: Medium)' even though NVD/CISA ADP score it 8.8 High. For browser bugs, I trust the product team's component-level severity signal more than the generic CVSS math. |
| Affected versions | Chrome <149.0.7827.53 broadly, with Google's desktop stable note calling out 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/Mac. |
| Fixed versions | Fixed in 149.0.7827.53 for Linux/Windows and 149.0.7827.54 for Mac. There is no distro-style backport story here; this is a browser-channel update. |
| Scanning/exposure reality | This is a client-side browser flaw, so Shodan/Censys/FOFA-style internet exposure counts are basically *not applicable*. Your exposure is your managed endpoint population, not a public-facing service footprint. |
| Disclosure and reporter | Published 2026-06-04 in the CVE record; Google's stable desktop advisory shipped 2026-06-02 and lists the bug as reported by Google on 2026-04-16 under issue 503392431. |
noisgate verdict.
The decisive brake is containment: this is a user-driven browser memory bug with no evidence that the single CVE escapes Chrome's sandbox or reliably delivers host compromise on its own. Wide deployment keeps it relevant, but absent exploitation evidence or a proven exploit chain, it does not justify a HIGH-priority incident response posture.
Why this verdict
- Vendor 8.8 starts too high for reality because CVSS gives full CIA credit, while the published record only confirms out-of-bounds access in a browser component and Google's own Chromium severity says *Medium*.
- Requires user interaction: the attacker cannot just hit an internet-facing service; they must get a victim to render malicious web content, which means phishing, malvertising, or site compromise first.
- Sandbox/process isolation is the main downward adjustment: to turn a browser-process memory bug into full endpoint compromise, the attacker usually needs a second bug or escape stage that is not part of this CVE.
- No exploitation signal: no KEV listing, no public campaign reporting, no exploit kit chatter surfaced, and no public PoC materially reduce short-term operational risk.
- Population is huge but blast radius per trigger is local: yes, Chrome is everywhere, but exploitation is one-user-at-a-time, not one-packet-to-10,000-hosts.
Why not higher?
There is no evidence this CVE alone provides a clean path to host takeover, domain impact, or wormable propagation. The combination of required user interaction, absent public weaponization, and likely sandbox containment keeps this out of HIGH territory.
Why not lower?
It is still a remotely reachable browser memory-safety flaw in a ubiquitous enterprise application. If a user visits hostile content on an unpatched build, the bug is reachable, and memory bugs in browser graphics code are never noise-level backlog items.
What to do — in priority order.
- Enforce browser auto-update — Make sure enterprise policy forces Chrome to update and relaunch so vulnerable builds age out quickly. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice you should let normal browser update controls do the work now rather than waiting for an annual cleanup cycle.
- Prefer browser isolation for high-risk users — Put admins, finance, executives, and help-desk staff behind remote/browser isolation for unknown sites and email-delivered links. There is no mitigation SLA for MEDIUM here, so use this as a targeted exposure reducer until patched versions are universal inside the remediation window.
- Harden risky web content paths — Use secure web gateway policy, Safe Browsing, attachment detonation, and ad/tracker filtering to cut down delivery of hostile pages that would need to trigger the bug. This matters because the first real friction point is getting a user onto attacker-controlled content.
- Watch for browser crash anomalies — Trend Chrome renderer/GPU-process crashes and exploit-protection events in EDR/SIEM, especially after suspicious link clicks or on high-risk user groups. This will not prove exploitation, but it can surface attempted trigger activity while patch compliance catches up.
- A WAF does not help because the vulnerable asset is the client browser, not your server.
- Perimeter port scanning reduction is irrelevant; there is no exposed listener to close.
- Generic network IDS signatures are weak here because the exploit would be embedded in normal-looking web content and browser rendering behavior.
- Disabling Chrome entirely is not a realistic control for most enterprises and just shifts users to another browser with its own patch burden.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/EDR execution framework. Invoke it as python3 chrome_cve_2026_11191_check.py on macOS/Linux or py chrome_cve_2026_11191_check.py on Windows; standard user rights are usually enough because it only reads local version metadata.
#!/usr/bin/env python3
# CVE-2026-11191 Chrome version check
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
TARGET = (149, 0, 7827, 53)
MAC_TARGET = (149, 0, 7827, 54)
def norm(v):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', v or '')
return tuple(int(x) for x in m.groups()) if m else None
def cmp_ver(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
if p.returncode == 0:
return p.stdout.strip() or p.stderr.strip()
except Exception:
pass
return None
def candidates_windows():
local = os.environ.get('LOCALAPPDATA', '')
pf = os.environ.get('ProgramFiles', '')
pfx86 = os.environ.get('ProgramFiles(x86)', '')
return [
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(local, 'Chromium', 'Application', 'chrome.exe'),
os.path.join(pf, 'Chromium', 'Application', 'chrome.exe'),
os.path.join(pfx86, 'Chromium', 'Application', 'chrome.exe'),
]
def candidates_macos():
return [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium'),
]
def candidates_linux():
paths = []
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
p = which(name)
if p:
paths.append(p)
paths += [
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
'/snap/bin/chromium',
]
return paths
def get_version_from_binary(path):
if not path or not os.path.exists(path):
return None
out = run_cmd([path, '--version'])
if out:
return norm(out)
return None
def get_version_windows_ps(path):
if not path or not os.path.exists(path):
return None
ps = which('powershell') or which('pwsh')
if not ps:
return None
cmd = [ps, '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"]
out = run_cmd(cmd)
return norm(out) if out else None
def find_installed_version():
sysname = platform.system()
if sysname == 'Windows':
for p in candidates_windows():
v = get_version_windows_ps(p) or get_version_from_binary(p)
if v:
return ('Windows', p, v)
elif sysname == 'Darwin':
for p in candidates_macos():
v = get_version_from_binary(p)
if v:
return ('Darwin', p, v)
else:
for p in candidates_linux():
v = get_version_from_binary(p)
if v:
return ('Linux', p, v)
return (sysname, None, None)
def main():
sysname, path, version = find_installed_version()
if not version:
print('UNKNOWN')
print(f'platform={sysname} reason=chrome_not_found_or_version_unreadable')
sys.exit(2)
fixed = MAC_TARGET if sysname == 'Darwin' else TARGET
status = 'PATCHED' if cmp_ver(version, fixed) >= 0 else 'VULNERABLE'
print(status)
print(f'platform={sysname} path={path} version={".".join(map(str, version))} fixed={".".join(map(str, fixed))}')
if status == 'PATCHED':
sys.exit(0)
else:
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.