Like a mislabeled folder tab, it can fool a glance but it does not unlock the filing cabinet
CVE-2026-11227 is a Chrome desktop UI spoofing flaw in Tab Hover Cards: before 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS, a remote attacker could use a crafted domain name so the hover-card security UI misrepresents what site the user is looking at. Affected population is broad in product terms—Chrome desktop is everywhere—but the vulnerable surface is narrow: it is a secondary trust signal shown when a user hovers over a tab, not a direct memory-corruption or sandbox-escape primitive.
The vendor-side 6.5 / MEDIUM overstates enterprise urgency. In practice this is a user-deception aid that still needs a phishing setup, a victim to browse or click, and a victim to rely on the hover card instead of the omnibox, enterprise filtering, identity prompts, or page content. Chromium itself labeled it Low, and that better matches the real-world blast radius.
3 steps from start to impact.
Land the user on an attacker-controlled site
- Unauthenticated remote reachability to the victim via email, chat, ads, or web content
- Victim uses affected Chrome desktop version before 149.0.7827.53/54
- Attacker controls a domain name crafted for visual misrepresentation
- Requires user interaction and successful lure delivery
- Enterprise email/web filtering can block or rewrite malicious links
- IDN/punycode handling and domain registration constraints reduce some spoofing options
Exploit the hover-card trust cue
- Victim hovers over the relevant tab or otherwise views the hover card
- Victim notices and trusts the hover-card domain display
- The crafted domain name triggers the incorrect UI behavior
- Many users verify the address bar, page branding, SSO prompts, or password manager origin instead
- Hover cards are a secondary UI element and not consistently used as a trust anchor
- The issue does not bypass origin checks or browser process isolation
Convert confusion into credential theft or misnavigation
- Victim proceeds to enter credentials or trust content based on the spoof
- Target workflow is not protected by phishing-resistant MFA or strong SSO origin checks
- Password managers often refuse to fill on lookalike domains
- FIDO2/WebAuthn and phishing-resistant MFA sharply cut credential-harvest payoff
- Even successful misuse typically affects a user session, not the endpoint fleet
The supporting signals.
| In-the-wild status | No current public exploitation evidence found in the sources reviewed, and Google did not flag this bug as exploited in the release advisory. |
|---|---|
| PoC availability | No public PoC or weaponized exploit located in primary-source review; the Chromium issue is still access-restricted, which limits reproduction details. |
| EPSS | 0.00022 supplied in the prompt, which implies very low near-term exploitation probability; percentile was not independently confirmed from FIRST in this review. |
| KEV status | Not listed in CISA KEV as of 2026-06-06. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N — the decisive term is UI:R: it needs a victim action, and there is no confidentiality or availability impact in the base vector. |
| Affected versions | Chrome desktop before 149.0.7827.53; Canada Cyber Centre lists prior to 149.0.7827.53/54 on Windows/Mac and prior to 149.0.7827.53 on Linux. |
| Fixed versions | Upgrade to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. Chrome for Testing also shows 149.0.7827.53 as the stable build available across platforms. |
| Exposure telemetry | Inference: this is a client-side browser UI flaw, so Shodan/Censys/GreyNoise-style internet exposure data is not very meaningful; you prioritize it by fleet version coverage, not external attack-surface counts. |
| Disclosure and reporter | Publicly disclosed 2026-06-04; Chrome release notes say it was reported by Hafiizh on 2025-10-01. |
noisgate verdict.
The single biggest down-rating factor is that this bug lives in a secondary browser trust cue and still requires the attacker to win a user-deception chain. It does not grant code execution, sandbox escape, data exfiltration by itself, or broad fleet-level blast radius.
Why this verdict
- UI:R is the whole story — exploitation requires a victim to land on attacker content and trust the hover-card display, which is immediate downward pressure from the 6.5 baseline.
- Secondary UI, not primary origin enforcement — this appears to mislead a hover card, not the browser's same-origin model, process sandbox, or memory safety boundaries.
- Blast radius is narrow — even a successful attack usually helps steal one user's trust or credentials; it does not turn into host takeover or tenant-wide compromise on its own.
- Modern controls cut payoff — phishing-resistant MFA, password managers, DNS filtering, secure email gateways, and SSO origin checks all sit in the attack path and frequently break the chain.
- No KEV / no public exploit evidence / very low EPSS — current threat intelligence does not support emergency handling.
Why not higher?
If this were an address-bar spoof, cert-indicator bypass, origin bypass, or a flaw already used in credential-harvesting campaigns, it would climb. But the evidence here points to a narrower deception bug in tab hover cards, with no public exploitation and no direct technical compromise primitive.
Why not lower?
It is still a real remotely triggerable browser flaw in a massively deployed product, and phishing-assist bugs do matter at enterprise scale. A large enough user base means even low-conviction UI spoofing can create avoidable identity incidents, so this is not IGNORE.
What to do — in priority order.
- Force browser auto-update — Use Chrome enterprise policy or your endpoint management stack to keep desktop Chrome on the stable channel and prevent long-lived lagging versions. For a LOW verdict there is no mitigation SLA and no remediation SLA beyond backlog hygiene, so do this in the normal browser maintenance flow rather than as an emergency change.
- Harden phishing-resistant sign-in — Push FIDO2/WebAuthn, conditional access, and password-manager-only credential entry for high-value apps. This directly reduces the only realistic payoff path for this bug; for LOW, fold it into the normal hardening roadmap rather than a rush action.
- Block lookalike domains upstream — Use secure email, DNS filtering, and browser isolation to stop newly registered or suspicious lookalike domains before users ever see the spoofed UI. Again, LOW means no special mitigation deadline; enforce through standard control tuning.
- Report version drift — Audit for Chrome versions below 149.0.7827.53 and push laggards into your existing desktop patch queue. Treat exceptions as patch hygiene debt, not a Sev1 incident.
- A WAF does not materially help; the vulnerable component is the client's browser UI, not your web application edge.
- EDR alone is a weak answer because there is no malware execution path inherent to this bug; it may catch follow-on payloads, not the spoof itself.
- Perimeter internet-exposure scanning is mostly irrelevant here; this is not a server-side service banner or remotely fingerprintable listening port issue.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet agent on Windows, macOS, or Linux. Invoke it with python3 check_chrome_cve_2026_11227.py; it needs only normal user rights and reports VULNERABLE, PATCHED, or UNKNOWN by comparing the local Chrome version to 149.0.7827.53.
#!/usr/bin/env python3
# CVE-2026-11227 Chrome version check
# 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)
def parse_version(text):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_str(v):
return '.'.join(str(x) for x in v)
def run_version(cmd):
try:
p = subprocess.run([cmd, '--version'], capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
v = parse_version(out)
if v:
return cmd, v, out.strip()
except Exception:
pass
return None
def candidate_paths():
system = platform.system().lower()
cands = []
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
programfiles = os.environ.get('PROGRAMFILES', '')
programfilesx86 = os.environ.get('PROGRAMFILES(X86)', '')
cands.extend([
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(programfiles, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(programfilesx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
])
elif system == 'darwin':
cands.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
p = which(name)
if p:
cands.append(p)
cands.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
'/opt/google/chrome/chrome',
])
# Deduplicate while preserving order
seen = set()
ordered = []
for c in cands:
if c and c not in seen:
seen.add(c)
ordered.append(c)
return ordered
def main():
found = []
for path in candidate_paths():
if os.path.exists(path) or which(path):
res = run_version(path)
if res:
found.append(res)
if not found:
print('UNKNOWN - Google Chrome executable not found or version could not be parsed')
sys.exit(2)
# Prefer the highest discovered version if multiple installs exist
found.sort(key=lambda x: x[1], reverse=True)
cmd, ver, raw = found[0]
if ver < FIXED:
print(f'VULNERABLE - detected {version_str(ver)} at {cmd}; fixed version is {version_str(FIXED)} or later')
sys.exit(1)
else:
print(f'PATCHED - detected {version_str(ver)} at {cmd}; fixed threshold is {version_str(FIXED)}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.