This is the deadbolt failing after the intruder is already in the hallway
CVE-2026-11151 is an input-validation flaw in Chrome Password Manager that affects Google Chrome versions earlier than 149.0.7827.53. The authoritative record published on 2026-06-04 says exploitation requires a remote attacker to have already compromised the renderer process, then use a crafted HTML page to *potentially* turn that foothold into a sandbox escape. For defenders, that means this is not a stand-alone drive-by; it is a chainable browser post-compromise primitive.
The vendor/CISA-ADP 7.5 HIGH score captures the *possible* end impact, but it overshoots enterprise patch priority when you audit the real attack path. The decisive friction is the prerequisite renderer compromise: the attacker needs another browser bug first, plus user interaction, and there is no KEV listing, no public exploitation evidence, and a very low EPSS. That pushes this down into MEDIUM in real-world fleet prioritization, even though it remains strategically interesting to browser exploit developers.
4 steps from start to impact.
Land the user on attacker content
- User is running Chrome older than
149.0.7827.53 - User visits attacker-controlled or attacker-influenced content
- Chrome Password Manager feature set is present on the endpoint
- Requires user interaction (
UI:R) - Enterprise URL filtering, Safe Browsing, DNS filtering, and email controls often kill the lure before execution
Gain a renderer foothold with a separate bug
- A separate exploitable renderer bug is available and reliable against the target build
- The earlier exploit stage succeeds inside the browser sandbox
- This is the biggest downward-pressure factor: it assumes another exploit already worked
- Modern browser hardening, site isolation, and crash telemetry reduce reliability of chained exploitation
- EDR often sees anomalous browser child-process behavior, crash loops, or exploit mitigation events
Trigger the Password Manager weakness
- Renderer compromise from step 2 is active
- Target is still on a vulnerable Chrome build
- The attacker can drive the relevant Password Manager code path
- No public PoC currently lowers opportunistic abuse
- The affected code path may not be uniformly reachable in every browsing session or profile state
Convert browser foothold into host impact
- Successful chaining through steps 1-3
- No exploit prevention or application isolation breaking the chain
- Browser isolation, VDI reset models, and strong EDR materially reduce blast radius
- Failure at any earlier stage collapses the chain
The supporting signals.
| In-the-wild status | As of 2026-06-06, I found no KEV listing and the CISA ADP/SSVC metadata shows Exploitation: none for this CVE. |
|---|---|
| Proof-of-concept availability | I found no public PoC, no Metasploit module, and no public GitHub exploit tied to CVE-2026-11151. The Chromium issue is referenced but not publicly useful for exploit replication. |
| EPSS | 0.00047 with percentile 0.14822 on 2026-06-05 — basically background noise, not a signal of likely mass exploitation. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities catalog as of 2026-06-06. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H (7.5 HIGH). Read that as: remote delivery and high potential impact, but high complexity and user interaction required. |
| Critical prerequisite | The authoritative CVE description says the attacker must have already compromised the renderer process. That is the single biggest reason this gets downgraded in operational priority. |
| Affected versions | Google Chrome earlier than 149.0.7827.53. CERT-FR also reflects packaging nuance across desktop platforms: earlier than 149.0.7827.53 for Windows/Linux and earlier than 149.0.7827.54 for Mac. |
| Fixed versions | Patch floor is 149.0.7827.53 on desktop Chrome, with Chrome Releases and CERT-FR indicating 149.0.7827.53/.54 depending on platform packaging. |
| Scanning and exposure reality | This is client-side browser software, not a server-exposed service. Shodan/Censys-style internet exposure counts are not meaningful; you need endpoint inventory or authenticated vuln scanning to measure exposure. |
| Disclosure and attribution | Published by the Chrome CNA on 2026-06-04. No public researcher credit was visible in the sources I reviewed. |
noisgate verdict.
The decisive factor is the renderer-compromise prerequisite: this is a post-initial-compromise browser chain component, not a clean-state remote compromise path. Chrome’s footprint keeps it relevant, but the absence of active exploitation, lack of a public PoC, and very low EPSS keep it out of the HIGH bucket.
Why this verdict
- Start at 7.5 HIGH: the published CVSS assumes total impact if the chain succeeds, so the baseline is fair in a vacuum
- Major downward pressure: the attacker must have *already* compromised the Chrome renderer, which implies a prior exploit stage and makes this post-initial-access within the browser attack chain
- More friction: exploitation needs user interaction and a crafted HTML page, so this is not a silent wormable path
- No current threat signal: no KEV entry, SSVC says exploitation
none, and EPSS0.00047is extremely low - Still not low-value: Chrome is ubiquitous and sandbox-escape primitives are strategically valuable when paired with another renderer bug
Why not higher?
Because this is not a one-bug compromise from a clean browser state. Requiring a prior renderer compromise compounds friction hard: the attacker needs another exploit first, then needs this bug to extend that foothold. That sharply narrows the reachable population and raises operational complexity.
Why not lower?
Because if an attacker already has renderer execution, a sandbox-escape-capable primitive inside Chrome is still meaningful. On a fleet with lots of Chrome usage, chained browser exploitation remains a credible risk class even when opportunistic mass exploitation is unlikely.
What to do — in priority order.
- Enforce Chrome auto-update policy — Use enterprise browser policy, MDM, or software distribution to pin the fleet at
149.0.7827.53/.54or later. For a MEDIUM verdict there is no mitigation SLA, so treat this as part of the normal remediation cycle and complete it within the<=365 dayremediation window. - Prioritize high-risk user tiers — Move admins, developers, executives, and external-facing staff onto the patched build first because they are the most realistic browser exploit-chain targets. There is no mitigation SLA here, but risk-based acceleration inside the
<=365 dayremediation window is sensible. - Reduce credential exposure in-browser — Where business-tolerable, restrict browser password storage/autofill for privileged accounts and service admin workflows so a successful browser chain yields less value. For this MEDIUM verdict, use it as a defense-in-depth measure during the normal remediation window rather than as an emergency containment step.
- Hunt for browser exploit telemetry — Review EDR and browser crash telemetry for abnormal Chrome child processes, exploit mitigation events, repeated renderer crashes, and suspicious browser-originated process launches. This does not replace patching, but it is the best available control while the fleet rolls through the
<=365 dayremediation cycle.
- A WAF does not meaningfully help because the vulnerable surface is the endpoint browser, not your server-side app tier.
- A perimeter vuln scanner will miss most of the problem because Chrome is client software; you need endpoint inventory or authenticated checks.
- Network ACLs alone do not solve this if users can still browse attacker-controlled content.
Crowdsourced verification payload.
Run this on the target endpoint itself or through your RMM/EDR remote script runner. Invoke it with python3 check_chrome_cve_2026_11151.py on macOS/Linux or py check_chrome_cve_2026_11151.py on Windows; no admin rights are normally required, but the account must be able to execute Chrome and read standard install paths.
#!/usr/bin/env python3
# check_chrome_cve_2026_11151.py
# Detects whether Google Chrome is below 149.0.7827.53
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple
PATCH_FLOOR = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, ...]]:
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:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=10)
if p.returncode == 0 or p.stdout:
return p.stdout.strip()
except Exception:
pass
return None
def candidate_commands():
system = platform.system().lower()
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'])
user_mac_path = os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
if os.path.exists(user_mac_path):
cmds.append([user_mac_path, '--version'])
else:
for name in ['google-chrome', 'google-chrome-stable', '/usr/bin/google-chrome', '/opt/google/chrome/chrome']:
resolved = shutil.which(name) if not name.startswith('/') else (name if os.path.exists(name) else None)
if resolved:
cmds.append([resolved, '--version'])
return cmds
def main():
seen = []
for cmd in candidate_commands():
out = run_version(cmd)
if out:
seen.append((cmd[0], out))
ver = parse_version(out)
if ver:
if ver < PATCH_FLOOR:
print(f'VULNERABLE - {cmd[0]} reports version {".".join(map(str, ver))} which is below 149.0.7827.53')
sys.exit(1)
else:
print(f'PATCHED - {cmd[0]} reports version {".".join(map(str, ver))} which is at or above 149.0.7827.53')
sys.exit(0)
if seen:
joined = '; '.join([f'{path}: {out}' for path, out in seen])
print(f'UNKNOWN - Chrome was found but version parsing failed: {joined}')
else:
print('UNKNOWN - Google Chrome not found in standard install paths or PATH')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53 (or below 149.0.7827.54 on macOS packaging where applicable), then roll those systems through your normal browser patch channel. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for this MEDIUM verdict; with disclosure on 2026-06-04, that means documenting that there is no separate mitigation deadline and meeting the noisgate remediation SLA by patching affected managed endpoints no later than 2027-06-04. In practice, because this is Chrome and easy to update, do it in your next standard browser wave rather than letting it rot in backlog hygiene.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.