This is less a smashed vault than a valet key that sometimes opens the password drawer
The authoritative public record matching your description appears to be CVE-2026-11193 rather than CVE-2026-11011; it was published on 2026-06-04 and describes *insufficient policy enforcement* in Chrome Password Manager. Affected builds are Chrome before 149.0.7827.53 on Windows/Linux and, per downstream advisories, before 149.0.7827.54 on macOS, with the fix shipped in Google's May 29, 2026 early-stable release.
In real enterprise terms, this is not a perimeter-breaker. It needs a victim on a vulnerable browser to load a crafted HTML page, the impact is constrained to the local browser profile and whatever credentials or policy state are actually present there, and many mature fleets already blunt it by disabling Chrome's built-in password manager or using passwordless/SSO. That makes MEDIUM the right first-call severity even though Chrome is ubiquitous.
3 steps from start to impact.
Land a victim on attacker HTML
- Victim runs Chrome earlier than
149.0.7827.53or macOS Chrome earlier than149.0.7827.54 - User visits attacker-controlled or attacker-influenced web content
- Built-in Chrome Password Manager is present in the browsing workflow
- Requires user interaction; this is not a scan-and-hit internet service bug
- Email security, browser isolation, Safe Browsing, and web filtering can kill the lure before render
- A large chunk of enterprise users no longer rely on browser-saved passwords for high-value apps
Trigger password-manager policy bypass
- The vulnerable code path is reachable in that browser/profile state
- Relevant credentials or password-manager features are actually enabled for the user
- Many orgs disable
PasswordManagerEnabledor discourage storing enterprise secrets in Chrome - Password-manager blocklists for sensitive domains reduce reachable blast radius
- Users on federated SSO/passkeys reduce credential value even if the policy boundary is bypassed
Turn local browser access into credential value
- Victim has stored passwords or related password-manager state worth abusing
- Targeted accounts are not fully protected by phishing-resistant MFA or passkeys
- Blast radius is typically one user profile at a time
- No evidence this flaw trivially scales to tenant-wide compromise
- Account protections at the IdP layer can still break post-browser abuse
The supporting signals.
| Identifier reconciliation | The public record matching the supplied title is CVE-2026-11193, published 2026-06-04. I found no authoritative Chrome record for CVE-2026-11011 matching this description. |
|---|---|
| In-the-wild status | No evidence found of active exploitation. It is not listed in CISA KEV as of this assessment. |
| Public PoC availability | No public PoC located in the sources reviewed; the Chromium bug link is non-public, which keeps the exploit recipe opaque for now. |
| EPSS | 0.00016 (3.633 percentile), which is effectively background noise rather than 'attackers will dogpile this next week' territory. |
| KEV status | Not in KEV. No KEV add date, no federal patch deadline override. |
| Vendor severity note | Chrome labels it 'Chromium security severity: Medium' in the CNA description, but Chrome did not publish a vendor CVSS base score. |
| Authority CVSS note | A CISA-ADP/NVD secondary vector now exists: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H = 6.5 MEDIUM. I still treat this verdict as ASSESSED AT MEDIUM because there is no Chrome vendor CVSS baseline to compare against. |
| Affected versions | Chrome before 149.0.7827.53 per CNA/NVD data; downstream advisories indicate macOS fixed at 149.0.7827.54. |
| Fixed versions | Desktop early-stable fix shipped 2026-05-29: 149.0.7827.53/.54 for Windows and Mac. For fleet ops, treat anything older than 149.0.7827.53 as suspect, and on macOS require 149.0.7827.54+. |
| Scanning / exposure reality | No meaningful Shodan/Censys/GreyNoise exposure story here because this is a client-side browser flaw, not an internet-listening service. Your exposure is the count of managed Chrome endpoints and the subset still using the built-in password manager for valuable accounts. |
| Disclosure / reporter | Published by the Chrome CNA on 2026-06-04; public source names the vendor and bug reference, but the specific reporter is not disclosed in the materials reviewed. |
noisgate verdict.
The decisive friction is that this bug lives entirely in the client browser workflow and requires a victim to render attacker HTML before anything happens. Even then, impact is gated by whether the user actually stores valuable credentials in Chrome, which sharply narrows real blast radius compared with server-side auth bypasses or browser RCEs.
Why this verdict
- User interaction is mandatory: attacker position is unauthenticated remote, but only after the victim loads crafted HTML. That immediately pushes this below wormable or perimeter-exposed classes.
- It is post-click and profile-scoped: the prerequisite implies a single-user browser session, not broad network reach. Real deployments compound that friction with web filtering, browser isolation, and Safe Browsing.
- Enterprise password storage habits matter: if
PasswordManagerEnabledis off, sensitive domains are blocklisted, or users rely on SSO/passkeys, the reachable population and resulting value drop materially. - No exploitation evidence: no KEV listing, no active-campaign reporting, and EPSS is extremely low. That keeps urgency in the routine-browser-patching lane instead of incident-response lane.
- Wide deployment keeps it from being LOW: Chrome is everywhere, so even a non-RCE password-manager boundary failure deserves attention once you verify vulnerable builds are present.
Why not higher?
There is no sign of active exploitation, no public exploit recipe in the reviewed sources, and no indication this jumps from one browser profile to broad enterprise compromise. Most importantly, the attacker must first win a lure and then find stored credentials or exploitable password-manager state on that specific endpoint.
Why not lower?
This still touches credential-handling logic inside one of the most widely deployed enterprise clients on earth. If you do allow Chrome's built-in password manager for workforce accounts, the flaw can undermine a policy boundary protecting exactly the data defenders care about.
What to do — in priority order.
- Disable Chrome password saving where business-acceptable — Set
PasswordManagerEnabled=falsefor managed browsers that do not need Chrome's built-in password store. For a MEDIUM verdict there is no mitigation SLA, so this is optional risk reduction rather than an emergency change; use it for higher-risk user groups and shared-workstation populations. - Block Password Manager on crown-jewel domains — Use
PasswordManagerBlocklistfor IdP, admin, finance, and privileged application domains so Chrome does not save/fill credentials there. There is no mitigation SLA for MEDIUM, but this is a sensible control during normal policy maintenance if your users still store browser passwords. - Prefer passkeys or phishing-resistant MFA — Shift high-value apps away from reusable passwords so a browser-side password-manager flaw has less to steal or misuse. There is no mitigation SLA for MEDIUM; align this with your identity hardening roadmap rather than treat it as a one-off CVE action.
- Use browser version reporting aggressively — Pull a versions report from the Admin console or endpoint tooling and isolate all Chrome builds below the fixed floor. For MEDIUM there is no mitigation SLA, but precise version visibility is what keeps this from becoming a blind spot in a 10,000-host fleet.
- A WAF does not help; there is no vulnerable enterprise web service to shield here.
- Network vulnerability scanners only find outdated versions; they cannot tell you whether a given user profile stores passwords or whether the vulnerable policy path is actually reachable.
- MFA alone is not a complete answer if browser-stored passwords still unlock low-friction sessions, legacy apps, or downstream tokens.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR/remote execution framework as the logged-in user or a standard local account; admin rights are not required in most cases. Example: python3 check_chrome_cve_2026_11193.py on macOS/Linux or py check_chrome_cve_2026_11193.py on Windows. It checks local Google Chrome version and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_11193.py
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / Chrome not found / parse failure
import os
import platform
import re
import subprocess
import sys
from pathlib import Path
WIN_MIN = (149, 0, 7827, 53)
LINUX_MIN = (149, 0, 7827, 53)
MAC_MIN = (149, 0, 7827, 54)
def parse_ver(s):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s 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 or p.stderr).strip()
except Exception:
pass
return None
def get_windows_version():
candidates = [
Path(os.environ.get('ProgramFiles', r'C:\Program Files')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)')) / 'Google/Chrome/Application/chrome.exe',
Path(os.environ.get('LocalAppData', '')) / 'Google/Chrome/Application/chrome.exe',
]
for exe in candidates:
if exe.exists():
cmd = [
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{str(exe)}').VersionInfo.ProductVersion"
]
out = run_cmd(cmd)
if out:
return out, str(exe)
return None, None
def get_macos_version():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for exe in candidates:
if Path(exe).exists():
out = run_cmd([exe, '--version'])
if out:
return out, exe
return None, None
def get_linux_version():
cmds = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['/opt/google/chrome/chrome', '--version'],
]
for cmd in cmds:
out = run_cmd(cmd)
if out:
return out, cmd[0]
return None, None
def main():
system = platform.system().lower()
if 'windows' in system:
raw, source = get_windows_version()
min_ver = WIN_MIN
platform_name = 'Windows'
elif 'darwin' in system:
raw, source = get_macos_version()
min_ver = MAC_MIN
platform_name = 'macOS'
elif 'linux' in system:
raw, source = get_linux_version()
min_ver = LINUX_MIN
platform_name = 'Linux'
else:
print('UNKNOWN: unsupported platform')
sys.exit(2)
if not raw:
print(f'UNKNOWN: Google Chrome not found on {platform_name}')
sys.exit(2)
ver = parse_ver(raw)
if not ver:
print(f'UNKNOWN: could not parse Chrome version from: {raw}')
sys.exit(2)
if cmp_ver(ver, min_ver) < 0:
print(f'VULNERABLE: {platform_name} Chrome {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} found at {source}; requires >= {min_ver[0]}.{min_ver[1]}.{min_ver[2]}.{min_ver[3]}')
sys.exit(1)
else:
print(f'PATCHED: {platform_name} Chrome {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} found at {source}; meets >= {min_ver[0]}.{min_ver[1]}.{min_ver[2]}.{min_ver[3]}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome stable channel desktop advisory
- CVE-2026-11193 aggregation with CNA, EPSS, CWE, and CISA-ADP details
- CISA Known Exploited Vulnerabilities Catalog
- Chrome Enterprise policy: PasswordManagerEnabled
- Chrome Enterprise policy: PasswordManagerBlocklist
- Google Chrome Help: Update Google Chrome
- Chrome Enterprise Admin help: View Chrome version details
- CERT-FR advisory covering affected desktop version floors
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.