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

Inappropriate implementation in Passwords in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
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 · 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.8/10)

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.

HIGH Impact is limited to spoofing / low-integrity trust abuse, not code execution
HIGH No active exploitation or KEV evidence at time of review
MEDIUM User-conversion rate in real phishing campaigns varies by environment

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.

05 · Compensating Control

What to do — in priority order.

  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.
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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not burn an emergency patch window on this one. Fold it into routine browser currency work, verify your fleet is auto-updating to Chrome 149 stable, and use identity/phishing controls as your near-term risk reducer. Because this is LOW, there is no noisgate mitigation SLA and no special temporary-block deadline; treat it as backlog hygiene and complete patch rollout inside your normal browser maintenance motion. Your noisgate remediation SLA for a LOW finding is effectively backlog hygiene rather than a fixed date, but for a 10,000-host fleet I would still want vulnerable Chrome stragglers cleaned up in the next standard desktop patch cycle, not left to age indefinitely.

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
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.