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

Insufficient validation of untrusted input in Password Manager in Google Chrome prior to 149

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

This is a counterfeit badge at the lobby desk, not a crowbar at the server-room door

CVE-2026-11192 is an input-validation flaw in Google Chrome Password Manager that affects desktop Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. Google describes the result as UI spoofing via malicious network traffic, which means attacker-controlled content can make the browser present misleading Password Manager-related security UI rather than directly achieving code execution or data theft.

Google's MEDIUM / 4.3 baseline is basically right. The attack surface is broad because Chrome is everywhere and the victim only needs to browse attacker content, but the impact is constrained: this is a user-deception and integrity issue in a trusted browser surface, not memory corruption, sandbox escape, or credential dump by itself.

"Real bug, but this is a phishing/UI-trust problem—not a browser-takeover event."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the user into attacker-controlled traffic

The attacker needs the victim to load a malicious page or otherwise consume attacker-controlled network responses. In practice this is a standard web lure delivered through phishing, ads, compromised sites, or links in chat. Common operator tooling here is a commodity phishing kit or redirector plus a web server; nothing exotic is required.
Conditions required:
  • Unauthenticated remote reach to the victim via the web
  • Victim browses attacker-controlled or attacker-influenced content
  • Chrome desktop version is below 149.0.7827.53
Where this breaks in practice:
  • Requires user interaction; there is no headless worm path
  • Safe Browsing, URL filtering, and email/web gateways can kill a large share of commodity lures before delivery
  • Corporate browsing isolation or ad-blocking reduces exposure to malvertising paths
Detection/coverage: No vuln-specific scanner signal at this step; coverage is mostly via browser version inventory, URL filtering telemetry, email gateway hits, and proxy logs.
STEP 02

Trigger spoofable Password Manager UI

The crafted traffic drives Chrome into a Password Manager-related UI state that is rendered incorrectly or misleadingly because untrusted input is not validated tightly enough. Think attacker-generated browser chrome that looks more trustworthy than it should. A realistic weaponization stack is a custom HTML/JS lure hosted behind nginx or similar, not a public one-click exploit framework.
Conditions required:
  • Victim reaches the crafted content
  • Relevant Password Manager UI path is reachable in that browsing session
Where this breaks in practice:
  • Bug details are still restricted in Chromium's tracker, so broad commodity weaponization is slower right now
  • The exploit path appears tied to a specific browser component and user-visible state, not a generic renderer bug
Detection/coverage: Network scanners will not see this. EDR may only catch downstream credential theft tooling, not the UI spoof itself.
STEP 03

Win the trust decision

The attacker still has to make the victim believe and act on the spoofed UI—click, save, reveal, or otherwise trust a fake prompt. This is where the bug becomes a phishing amplifier: it borrows browser trust to improve the conversion rate of social engineering. Tooling is usually just the operator's phishing kit and collection backend.
Conditions required:
  • Victim notices and interacts with the spoofed UI
  • Enterprise user training or policy does not interrupt the action
Where this breaks in practice:
  • Human behavior is variable; many users ignore odd prompts
  • MFA, passwordless flows, and federated auth reduce the value of a single harvested secret
  • Password managers and IdP controls can limit reuse even if a user is tricked
Detection/coverage: Detection is indirect: suspicious logins, impossible travel, IdP risk alerts, password reset spikes, and phishing telemetry.
STEP 04

Convert spoofing into account misuse

If the victim acts on the spoof, the attacker may capture credentials or induce a wrong trust/save/fill action. The downstream impact is real, but it is still one step removed from the vulnerability itself: the CVE gives misleading UI, not turnkey code execution. Operators then pivot into normal account abuse tooling against SaaS, VPN, or internal portals.
Conditions required:
  • User interaction succeeds
  • Captured secret or induced action is valuable in the target environment
Where this breaks in practice:
  • Impact is bounded to low integrity in the published CVSS framing
  • Strong conditional access and phishing-resistant MFA can break the monetization step
Detection/coverage: Detect via IdP logs, CASB, MFA fatigue alerts, credential reset events, and browser version compliance dashboards rather than exploit signatures.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the sources reviewed, and Google/third-party advisories do not flag this one as exploited.
PoC availabilityNo public PoC located. Chromium notes that bug details may remain restricted until the user base is patched, which slows copycat weaponization.
EPSS0.00025 (~0.025%) per the intel you provided; that is a very low modeled near-term exploitation probability.
KEV statusNot listed in CISA KEV as of this assessment.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — remote, no auth, but user interaction required and only low-integrity impact.
Affected versionsDesktop Chrome prior to 149.0.7827.53; Canadian Cyber Centre spells that out as 149.0.7827.53/54 for Windows/Mac and 149.0.7827.53 for Linux.
Fixed versionsUpgrade to Chrome 149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. For enterprises, the real fixed state is *endpoint has updated and relaunched*.
Exposure / scanning realityThere is no meaningful Shodan/Censys-style census here because this is a client-side browser flaw, not an internet-exposed service. Your exposure is your managed desktop fleet and any unmanaged Chrome installs outside policy.
Disclosure timelineChrome 149 stable shipped on 2026-06-02; the CVE record was published on 2026-06-04.
Reporter / sourceReported by Google in the Chrome stable channel notes; bug 503490678 is the underlying restricted Chromium issue.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.2/10)

The decisive factor is that this bug stops at spoofable Password Manager UI and still requires the victim to trust and act on that UI. It matters because browser security chrome is high-trust, but there is no evidence here of direct code execution, sandbox escape, or automatic credential disclosure.

HIGH Affected version range and fix version
MEDIUM Real-world attack-path assessment
MEDIUM No public exploitation / PoC status at time of review

Why this verdict

  • Baseline stays near vendor 4.3 because Chrome is ubiquitous and attacker reach is just normal web delivery, not local access or prior auth.
  • Downward pressure: user interaction is mandatory. The attacker still has to get a victim to load the content and then trust a misleading Password Manager surface.
  • Downward pressure: impact is bounded. Published scoring only claims I:L; there is no stated confidentiality loss, availability loss, or code execution path.
  • Upward pressure: browser trust matters. Password Manager UI is a high-trust surface, so spoofing there can improve phishing conversion more than a generic page-level fake.

Why not higher?

This is not a memory corruption bug, not a sandbox escape, and not a credential exfiltration primitive on its own. Even with broad client-side reach, the attacker still needs the human to do the last mile of the exploit, which caps both reliability and blast radius.

Why not lower?

Calling this LOW would understate the value of spoofing security UI in a browser component users are trained to trust. In a large fleet, even a modest conversion rate on a convincing Password Manager spoof can produce enough account abuse to justify keeping it in the MEDIUM bucket.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update and relaunch — Make sure managed endpoints are not just downloading Chrome 149 but actually restarting into it. For a MEDIUM verdict there is no mitigation SLA; use your normal browser management channel and clear stragglers inside the 365-day remediation window.
  2. Harden phishing-resistant authentication — Prefer passkeys/FIDO2 or strong MFA on enterprise apps so a spoofed Password Manager prompt is less useful even if a user is fooled. This is a standing control, not an emergency one; for MEDIUM, there is no mitigation SLA and this should be folded into ongoing identity hardening before the remediation window expires.
  3. Constrain unmanaged Chrome installs — Inventory and remove user-installed or portable Chrome variants that sit outside enterprise update policy. On this verdict there is no mitigation SLA; treat it as hygiene work that should be completed within the 365-day remediation window while you verify version compliance.
  4. Tune IdP detection for post-phish abuse — Because the likely real impact is downstream account misuse, raise monitoring on unusual login patterns, password resets, and fresh-device sign-ins. There is no mitigation SLA for MEDIUM findings, so deploy through normal detection engineering rather than emergency change control.
What doesn't work
  • A WAF does not meaningfully solve this; the vulnerable component is the client browser UI path, not your web app.
  • Server-side patching of internal apps does nothing for endpoints running a vulnerable Chrome build.
  • Generic network perimeter blocking is weak here because the lure can come from normal web browsing, ads, or compromised legitimate sites.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management agent; it is meant for local version verification, not remote scanning. Invoke it as python3 check_cve_2026_11192.py (or py check_cve_2026_11192.py on Windows). No admin rights are normally required unless your EDR blocks process/version queries.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11192.py
# Verify whether local Chrome/Chromium is below the fixed version for CVE-2026-11192.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

FIXED = (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 run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return p.returncode, out.strip()
    except Exception:
        return 1, ''


def candidate_commands():
    cmds = []
    system = platform.system()

    if system == 'Windows':
        local = os.environ.get('LOCALAPPDATA', r'C:\Users\%USERNAME%\AppData\Local')
        pf = os.environ.get('PROGRAMFILES', r'C:\Program Files')
        pfx86 = os.environ.get('PROGRAMFILES(X86)', r'C:\Program Files (x86)')
        candidates = [
            Path(local) / 'Google/Chrome/Application/chrome.exe',
            Path(pf) / 'Google/Chrome/Application/chrome.exe',
            Path(pfx86) / 'Google/Chrome/Application/chrome.exe',
            Path(pf) / 'Chromium/Application/chrome.exe',
            Path(pfx86) / 'Chromium/Application/chrome.exe',
        ]
        for c in candidates:
            if c.exists():
                cmds.append([str(c), '--version'])
        for name in ['chrome', 'chrome.exe', 'chromium', 'chromium.exe']:
            found = shutil.which(name)
            if found:
                cmds.append([found, '--version'])
    elif system == 'Darwin':
        candidates = [
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            '/Applications/Chromium.app/Contents/MacOS/Chromium',
        ]
        for c in candidates:
            if os.path.exists(c):
                cmds.append([c, '--version'])
        for name in ['google-chrome', 'chromium', 'chrome']:
            found = shutil.which(name)
            if found:
                cmds.append([found, '--version'])
    else:
        for name in [
            'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome'
        ]:
            found = shutil.which(name)
            if found:
                cmds.append([found, '--version'])
        extra = [
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
        ]
        for c in extra:
            if os.path.exists(c):
                cmds.append([c, '--version'])

    # de-duplicate while preserving order
    seen = set()
    unique = []
    for cmd in cmds:
        key = tuple(cmd)
        if key not in seen:
            seen.add(key)
            unique.append(cmd)
    return unique


def main():
    for cmd in candidate_commands():
        rc, out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            label = ' '.join(cmd[:-1])
            if ver < FIXED:
                print(f'VULNERABLE: {label} version {".".join(map(str, ver))} is below 149.0.7827.53')
                sys.exit(1)
            else:
                print(f'PATCHED: {label} version {".".join(map(str, ver))} is at or above 149.0.7827.53')
                sys.exit(0)

    print('UNKNOWN: Could not locate a local Chrome/Chromium executable or parse its version')
    sys.exit(2)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this as a fleet-wide emergency, but do verify Chrome version compliance and relaunch enforcement across managed endpoints because this is still a trusted-browser-UI bug in a ubiquitous client. For a MEDIUM noisgate verdict, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; practically, let auto-update do the heavy lifting, validate that endpoints land on 149.0.7827.53+, and clean up unmanaged or stalled browser installs well before the noisgate remediation SLA of ≤365 days.

Sources

  1. Google Chrome Stable Channel Update for Desktop
  2. Google Chrome Early Stable Update for Desktop
  3. Chrome Beta for Desktop Update
  4. CIRCL Vulnerability Lookup for CVE-2026-11192
  5. Canadian Centre for Cyber Security AV26-544
  6. CISA Known Exploited Vulnerabilities Catalog
  7. CISA KEV data mirror
  8. Chromium Security
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.