This is a hidden door inside a house key you already should not have handed out
CVE-2026-11157 is a UXSS/script-injection flaw in Chrome Accessibility affecting Google Chrome before 149.0.7827.53. The attack does not start from a website alone: the attacker must first convince the user to install a malicious Chrome extension, after which the crafted extension can inject arbitrary scripts or HTML through the Accessibility component.
Google's Medium 5.4 label is directionally fair in a vacuum, but for enterprise patch triage this lands lower in practice. The decisive friction is the prerequisite chain: user interaction + malicious extension installation + browser-side execution. In managed fleets that already restrict extension installs, the reachable population collapses fast; in unmanaged fleets, the extension problem is the bigger risk than this individual bug.
4 steps from start to impact.
Land a malicious extension
- User can install extensions or policy allows the specific extension
- Attacker can socially engineer the user or control an extension supply-chain path
- Chrome version is older than 149.0.7827.53
- Managed Chrome commonly blocks or allowlists extensions
- Users still see install prompts and trust indicators
- Security teams often monitor new extension installs on managed endpoints
Trigger Accessibility UXSS path
- Extension executes in the victim browser
- Victim browses content/context the attacker wants to influence
- The vulnerable code path in Accessibility is reachable from the extension
- Bug details are typically restricted until patch adoption rises
- Some extension permission models and site-access scoping may still constrain impact
- Browser restarts and extension review/removal break persistence
Use injected script for browser-layer abuse
- Victim accesses targeted web apps
- Injected content can run in the relevant page context
- Session cookies or sensitive workflows are present
- MFA, conditional access, and re-auth challenges reduce session abuse value
- HttpOnly cookies and app-side anti-CSRF controls still matter
- EDR/browser protection can flag suspicious extension-driven behavior
Escalate through stolen sessions or user trust
- The attacker can monetize or reuse stolen browser context
- The extension remains installed long enough to act
- Targeted SaaS sessions are valuable
- Per-user scope limits immediate enterprise-wide blast radius
- SOC can respond by revoking sessions and removing the extension
- Managed profile resets and browser policy refreshes contain spread
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in reviewed sources as of 2026-06-05. |
|---|---|
| KEV status | Not listed in CISA KEV as of 2026-06-05 (CISA KEV). |
| PoC availability | No public PoC located in primary sources reviewed; Chromium issue details are typically restricted until patch uptake improves. |
| EPSS | 0.00013 (very low), which matches the heavy prerequisite chain and lack of observed exploitation in current reporting. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N — the score assumes network reachability, but the real-world gate is extension installation by the victim. |
| Affected versions | Google Chrome before 149.0.7827.53 on desktop platforms; Chrome release materials show 149.0.7827.53/.54 for Windows/macOS early stable and 149.0.7827.53 for Linux-related testing artifacts. |
| Fixed version | 149.0.7827.53 (Linux / baseline fix) and 149.0.7827.53/.54 for Windows and macOS early stable rollout references. |
| Exposure reality | Not internet-enumerable. Shodan/Censys/FOFA-style exposure data is mostly irrelevant because this is a client-side browser bug, not a remotely scanned service. |
| Disclosure date | 2026-06-04 in the published CVE record aggregation reviewed. |
| Researcher / reporting | Public sources reviewed credit the Chrome CNA / Chromium issue tracker; no external researcher attribution was exposed in the accessible primary references. |
noisgate verdict.
The single biggest severity suppressor is that exploitation requires the victim to install a malicious extension first. That makes this a post-governance browser trust failure, not a clean unauthenticated remote compromise path, and sharply narrows both reachable population and immediate blast radius.
Why this verdict
- Downgraded for attacker position: despite the
AV:Nvector, the attacker effectively needs user-enabled code execution inside the browser via a malicious extension. - Downgraded for exposure population: managed enterprise Chrome deployments often block or allowlist extensions, so only a subset of fleets are realistically exposed.
- Downgraded for blast radius: the immediate impact is usually per-user browser/session abuse, not instant fleet-wide compromise or server-side takeover.
Why not higher?
This is not a drive-by web exploit and not a clean pre-auth remote code execution path. The attack chain assumes a prior governance failure around extension installation, which is strong downward pressure on enterprise priority.
Why not lower?
It is still a real trust-boundary break in a massively deployed browser, and malicious extensions are a proven attacker vehicle. In environments that allow user-installed extensions, this bug can amplify an otherwise constrained extension into more dangerous page-level abuse.
What to do — in priority order.
- Allowlist extensions only — If you manage Chrome, move users to an approved-extension-only model using enterprise policy. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is the highest-value control because it kills the prerequisite the CVE depends on.
- Block high-risk permissions — Use Chrome app/extension policy controls to block or restrict extensions requesting broad site access and sensitive permissions. For a LOW verdict there is no SLA (treat as backlog hygiene); implement as part of normal browser-governance hardening.
- Review newly installed extensions — Hunt for recent installs, especially consumer productivity tools, AI helpers, coupon/shopping extensions, and force-installed third-party helpers. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is the fastest way to cut practical risk while patching rolls through normal channels.
- Enable user request workflows — Require users to request extensions through admin approval instead of self-installing from the store. For a LOW verdict there is no SLA (treat as backlog hygiene); this turns extension risk from an endpoint problem into a governed change-control problem.
- Network perimeter controls don't help much; this is executed inside the browser after extension installation, not through an exposed server port.
- WAF rules are mostly irrelevant because the exploit primitive lives in the local browser/extension trust boundary.
- MFA alone reduces downstream session abuse but does not stop malicious DOM/script injection in the browser session already running on the endpoint.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke with python3 chrome_cve_2026_11157_check.py on macOS/Linux or py chrome_cve_2026_11157_check.py on Windows; standard user rights are usually enough, though Windows registry access may be easier with normal desktop-user context than with locked-down service accounts.
#!/usr/bin/env python3
# CVE-2026-11157 local exposure check for Google Chrome
# Checks installed Chrome version against fixed version 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
FIXED = (149, 0, 7827, 53)
def parse_version(text):
if not text:
return None
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_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def get_windows_version():
candidates = [
[r'reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
[r'reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
]
for cmd in candidates:
out = run_cmd(cmd)
ver = parse_version(out)
if ver:
return ver, out
exe_paths = [
r'C:\Program Files\Google\Chrome\Application\chrome.exe',
r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
]
for path in exe_paths:
if path and os.path.exists(path):
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return ver, out
return None, ''
def get_macos_version():
path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(path):
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return ver, out
plist = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(plist):
out = run_cmd(['/usr/bin/defaults', 'read', plist, 'KSVersion'])
ver = parse_version(out)
if ver:
return ver, out
return None, ''
def get_linux_version():
cmds = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in cmds:
out = run_cmd(cmd)
ver = parse_version(out)
if ver:
return ver, out
return None, ''
def compare_versions(a, b):
return (a > b) - (a < b)
def main():
system = platform.system().lower()
if 'windows' in system:
ver, raw = get_windows_version()
elif 'darwin' in system:
ver, raw = get_macos_version()
elif 'linux' in system:
ver, raw = get_linux_version()
else:
print('UNKNOWN - Unsupported OS: {}'.format(platform.system()))
sys.exit(2)
if not ver:
print('UNKNOWN - Google Chrome version not found')
sys.exit(2)
ver_str = '.'.join(str(x) for x in ver)
fixed_str = '.'.join(str(x) for x in FIXED)
if compare_versions(ver, FIXED) < 0:
print('VULNERABLE - Installed Chrome version {} is older than fixed version {}'.format(ver_str, fixed_str))
sys.exit(1)
else:
print('PATCHED - Installed Chrome version {} is at or above fixed version {}'.format(ver_str, fixed_str))
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Chrome Releases: Early Stable Update for Desktop (May 29, 2026)
- Vulnerability-Lookup entry for CVE-2026-11157
- CISA Known Exploited Vulnerabilities Catalog
- Managing Extensions in Your Enterprise
- Chrome app and extension policies
- Install and manage extensions
- Chrome for Testing availability
- Chrome Enterprise previous release notes
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.