← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11227 · CWE-451 · Disclosed 2026-06-04

Incorrect security UI in Tab Hover Cards in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"This is a phishing assist bug in secondary browser UI, not a hands-off compromise path."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land the user on an attacker-controlled site

The attacker needs a victim to visit content under a domain name crafted to trigger the misleading hover-card presentation. The practical weapon here is a custom phishing site / crafted domain, not a public exploit kit. This is still an initial-access social-engineering problem, not a browser compromise problem.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Secure email gateways, DNS filtering, URL rewriting, and browser isolation products can often catch the lure stage. Vulnerability scanners generally only detect outdated Chrome versions, not exploit attempts.
STEP 02

Exploit the hover-card trust cue

Once the user has multiple tabs or hovers over a tab, the attacker relies on Tab Hover Cards showing misleading domain information. The practical tool is again the crafted domain / phishing page; no public weaponized PoC was found in primary-source review. This exploits human trust in secondary UI rather than a code-execution bug.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: There is little host telemetry for the spoof itself. Browser version auditing gives good coverage; runtime exploit detection is weak because the effect is UI deception, not shellcode or abnormal process behavior.
STEP 03

Convert confusion into credential theft or misnavigation

If the victim is convinced by the spoofed presentation, the attacker can steer them to sign in, submit credentials, or trust the wrong tab. The impact is therefore integrity of user decision-making, with downstream risk of phishing, not direct browser compromise. Any real damage still depends on follow-on controls failing.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Identity-provider risky-login alerts, impossible travel, and password-reset spikes are better downstream detectors than endpoint telemetry. EDR is unlikely to see a pure UI-spoof event.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current public exploitation evidence found in the sources reviewed, and Google did not flag this bug as exploited in the release advisory.
PoC availabilityNo public PoC or weaponized exploit located in primary-source review; the Chromium issue is still access-restricted, which limits reproduction details.
EPSS0.00022 supplied in the prompt, which implies very low near-term exploitation probability; percentile was not independently confirmed from FIRST in this review.
KEV statusNot listed in CISA KEV as of 2026-06-06.
CVSS vectorCVSS: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 versionsChrome 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 versionsUpgrade 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 telemetryInference: 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 reporterPublicly disclosed 2026-06-04; Chrome release notes say it was reported by Hafiizh on 2025-10-01.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

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.

HIGH Affected/fixed version boundaries
MEDIUM Real-world exploitability without public bug details
HIGH Severity downgrade driven by user-interaction and phishing dependence

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this as an emergency browser fire drill. Put Chrome versions below 149.0.7827.53 into your normal desktop-browser patch ring, verify auto-update is working, and let phishing-resistant identity controls carry most of the risk reduction. For a LOW noisgate verdict there is no noisgate mitigation SLA and noisgate remediation SLA is also no SLA (treat as backlog hygiene), so document the downgrade rationale, clean up lagging Chrome installs in the next routine cycle, and spend your fast-track patch effort elsewhere unless your org is actively facing lookalike-domain phishing against high-value users.

Sources

  1. NVD entry for CVE-2026-11227
  2. Chrome Releases stable desktop update for June 2, 2026
  3. Chromium issue 448421954
  4. Chrome for Testing availability
  5. Canadian Centre for Cyber Security advisory AV26-544
  6. FIRST EPSS overview
  7. FIRST EPSS model documentation
  8. CISA Known Exploited Vulnerabilities Catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.