Like a fake bank teller window built inside the real branch lobby
CVE-2026-11031 is an input-validation flaw in Chrome Password Manager that can let a remote attacker spoof trusted browser UI. The affected range is Google Chrome prior to 149.0.7827.53; Google's early stable desktop release notes show 149.0.7827.53/.54 as the fix train for Windows and Mac, and enterprises should use endpoint inventory to confirm the exact rollout state across their fleet.
Google's MEDIUM 4.3 baseline is defensible on paper, but in real operations this lands lower. The attacker still needs the victim in front of a malicious page and needs the bug to successfully convert that moment into a believable fake password-manager interaction; the flaw does not by itself give code execution, sandbox escape, or direct credential extraction from Chrome.
4 steps from start to impact.
Land the user on attacker-controlled web content
- Victim runs Chrome older than 149.0.7827.53
- Victim can browse to attacker-controlled content
- Attacker can deliver normal HTTPS web content
- Requires user interaction by definition
- Secure web gateways, URL filtering, and Safe Browsing can kill the path before the bug matters
- Managed Chrome fleets often auto-update quickly, shrinking the reachable population
Trigger spoofed Password Manager UI
- The vulnerable code path in Password Manager is reachable from rendered content
- The browser is on an affected build
- The spoof is convincing enough in the user's environment
- No public exploit kit or broadly circulated PoC was found
- UI spoofing bugs are fragile across DPI, themes, language packs, and UX changes
- Password-manager re-auth prompts or profile separation can break the illusion
Exploit user trust, not the kernel
- User believes the spoofed UI is genuine
- User takes the requested action
- Enterprise controls do not require separate re-authentication
- MFA and passwordless flows reduce payoff from harvested credentials
- Many enterprise password managers require OS or profile re-auth for sensitive actions
- User confusion does not guarantee credential capture or durable compromise
Convert deception into low-grade impact
- Attacker has an external collection point or follow-on phishing flow
- Victim action creates something useful to the attacker
- Impact is capped: no direct code exec, no sandbox break, no stated confidentiality loss from the vuln itself
- Any useful outcome often depends on additional social engineering or a second-stage phish
The supporting signals.
| In-the-wild status | No known active exploitation evidence in the supplied intel and not KEV-listed. This matters because client-side Chrome bugs that are actually burning tend to show up fast in KEV or public incident reporting. |
|---|---|
| Public PoC availability | No public PoC or exploit kit located in common public tracking during this review. That is not proof of safety, but it lowers immediate weaponization pressure. |
| EPSS | 0.00047 from the user-supplied intel, which is extremely low. FIRST EPSS is the right directional input here: expected exploitation pressure is near the floor. |
| KEV status | Not listed in CISA KEV as of 2026-06-06. For patch triage, that keeps this out of the 'within hours' lane. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N maps to remote delivery but mandatory user interaction, low integrity-only impact, and no confidentiality or availability loss. |
| Affected versions | Google Chrome before 149.0.7827.53. Because Chrome is evergreen, the real exposure question is not install base but version drift inside managed endpoints. |
| Fixed versions | Google's early stable release notes show 149.0.7827.53/.54 for Windows and Mac. Treat distro/browser repackaging separately and verify the embedded Chromium level before closing exceptions. |
| Exposure and scanning reality | Shodan/Censys/GreyNoise are weak fit for this CVE because it is a client-side browser/UI bug, not an internet-facing daemon. Your reliable coverage is EDR, software inventory, browser management telemetry, and package/version compliance. |
| Disclosure | 2026-06-04 per the supplied intel, with Google's desktop early-stable fix train published 2026-05-29. |
| Researcher / reporting attribution | No public researcher attribution located in the release note used here. That is common for Chrome batch releases when the public issue stays sparse or non-public. |
noisgate verdict.
The decisive factor is the impact ceiling: this is a UI-spoofing/phishing-assist bug, not a browser-compromise bug. Even though delivery is remote, the path still depends on user trust and produces only low-integrity impact from the vulnerability itself.
Why this verdict
- [object Object]
- Start at vendor 4.3: Chrome is broadly deployed and the bug is reachable through normal web content, so the vendor baseline is not crazy as a starting point.
- Down for attacker position and prerequisite chain: This is unauthenticated remote delivery, but it implies successful phishing or malicious-site traffic plus user interaction. That compounds downward pressure because the attacker does not get impact just by sending packets.
- Down for impact ceiling: The vector already tells the story:
C:N/I:L/A:N. No direct credential dump, no code execution, no sandbox escape, no durable browser takeover. - Down for real-world population control: Modern enterprise Chrome fleets auto-update, and browser version drift is usually measured in days, not quarters. That sharply limits the long-tail exposed population compared with server-side CVEs.
Why not higher?
It is not higher because the attacker must win a human-interaction step and then still only gets a deception primitive. There is no evidence here of active exploitation, no public PoC pressure, and no technical path from this CVE alone to host compromise or password vault exfiltration.
Why not lower?
It is not IGNORE because browsers are high-frequency attack surfaces and UI spoofing against password-manager trust can still fuel credential theft. If you have lagging Chrome updates or high-risk user populations, the bug is worth cleaning up in normal patch hygiene rather than dismissing outright.
What to do — in priority order.
- Enforce Chrome auto-update — Make sure managed endpoints cannot sit behind the fixed build line; for a LOW verdict there is no mitigation SLA and no hard remediation SLA, so handle this as backlog hygiene in your normal browser evergreen process.
- Require re-auth for password reveal/fill where available — OS- or profile-level re-auth weakens the value of spoofed password-manager UI because the attacker must now mimic an additional trust boundary. Roll this into your standard hardening baseline; again, no mitigation SLA applies for LOW.
- Tighten web filtering for newly seen or low-reputation domains — This bug still needs a hostile page, so killing first-stage delivery matters more than trying to signature the browser flaw. Apply through your existing SWG/DNS controls as part of routine hygiene.
- Watch version drift, not perimeter scans — Use endpoint inventory, browser management, or EDR software census to find Chrome versions below
149.0.7827.53. That gives you actionable exposure data; internet scanners do not.
- A WAF does not help much because the victim is the browser client rendering attacker-controlled web content over ordinary HTTPS.
- Internet exposure scanning is the wrong lens; there is no server port to fingerprint for this client-side flaw.
- User awareness training alone is not a control boundary. It may reduce success rate, but it does not remove the vulnerable trusted-UI confusion path.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-inventory agent, not from a remote auditor box. Invoke with python3 check_chrome_cve_2026_11031.py on macOS/Linux or py check_chrome_cve_2026_11031.py on Windows; standard user rights are usually enough because it only reads local version data.
#!/usr/bin/env python3
# Check exposure to CVE-2026-11031 by Google Chrome version.
# Fixed version baseline: 149.0.7827.53
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# 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 cmp_ver(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
out = subprocess.check_output(cmd, stderr=subprocess.DEVNULL, text=True).strip()
return out
except Exception:
return None
def detect_windows():
candidates = []
try:
import winreg # type: ignore
reg_paths = [
r'SOFTWARE\\Google\\Chrome\\BLBeacon',
r'SOFTWARE\\WOW6432Node\\Google\\Chrome\\BLBeacon',
]
for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
for path in reg_paths:
try:
with winreg.OpenKey(hive, path) as k:
version, _ = winreg.QueryValueEx(k, 'version')
pv = parse_version(str(version))
if pv:
candidates.append((pv, f'Registry:{path}'))
except Exception:
pass
except Exception:
pass
env_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 env_paths:
if p and os.path.exists(p):
out = run_cmd([p, '--version'])
pv = parse_version(out)
if pv:
candidates.append((pv, p))
return max(candidates, default=(None, None), key=lambda x: x[0] or (0, 0, 0, 0))
def detect_macos():
app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app):
out = run_cmd([app, '--version'])
pv = parse_version(out)
if pv:
return pv, app
plist = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(plist):
out = run_cmd(['/usr/bin/defaults', 'read', plist, 'CFBundleShortVersionString'])
pv = parse_version(out)
if pv:
return pv, plist
return None, None
def detect_linux():
bins = [
'google-chrome',
'google-chrome-stable',
'/opt/google/chrome/chrome',
]
for b in bins:
out = run_cmd([b, '--version']) if not b.startswith('/') or os.path.exists(b) else None
pv = parse_version(out)
if pv:
return pv, b
return None, None
def main():
system = platform.system().lower()
version = None
source = None
if 'windows' in system:
version, source = detect_windows()
elif 'darwin' in system:
version, source = detect_macos()
elif 'linux' in system:
version, source = detect_linux()
if not version:
print('UNKNOWN')
sys.exit(2)
if cmp_ver(version, FIXED) < 0:
print('VULNERABLE')
sys.exit(1)
else:
print('PATCHED')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Google Chrome Releases homepage
- CISA Known Exploited Vulnerabilities overview
- FIRST EPSS API documentation
- FIRST EPSS data statistics
- GreyNoise vulnerability prioritization overview
- Shodan vulnerability assessment help
- VulDB entry for CVE-2026-11031
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.