← Back to Feed CACHED · 2026-06-06 22:21:53 · CACHE_KEY CVE-2026-11294
CVE-2026-11294 · CWE-451 · Disclosed 2026-06-05

Google Chrome Passwords UI spoofing via crafted HTML page

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"This is a phishing assist, not a fleet-burning browser bug."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Host a lure page with spoofing logic

The attacker uses a standard phishing kit or custom JavaScript hosted on any web server to render a crafted HTML page that triggers the Passwords UI flaw. There is no need for prior foothold on the endpoint; delivery is just a link, ad, chat message, or embedded web content.
Conditions required:
  • Attacker can deliver a URL to the target user
  • Target is running vulnerable Chrome prior to 149.0.7827.53
Where this breaks in practice:
  • 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
Detection/coverage: Traditional vuln scanners can identify vulnerable Chrome versions on managed endpoints, but they do not validate exploitability of the spoof path itself.
STEP 02

User visits the attacker page

The victim must interact with the malicious content in a live browser session. This is the decisive friction point: exploitation is not background-triggered from the network and not wormable.
Conditions required:
  • User clicks or otherwise opens attacker-controlled content
  • Chrome protections or enterprise controls do not block page load
Where this breaks in practice:
  • Requires explicit user interaction (UI:R)
  • Many enterprises route risky links through isolation, detonation, or reputation controls
Detection/coverage: Web proxy, browser telemetry, and email click-tracking may show the visit, but no generic IDS signature is likely for this specific flaw.
STEP 03

Spoof password-related browser UI

Using the bug, the crafted page presents misleading Passwords-related interface elements that appear more trustworthy than normal webpage chrome. The attacker is weaponizing *trust in browser UI*, not exploiting memory safety or escaping the sandbox.
Conditions required:
  • Rendered page reaches the vulnerable code path
  • User sees and believes the spoofed UI
Where this breaks in practice:
  • Spoofing success is human-dependent and inconsistent across users
  • Password managers, SSO flows, and user familiarity with enterprise login journeys reduce conversion
Detection/coverage: There is little reliable endpoint detection for 'convincing fake UI'; defender visibility comes mostly from downstream credential-use anomalies.
STEP 04

Capture credentials or misdirect an action

The likely end state is credential phishing, user consent to an unwanted action, or trust abuse around saved-password workflows. Any real impact requires a second-stage social-engineering win; the browser flaw alone only lowers the bar for that social engineering.
Conditions required:
  • User submits data or follows the spoofed prompt
  • Captured credentials are still valid and not blocked by MFA or phishing-resistant auth
Where this breaks in practice:
  • 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
Detection/coverage: Identity telemetry is stronger than exploit telemetry here: impossible travel, new device registration, MFA fatigue, and suspicious OAuth/app-consent events are the useful signals.
03 · Compensating Control

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

The supporting signals.

In-the-wild statusNo public exploitation evidence found in authoritative sources reviewed; the CVE record's CISA ADP SSVC marks Exploitation: none.
KEV statusNot listed in the CISA KEV catalog as reviewed.
Proof-of-concept availabilityNo public PoC repo or Exploit-DB-style release surfaced in primary-source review. The underlying Chromium issue reference exists, but details remain access-restricted.
EPSS0.00022 (~0.022%), which is extremely low and consistent with a low-confidence social-engineering bug rather than a favored intrusion primitive.
CVSS vectorCVSS: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 versionsChrome 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 / backportsVendor 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 realityThis 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 timingThe 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.
ReporterReported by Google in the Chrome release notes; no external researcher credit or bounty is listed for this CVE.

Sources.

  1. Official CVE JSON record for CVE-2026-11294
  2. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  3. Chrome Releases: Early Stable Update for Desktop (May 29, 2026)
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. Canadian Centre for Cyber Security advisory AV26-544
  7. GovCERT.HK alert A26-06-08
  8. openSUSE maintenance patchinfo including CVE-2026-11294
05 · The Call

Final Verdict
↓ DOWNGRADED to LOW (2.8/10)

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:L only; 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.

06 · Verification

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.

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