This is a fake badge on a familiar uniform, not a master key to the building
CVE-2026-11294 is a Chrome Passwords UI spoofing flaw in builds prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. The published CVE record says a remote attacker can use a crafted HTML page to make Chrome present misleading password-related UI, which maps cleanly to *user-interface misrepresentation* rather than memory corruption or sandbox escape.
The vendor baseline of MEDIUM 4.3 is already restrained, but for enterprise patch triage it still overstates operational urgency. The chain requires a user to land on attacker-controlled content and then trust a spoofed prompt; the bug does not itself provide code execution, sandbox escape, auth bypass, or silent credential dumping. In practice this behaves like a phishing amplifier on a very common client, so it belongs in LOW: patch it on normal browser cadence, not in an emergency lane.
4 steps from start to impact.
Host a lure page with spoofing logic
- Attacker can deliver a URL to the target user
- Target is running vulnerable Chrome prior to
149.0.7827.53
- Delivery still needs normal phishing reach or malvertising placement
- Safe Browsing, secure email gateways, DNS filtering, and browser isolation can kill many first clicks before the bug matters
User visits the attacker page
- User clicks or otherwise opens attacker-controlled content
- Chrome protections or enterprise controls do not block page load
- Requires explicit user interaction (
UI:R) - Many enterprises route risky links through isolation, detonation, or reputation controls
Spoof password-related browser UI
- Rendered page reaches the vulnerable code path
- User sees and believes the spoofed UI
- Spoofing success is human-dependent and inconsistent across users
- Password managers, SSO flows, and user familiarity with enterprise login journeys reduce conversion
Capture credentials or misdirect an action
- User submits data or follows the spoofed prompt
- Captured credentials are still valid and not blocked by MFA or phishing-resistant auth
- FIDO2/WebAuthn, conditional access, and MFA sharply limit blast radius
- EDR and identity tools often catch the *use* of stolen credentials even if they miss the browser spoof
The supporting signals.
| In-the-wild status | No public exploitation evidence found in authoritative sources reviewed; the CVE record's CISA ADP SSVC marks Exploitation: none. |
|---|---|
| KEV status | Not listed in the CISA KEV catalog as reviewed. |
| Proof-of-concept availability | No public PoC repo or Exploit-DB-style release surfaced in primary-source review. The underlying Chromium issue reference exists, but details remain access-restricted. |
| EPSS | 0.00022 (~0.022%), which is extremely low and consistent with a low-confidence social-engineering bug rather than a favored intrusion primitive. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — network-reachable but user-interaction required, with only low integrity impact and no confidentiality or availability impact in the base model. |
| Affected versions | Chrome before 149.0.7827.53 per the CVE JSON; desktop rollout notes specify Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/54 as the fixed stable builds. |
| Fixed versions / backports | Vendor fix landed in Chrome 149 stable; distro backport evidence exists in openSUSE maintenance patchinfo, which includes CVE-2026-11294 in its packaged update stream. |
| Exposure / scanning reality | This is client software, not an internet-facing service. Shodan/Censys-style exposure counts are not meaningful; real exposure is your managed browser estate size and how many users can be lured to malicious content. |
| Disclosure timing | The official CVE JSON shows datePublished: 2026-06-04, while the CISA ADP enrichment update and many downstream feeds landed on 2026-06-05. Use June 4, 2026 as the first public CVE publication date. |
| Reporter | Reported by Google in the Chrome release notes; no external researcher credit or bounty is listed for this CVE. |
noisgate verdict.
The single biggest downward pressure is that this flaw only becomes useful after a user is successfully lured onto attacker-controlled web content and then trusts a spoofed password-related UI. That makes it a social-engineering multiplier on a ubiquitous client, not an initial-access or post-exploitation accelerant by itself.
Why this verdict
- Requires user interaction: the attacker must get a victim to open malicious content, which compounds with every phishing control already in your stack.
- No direct system compromise primitive: the published record describes UI spoofing with
I:Lonly; there is no silent credential read, sandbox escape, or arbitrary code execution. - Client-side exposure is broad but shallow: Chrome is everywhere, but this bug is not remotely enumerable like a server CVE and does not create an internet-scale blast radius on its own.
Why not higher?
A higher rating would need a cleaner path from webpage to compromise: credential theft without user decision, direct data exposure, auth bypass, or code execution. None of that is present in the published record. This is materially weaker than the Chrome memory-corruption bugs in the same release train that can lead to sandbox escape or RCE.
Why not lower?
It is not IGNORE because Chrome is deployed everywhere and the affected surface is the password UX, which directly intersects with phishing-resistant goals. In a large fleet, even a low-conversion spoofing bug can still generate real help-desk load and some identity incidents if left unpatched too long.
What to do — in priority order.
- Enforce phishing-resistant auth — Prioritize FIDO2/WebAuthn and strong conditional access on high-value apps so a spoofed password prompt is less useful even if a user bites. For a LOW verdict there is no SLA beyond normal hygiene, but this control should already be standard and any gaps should be queued with backlog priority.
- Tighten browser channel compliance — Use enterprise browser management to keep Chrome on auto-update and block long-tail stragglers from sitting below
149.0.7827.53. For LOW, treat this as backlog hygiene and fold it into routine browser currency work rather than a special-response program. - Harden malicious-link interception — Safe Browsing, DNS/web filtering, click-time detonation, and remote browser isolation all break the chain before the spoofed UI ever renders. For LOW, maintain these controls continuously and verify coverage during normal control-validation cycles.
- Watch identity-side detections — Because exploit telemetry is weak, monitor for stolen-credential use: impossible travel, fresh device registration, unusual OAuth consent, password reset anomalies, and MFA fatigue. For LOW, no special deadline applies, but make sure these detections remain enabled and routed.
- Relying on EDR alone doesn't help much because there is no malware execution requirement and no memory-corruption artifact to catch.
- Treating this like a network perimeter problem misses the point; Shodan exposure reduction or external attack-surface cleanup does not materially change a client-side phishing chain.
- Basic password rotation after the fact is not a preventive control and does nothing to stop the spoof prompt from harvesting fresh secrets.
Crowdsourced verification payload.
Run this on the target endpoint or via your software-inventory/remote-exec tooling on managed workstations. Invoke it with python3 check_chrome_cve_2026_11294.py; no admin rights are required, but the script must be able to read installed application version metadata or execute the browser binary with --version.
#!/usr/bin/env python3
# Check Chrome/Chromium version exposure for CVE-2026-11294
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
THRESHOLD = (149, 0, 7827, 53)
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 cmp_ver(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=5)
return out.strip()
except Exception:
return None
def windows_candidates():
candidates = []
envs = [
os.environ.get('PROGRAMFILES'),
os.environ.get('PROGRAMFILES(X86)'),
os.environ.get('LOCALAPPDATA'),
]
suffixes = [
r'Google\\Chrome\\Application\\chrome.exe',
r'Chromium\\Application\\chrome.exe',
]
for base in envs:
if not base:
continue
for suf in suffixes:
p = os.path.join(base, *suf.split('\\'))
if os.path.exists(p):
candidates.append(p)
return candidates
def mac_candidates():
return [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium'),
]
def linux_candidates():
bins = [
'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome'
]
found = []
for b in bins:
p = shutil.which(b)
if p:
found.append(p)
return found
def detect_versions():
system = platform.system().lower()
candidates = []
if 'windows' in system:
candidates = windows_candidates()
elif 'darwin' in system:
candidates = mac_candidates()
else:
candidates = linux_candidates()
seen = []
for path in candidates:
if not os.path.exists(path) and not shutil.which(path):
continue
out = run_cmd([path, '--version'])
if not out:
continue
ver = parse_version(out)
if ver:
seen.append((path, ver, out))
return seen
def main():
seen = detect_versions()
if not seen:
print('UNKNOWN: could not determine installed Chrome/Chromium version')
sys.exit(2)
vulnerable = []
patched = []
for path, ver, raw in seen:
if cmp_ver(ver, THRESHOLD) < 0:
vulnerable.append((path, ver, raw))
else:
patched.append((path, ver, raw))
if vulnerable:
details = '; '.join([f'{p}={".".join(map(str, v))}' for p, v, _ in vulnerable])
print(f'VULNERABLE: found version(s) below 149.0.7827.53 -> {details}')
sys.exit(1)
details = '; '.join([f'{p}={".".join(map(str, v))}' for p, v, _ in patched])
print(f'PATCHED: found version(s) at or above 149.0.7827.53 -> {details}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Official CVE JSON record for CVE-2026-11294
- Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
- Chrome Releases: Early Stable Update for Desktop (May 29, 2026)
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- Canadian Centre for Cyber Security advisory AV26-544
- GovCERT.HK alert A26-06-08
- openSUSE maintenance patchinfo including CVE-2026-11294
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.