← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11031 · 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

Like a fake bank teller window built inside the real branch lobby

CVE-2026-11031 is an input-validation flaw in Chrome Password Manager that can let a remote attacker spoof trusted browser UI. The affected range is Google Chrome prior to 149.0.7827.53; Google's early stable desktop release notes show 149.0.7827.53/.54 as the fix train for Windows and Mac, and enterprises should use endpoint inventory to confirm the exact rollout state across their fleet.

Google's MEDIUM 4.3 baseline is defensible on paper, but in real operations this lands lower. The attacker still needs the victim in front of a malicious page and needs the bug to successfully convert that moment into a believable fake password-manager interaction; the flaw does not by itself give code execution, sandbox escape, or direct credential extraction from Chrome.

"This is a phishing assist in trusted browser clothing, not a fleet-burning browser RCE"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled web content

Weaponized tool: a phishing page or malicious ad delivery path. The attacker must get a user running vulnerable Chrome to render attacker-supplied content over normal web traffic; this is internet-reachable in theory, but still depends on the user visiting the page.
Conditions required:
  • Victim runs Chrome older than 149.0.7827.53
  • Victim can browse to attacker-controlled content
  • Attacker can deliver normal HTTPS web content
Where this breaks in practice:
  • Requires user interaction by definition
  • Secure web gateways, URL filtering, and Safe Browsing can kill the path before the bug matters
  • Managed Chrome fleets often auto-update quickly, shrinking the reachable population
Detection/coverage: Version-based scanners and endpoint inventory can flag outdated Chrome. Network scanners are poor coverage because this is a client-side browser bug, not an exposed service.
STEP 02

Trigger spoofed Password Manager UI

Weaponized tool: crafted page content leveraging the input-validation flaw. The attacker attempts to make untrusted content appear as if it were trusted Password Manager UI, turning a browser trust boundary into a social-engineering amplifier.
Conditions required:
  • The vulnerable code path in Password Manager is reachable from rendered content
  • The browser is on an affected build
  • The spoof is convincing enough in the user's environment
Where this breaks in practice:
  • No public exploit kit or broadly circulated PoC was found
  • UI spoofing bugs are fragile across DPI, themes, language packs, and UX changes
  • Password-manager re-auth prompts or profile separation can break the illusion
Detection/coverage: There is usually no clean signature for the trigger itself. Browser telemetry, phishing detections, and web filtering provide better coverage than IDS signatures.
STEP 03

Exploit user trust, not the kernel

Weaponized tool: the fake prompt itself. The attacker still needs the victim to click, type, save, reveal, or otherwise act on the spoofed interface; the bug's leverage comes from abusing Chrome's visual trust, not from memory corruption.
Conditions required:
  • User believes the spoofed UI is genuine
  • User takes the requested action
  • Enterprise controls do not require separate re-authentication
Where this breaks in practice:
  • MFA and passwordless flows reduce payoff from harvested credentials
  • Many enterprise password managers require OS or profile re-auth for sensitive actions
  • User confusion does not guarantee credential capture or durable compromise
Detection/coverage: EDR/browser telemetry may see suspicious navigation chains or follow-on phishing behavior, but most commodity scanners will miss this step.
STEP 04

Convert deception into low-grade impact

Weaponized tool: the follow-on phishing workflow. The practical outcome is low-integrity user deception such as tricking the user into an unsafe action or handing over credentials elsewhere; the CVSS and description do not support direct browser compromise from this flaw alone.
Conditions required:
  • Attacker has an external collection point or follow-on phishing flow
  • Victim action creates something useful to the attacker
Where this breaks in practice:
  • Impact is capped: no direct code exec, no sandbox break, no stated confidentiality loss from the vuln itself
  • Any useful outcome often depends on additional social engineering or a second-stage phish
Detection/coverage: Credential-theft detections, IdP alerts, impossible-travel alerts, and mailbox/SSO anomaly monitoring are more useful than CVE-specific exploit detection.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo known active exploitation evidence in the supplied intel and not KEV-listed. This matters because client-side Chrome bugs that are actually burning tend to show up fast in KEV or public incident reporting.
Public PoC availabilityNo public PoC or exploit kit located in common public tracking during this review. That is not proof of safety, but it lowers immediate weaponization pressure.
EPSS0.00047 from the user-supplied intel, which is extremely low. FIRST EPSS is the right directional input here: expected exploitation pressure is near the floor.
KEV statusNot listed in CISA KEV as of 2026-06-06. For patch triage, that keeps this out of the 'within hours' lane.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N maps to remote delivery but mandatory user interaction, low integrity-only impact, and no confidentiality or availability loss.
Affected versionsGoogle Chrome before 149.0.7827.53. Because Chrome is evergreen, the real exposure question is not install base but version drift inside managed endpoints.
Fixed versionsGoogle's early stable release notes show 149.0.7827.53/.54 for Windows and Mac. Treat distro/browser repackaging separately and verify the embedded Chromium level before closing exceptions.
Exposure and scanning realityShodan/Censys/GreyNoise are weak fit for this CVE because it is a client-side browser/UI bug, not an internet-facing daemon. Your reliable coverage is EDR, software inventory, browser management telemetry, and package/version compliance.
Disclosure2026-06-04 per the supplied intel, with Google's desktop early-stable fix train published 2026-05-29.
Researcher / reporting attributionNo public researcher attribution located in the release note used here. That is common for Chrome batch releases when the public issue stays sparse or non-public.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

The decisive factor is the impact ceiling: this is a UI-spoofing/phishing-assist bug, not a browser-compromise bug. Even though delivery is remote, the path still depends on user trust and produces only low-integrity impact from the vulnerability itself.

HIGH Impact ceiling is low and accurately bounded by the CVSS vector
MEDIUM Exploitability is reduced by required user interaction and lack of public weaponization
MEDIUM Fleet exposure depends on your Chrome auto-update hygiene and version drift

Why this verdict

  • [object Object]
  • Start at vendor 4.3: Chrome is broadly deployed and the bug is reachable through normal web content, so the vendor baseline is not crazy as a starting point.
  • Down for attacker position and prerequisite chain: This is unauthenticated remote delivery, but it implies successful phishing or malicious-site traffic plus user interaction. That compounds downward pressure because the attacker does not get impact just by sending packets.
  • Down for impact ceiling: The vector already tells the story: C:N/I:L/A:N. No direct credential dump, no code execution, no sandbox escape, no durable browser takeover.
  • Down for real-world population control: Modern enterprise Chrome fleets auto-update, and browser version drift is usually measured in days, not quarters. That sharply limits the long-tail exposed population compared with server-side CVEs.

Why not higher?

It is not higher because the attacker must win a human-interaction step and then still only gets a deception primitive. There is no evidence here of active exploitation, no public PoC pressure, and no technical path from this CVE alone to host compromise or password vault exfiltration.

Why not lower?

It is not IGNORE because browsers are high-frequency attack surfaces and UI spoofing against password-manager trust can still fuel credential theft. If you have lagging Chrome updates or high-risk user populations, the bug is worth cleaning up in normal patch hygiene rather than dismissing outright.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Make sure managed endpoints cannot sit behind the fixed build line; for a LOW verdict there is no mitigation SLA and no hard remediation SLA, so handle this as backlog hygiene in your normal browser evergreen process.
  2. Require re-auth for password reveal/fill where available — OS- or profile-level re-auth weakens the value of spoofed password-manager UI because the attacker must now mimic an additional trust boundary. Roll this into your standard hardening baseline; again, no mitigation SLA applies for LOW.
  3. Tighten web filtering for newly seen or low-reputation domains — This bug still needs a hostile page, so killing first-stage delivery matters more than trying to signature the browser flaw. Apply through your existing SWG/DNS controls as part of routine hygiene.
  4. Watch version drift, not perimeter scans — Use endpoint inventory, browser management, or EDR software census to find Chrome versions below 149.0.7827.53. That gives you actionable exposure data; internet scanners do not.
What doesn't work
  • A WAF does not help much because the victim is the browser client rendering attacker-controlled web content over ordinary HTTPS.
  • Internet exposure scanning is the wrong lens; there is no server port to fingerprint for this client-side flaw.
  • User awareness training alone is not a control boundary. It may reduce success rate, but it does not remove the vulnerable trusted-UI confusion path.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-inventory agent, not from a remote auditor box. Invoke with python3 check_chrome_cve_2026_11031.py on macOS/Linux or py check_chrome_cve_2026_11031.py on Windows; standard user rights are usually enough because it only reads local version data.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check exposure to CVE-2026-11031 by Google Chrome version.
# Fixed version baseline: 149.0.7827.53
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    if not text:
        return None
    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.DEVNULL, text=True).strip()
        return out
    except Exception:
        return None


def detect_windows():
    candidates = []
    try:
        import winreg  # type: ignore
        reg_paths = [
            r'SOFTWARE\\Google\\Chrome\\BLBeacon',
            r'SOFTWARE\\WOW6432Node\\Google\\Chrome\\BLBeacon',
        ]
        for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):
            for path in reg_paths:
                try:
                    with winreg.OpenKey(hive, path) as k:
                        version, _ = winreg.QueryValueEx(k, 'version')
                        pv = parse_version(str(version))
                        if pv:
                            candidates.append((pv, f'Registry:{path}'))
                except Exception:
                    pass
    except Exception:
        pass

    env_paths = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]
    for p in env_paths:
        if p and os.path.exists(p):
            out = run_cmd([p, '--version'])
            pv = parse_version(out)
            if pv:
                candidates.append((pv, p))

    return max(candidates, default=(None, None), key=lambda x: x[0] or (0, 0, 0, 0))


def detect_macos():
    app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(app):
        out = run_cmd([app, '--version'])
        pv = parse_version(out)
        if pv:
            return pv, app
    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist):
        out = run_cmd(['/usr/bin/defaults', 'read', plist, 'CFBundleShortVersionString'])
        pv = parse_version(out)
        if pv:
            return pv, plist
    return None, None


def detect_linux():
    bins = [
        'google-chrome',
        'google-chrome-stable',
        '/opt/google/chrome/chrome',
    ]
    for b in bins:
        out = run_cmd([b, '--version']) if not b.startswith('/') or os.path.exists(b) else None
        pv = parse_version(out)
        if pv:
            return pv, b
    return None, None


def main():
    system = platform.system().lower()
    version = None
    source = None

    if 'windows' in system:
        version, source = detect_windows()
    elif 'darwin' in system:
        version, source = detect_macos()
    elif 'linux' in system:
        version, source = detect_linux()

    if not version:
        print('UNKNOWN')
        sys.exit(2)

    if cmp_ver(version, FIXED) < 0:
        print('VULNERABLE')
        sys.exit(1)
    else:
        print('PATCHED')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: do not treat this like a break-glass Chrome emergency. For a LOW verdict there is noisgate mitigation SLA and no hard noisgate remediation SLA; fold it into normal browser evergreen hygiene, use endpoint inventory to find Chrome builds below 149.0.7827.53, and clear the stragglers in your next routine browser maintenance cycle while documenting exceptions and validating that auto-update drift is not the bigger problem.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Google Chrome Releases homepage
  3. CISA Known Exploited Vulnerabilities overview
  4. FIRST EPSS API documentation
  5. FIRST EPSS data statistics
  6. GreyNoise vulnerability prioritization overview
  7. Shodan vulnerability assessment help
  8. VulDB entry for CVE-2026-11031
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.