This is a bad lock on one desk drawer, not a master key to the building
CVE-2026-11193 is an *insufficient policy enforcement* flaw in Chrome Password Manager. Google says Chrome versions *before* 149.0.7827.53 are affected; the stable desktop release shipped as 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS. The attack is delivered through a crafted HTML page, so the vulnerable component is the browser endpoint, not an internet-facing server.
Google's 6.5 MEDIUM is basically fair, and if anything slightly generous for enterprise prioritization. The downdraft is simple: exploitation requires a user to land on attacker content, the bug sits inside a specific feature area of the browser, and the published scoring shows *no confidentiality or integrity impact*—only availability. That makes this an endpoint hygiene problem, not an emergency incident-driver.
4 steps from start to impact.
Deliver a crafted page
- Victim uses Chrome older than
149.0.7827.53 - Attacker can get the victim to browse attacker-controlled content
- Normal web access from the endpoint is allowed
- Requires user interaction (
UI:R) - Email gateway, web filtering, Safe Browsing, and user training all cut into delivery success
- No public PoC or exploit kit lowers opportunistic abuse
Trigger Password Manager policy bypass
CWE-284 rather than memory corruption or sandbox escape.- Password Manager code path is present and reachable on the endpoint
- The vulnerable browser build has not updated
- The crafted page reaches the relevant browser state
- Many enterprises disable or de-emphasize Chrome Password Manager in favor of third-party vaults
- Managed browser policy can reduce feature availability
- Restricted bug details slow copycat exploit development
PasswordManagerEnabled policy state.Cause local browser-side impact
- Exploit reaches the vulnerable code path successfully
- Victim browser profile is the one using the affected feature
- Impact appears limited to the local browser context
- No evidence of privilege escalation, code execution, or cross-host spread
- EDR and browser restart/update can collapse persistence of the condition
Translate into business pain
- Enough users are exposed to the lure content
- Affected users rely on Chrome Password Manager or related browser credential UX
- Blast radius is per-user and per-browser profile
- No internet-facing service exposure to mass-scan
- Auto-update channels usually shrink dwell time quickly
The supporting signals.
| In-the-wild status | No public exploitation evidence found as of 2026-06-05. CISA ADP enrichment shows SSVC Exploitation: none. |
|---|---|
| Proof-of-concept availability | No public PoC located. The GitHub advisory says No known source code, and the Chromium issue remains restricted. |
| EPSS | Very low. GitHub displays 0.016% (4th percentile); the CIRCL mirror showed 0.00016 / 3.633rd percentile on 2026-06-05. Either way, attacker demand is weak. |
| KEV status | Not listed in the CISA KEV Catalog as of 2026-06-05. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H — remote delivery is possible, but only with user interaction, and the published impact is *availability-only*. |
| Affected versions | Google CNA data marks Chrome earlier than 149.0.7827.53 as affected. |
| Fixed versions | Desktop stable shipped fixes in 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. Chrome is self-packaged, so distro-style backport guidance is generally not the planning model here. |
| Exposure/scanning reality | This is an *endpoint browser* issue, so Shodan/Censys/FOFA-style internet census is largely irrelevant. You need EDR, MDM, or browser-management inventory; public internet scan telemetry is not a useful exposure proxy. |
| Disclosure timeline | Chrome stable desktop update published 2026-06-02; CVE record published 2026-06-04; GitHub advisory published 2026-06-05. |
| Researcher / reporting | Public credit is not exposed in the advisory trail I found. The Chromium issue is restricted, so reporter attribution is currently opaque. |
noisgate verdict.
The single biggest reason this stays out of HIGH is that the chain starts with user-driven browsing to attacker content and ends with an impact that the published scoring limits to availability, not credential theft or code execution. The bug lives in a broadly deployed product, but the *actual* blast radius looks local to the browser feature and user profile, not enterprise-wide compromise.
Why this verdict
- User interaction drags this down: the attacker needs a victim to load a crafted HTML page, which implies phishing, malvertising, or a compromised site rather than silent network exploitation.
- Feature scope matters: this is in *Password Manager*, and many enterprises either disable that feature or steer users into a separate enterprise vault, shrinking the reachable population.
- Published impact is not takeover-grade: the vendor/CISA-adjacent scoring is
C:N/I:N/A:H, so this is not a browser RCE, sandbox escape, or credential disclosure bug based on the evidence currently public. - Exploit demand is weak right now: no KEV listing, no public PoC found, and EPSS is extremely low.
- Exposure is endpoint-local, not server-external: there is no mass internet attack surface to sweep with commodity scanners, which sharply reduces opportunistic exploitation at scale.
Why not higher?
To justify HIGH here, I would want either *active exploitation*, a public PoC with reliable abuse, or a stronger impact class such as data theft, account compromise, or code execution. We have none of that. The chain also compounds friction: user interaction first, feature-specific reach second, then a local browser-side impact rather than an enterprise control-plane break.
Why not lower?
I am not pushing this to LOW because Chrome is everywhere and web-delivered bugs can still scale quickly once lures are in the wild. Even with weak attacker demand, a vulnerable browser fleet is a real estate problem, and the attack precondition of 'open a page' is still common enough to merit routine remediation rather than documentation-only dismissal.
What to do — in priority order.
- Enforce Chrome auto-update compliance — Make sure browser update policy is actually landing and that endpoints are not pinned behind broken rings. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browser compliance should be verified in your next normal endpoint cycle because dwell time is what turns browser bugs into incident volume.
- Audit
PasswordManagerEnabledpolicy — If your standard is to use an enterprise password vault instead of Chrome Password Manager, verify the policy is consistently disabled across managed browsers. This does not replace patching, but it can reduce reachable exposure while you work through normal remediation. - Keep Safe Browsing and web filtering on — This bug needs delivery through attacker-controlled HTML, so web-phishing controls still matter. Use them to suppress lure delivery and malicious destinations while patching proceeds under the MEDIUM 365-day remediation window.
- Use browser inventory, not network scans — Track version state with EDR, MDM, Chrome Browser Cloud Management, SCCM/Intune, or similar tooling. Internet-facing scanners will not tell you which users have vulnerable browser builds.
- A WAF does not help much; this is a client-side browser flaw triggered by rendered web content, not a server endpoint you can shield centrally.
- An IPS signature is unlikely to be dependable; there is no stable published exploit pattern and the vulnerable condition sits inside browser behavior rather than a simple network protocol primitive.
- Perimeter vulnerability scanning is the wrong instrument; Shodan/Censys-style exposure views do not inventory desktop Chrome versions in a way that drives remediation.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-inventory/EDR remote execution channel. Invoke it with python3 check_chrome_cve_2026_11193.py; no admin rights are usually needed unless your EDR wrapper requires them. The script checks common install locations on Windows, macOS, and Linux and compares the discovered browser version to the fixed baseline 149.0.7827.53.
#!/usr/bin/env python3
# check_chrome_cve_2026_11193.py
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
FIXED = (149, 0, 7827, 53)
CANDIDATES = []
SYSTEM = platform.system().lower()
if SYSTEM == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
program_files = os.environ.get('ProgramFiles', '')
program_files_x86 = os.environ.get('ProgramFiles(x86)', '')
CANDIDATES = [
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(local, 'Chromium', 'Application', 'chrome.exe'),
]
elif SYSTEM == 'darwin':
CANDIDATES = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
'/Applications/Chromium.app/Contents/MacOS/Chromium',
]
else:
CANDIDATES = [
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
'/snap/bin/chromium',
which('google-chrome') or '',
which('google-chrome-stable') or '',
which('chromium') or '',
which('chromium-browser') or '',
]
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 get_version_from_binary(path):
try:
result = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
output = (result.stdout or '') + ' ' + (result.stderr or '')
return parse_version(output)
except Exception:
return None
def compare_versions(a, b):
return (a > b) - (a < b)
seen = []
for candidate in CANDIDATES:
if candidate and os.path.exists(candidate):
ver = get_version_from_binary(candidate)
if ver:
seen.append((candidate, ver))
if not seen:
print('UNKNOWN: Chrome/Chromium binary not found in common locations')
sys.exit(2)
# Use the highest discovered version if multiple are installed.
path, version = sorted(seen, key=lambda x: x[1], reverse=True)[0]
version_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in FIXED)
if compare_versions(version, FIXED) >= 0:
print(f'PATCHED: {path} -> {version_str} (fixed baseline {fixed_str})')
sys.exit(0)
else:
print(f'VULNERABLE: {path} -> {version_str} (needs >= {fixed_str})')
sys.exit(1)
If you remember one thing.
PasswordManagerEnabled, Safe Browsing, browser inventory) to keep exposure from lingering unnoticed.Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Chromium issue tracker - issue 503642586
- GitHub Advisory Database - GHSA-cw7x-6q47-qrj7
- CIRCL Vulnerability-Lookup - CVE-2026-11193
- NVD - CVE-2026-11193
- CISA Known Exploited Vulnerabilities Catalog
- Chrome Enterprise Help - Security and privacy policies
- Chrome Enterprise Help - Set up active password detection
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.