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

Insufficient policy enforcement in Password Manager in Google Chrome prior to 149

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

This is less a smashed vault than a valet key that sometimes opens the password drawer

The authoritative public record matching your description appears to be CVE-2026-11193 rather than CVE-2026-11011; it was published on 2026-06-04 and describes *insufficient policy enforcement* in Chrome Password Manager. Affected builds are Chrome before 149.0.7827.53 on Windows/Linux and, per downstream advisories, before 149.0.7827.54 on macOS, with the fix shipped in Google's May 29, 2026 early-stable release.

In real enterprise terms, this is not a perimeter-breaker. It needs a victim on a vulnerable browser to load a crafted HTML page, the impact is constrained to the local browser profile and whatever credentials or policy state are actually present there, and many mature fleets already blunt it by disabling Chrome's built-in password manager or using passwordless/SSO. That makes MEDIUM the right first-call severity even though Chrome is ubiquitous.

"Assessed at MEDIUM: broad Chrome footprint, but this is still a user-driven browser-side policy bypass with no exploitation signal."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land a victim on attacker HTML

The weapon is just a crafted web page rendered by vulnerable Chrome, so delivery is cheap: phishing, malvertising, compromised sites, or chat links all work in principle. There is no server to expose here; the exploit path begins only when the user loads attacker-controlled HTML in a vulnerable browser build. Reference: Chrome advisory.
Conditions required:
  • Victim runs Chrome earlier than 149.0.7827.53 or macOS Chrome earlier than 149.0.7827.54
  • User visits attacker-controlled or attacker-influenced web content
  • Built-in Chrome Password Manager is present in the browsing workflow
Where this breaks in practice:
  • Requires user interaction; this is not a scan-and-hit internet service bug
  • Email security, browser isolation, Safe Browsing, and web filtering can kill the lure before render
  • A large chunk of enterprise users no longer rely on browser-saved passwords for high-value apps
Detection/coverage: Version scanners can flag outdated Chrome, but they cannot prove exploitability on a given profile. Network detections are generic lure telemetry, not CVE-specific.
STEP 02

Trigger password-manager policy bypass

Once rendered, the page abuses the Password Manager policy-enforcement flaw to bypass a discretionary access control boundary. Public detail is intentionally sparse because the Chromium bug is non-public, which is normal for browser fixes; what matters operationally is that this is a browser-state abuse, not remote code execution or sandbox escape. Reference: Chromium issue 503642586.
Conditions required:
  • The vulnerable code path is reachable in that browser/profile state
  • Relevant credentials or password-manager features are actually enabled for the user
Where this breaks in practice:
  • Many orgs disable PasswordManagerEnabled or discourage storing enterprise secrets in Chrome
  • Password-manager blocklists for sensitive domains reduce reachable blast radius
  • Users on federated SSO/passkeys reduce credential value even if the policy boundary is bypassed
Detection/coverage: Little to no direct runtime detection from traditional scanners. Browser telemetry may show navigation and form events, but not a clean 'this CVE fired' signal.
STEP 03

Turn local browser access into credential value

The attacker still has to turn the access-control bypass into something useful: credential disclosure, unintended fill behavior, or downstream account abuse. That last mile depends heavily on whether the user actually stores credentials in Chrome and whether those credentials unlock anything important. Reference: CVE record aggregation.
Conditions required:
  • Victim has stored passwords or related password-manager state worth abusing
  • Targeted accounts are not fully protected by phishing-resistant MFA or passkeys
Where this breaks in practice:
  • Blast radius is typically one user profile at a time
  • No evidence this flaw trivially scales to tenant-wide compromise
  • Account protections at the IdP layer can still break post-browser abuse
Detection/coverage: Best signal is downstream: unusual sign-ins, impossible travel, MFA prompts, or anomalous app access after lure delivery.
03 · Intelligence Metadata

The supporting signals.

Identifier reconciliationThe public record matching the supplied title is CVE-2026-11193, published 2026-06-04. I found no authoritative Chrome record for CVE-2026-11011 matching this description.
In-the-wild statusNo evidence found of active exploitation. It is not listed in CISA KEV as of this assessment.
Public PoC availabilityNo public PoC located in the sources reviewed; the Chromium bug link is non-public, which keeps the exploit recipe opaque for now.
EPSS0.00016 (3.633 percentile), which is effectively background noise rather than 'attackers will dogpile this next week' territory.
KEV statusNot in KEV. No KEV add date, no federal patch deadline override.
Vendor severity noteChrome labels it 'Chromium security severity: Medium' in the CNA description, but Chrome did not publish a vendor CVSS base score.
Authority CVSS noteA CISA-ADP/NVD secondary vector now exists: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H = 6.5 MEDIUM. I still treat this verdict as ASSESSED AT MEDIUM because there is no Chrome vendor CVSS baseline to compare against.
Affected versionsChrome before 149.0.7827.53 per CNA/NVD data; downstream advisories indicate macOS fixed at 149.0.7827.54.
Fixed versionsDesktop early-stable fix shipped 2026-05-29: 149.0.7827.53/.54 for Windows and Mac. For fleet ops, treat anything older than 149.0.7827.53 as suspect, and on macOS require 149.0.7827.54+.
Scanning / exposure realityNo meaningful Shodan/Censys/GreyNoise exposure story here because this is a client-side browser flaw, not an internet-listening service. Your exposure is the count of managed Chrome endpoints and the subset still using the built-in password manager for valuable accounts.
Disclosure / reporterPublished by the Chrome CNA on 2026-06-04; public source names the vendor and bug reference, but the specific reporter is not disclosed in the materials reviewed.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

The decisive friction is that this bug lives entirely in the client browser workflow and requires a victim to render attacker HTML before anything happens. Even then, impact is gated by whether the user actually stores valuable credentials in Chrome, which sharply narrows real blast radius compared with server-side auth bypasses or browser RCEs.

HIGH Affected version floor and fixed build identification
MEDIUM Real-world impact magnitude, because the Chromium issue details remain non-public
HIGH Assessment that there is no current exploitation pressure

Why this verdict

  • User interaction is mandatory: attacker position is unauthenticated remote, but only after the victim loads crafted HTML. That immediately pushes this below wormable or perimeter-exposed classes.
  • It is post-click and profile-scoped: the prerequisite implies a single-user browser session, not broad network reach. Real deployments compound that friction with web filtering, browser isolation, and Safe Browsing.
  • Enterprise password storage habits matter: if PasswordManagerEnabled is off, sensitive domains are blocklisted, or users rely on SSO/passkeys, the reachable population and resulting value drop materially.
  • No exploitation evidence: no KEV listing, no active-campaign reporting, and EPSS is extremely low. That keeps urgency in the routine-browser-patching lane instead of incident-response lane.
  • Wide deployment keeps it from being LOW: Chrome is everywhere, so even a non-RCE password-manager boundary failure deserves attention once you verify vulnerable builds are present.

Why not higher?

There is no sign of active exploitation, no public exploit recipe in the reviewed sources, and no indication this jumps from one browser profile to broad enterprise compromise. Most importantly, the attacker must first win a lure and then find stored credentials or exploitable password-manager state on that specific endpoint.

Why not lower?

This still touches credential-handling logic inside one of the most widely deployed enterprise clients on earth. If you do allow Chrome's built-in password manager for workforce accounts, the flaw can undermine a policy boundary protecting exactly the data defenders care about.

05 · Compensating Control

What to do — in priority order.

  1. Disable Chrome password saving where business-acceptable — Set PasswordManagerEnabled=false for managed browsers that do not need Chrome's built-in password store. For a MEDIUM verdict there is no mitigation SLA, so this is optional risk reduction rather than an emergency change; use it for higher-risk user groups and shared-workstation populations.
  2. Block Password Manager on crown-jewel domains — Use PasswordManagerBlocklist for IdP, admin, finance, and privileged application domains so Chrome does not save/fill credentials there. There is no mitigation SLA for MEDIUM, but this is a sensible control during normal policy maintenance if your users still store browser passwords.
  3. Prefer passkeys or phishing-resistant MFA — Shift high-value apps away from reusable passwords so a browser-side password-manager flaw has less to steal or misuse. There is no mitigation SLA for MEDIUM; align this with your identity hardening roadmap rather than treat it as a one-off CVE action.
  4. Use browser version reporting aggressively — Pull a versions report from the Admin console or endpoint tooling and isolate all Chrome builds below the fixed floor. For MEDIUM there is no mitigation SLA, but precise version visibility is what keeps this from becoming a blind spot in a 10,000-host fleet.
What doesn't work
  • A WAF does not help; there is no vulnerable enterprise web service to shield here.
  • Network vulnerability scanners only find outdated versions; they cannot tell you whether a given user profile stores passwords or whether the vulnerable policy path is actually reachable.
  • MFA alone is not a complete answer if browser-stored passwords still unlock low-friction sessions, legacy apps, or downstream tokens.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/remote execution framework as the logged-in user or a standard local account; admin rights are not required in most cases. Example: python3 check_chrome_cve_2026_11193.py on macOS/Linux or py check_chrome_cve_2026_11193.py on Windows. It checks local Google Chrome version and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11193.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / Chrome not found / parse failure

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

WIN_MIN = (149, 0, 7827, 53)
LINUX_MIN = (149, 0, 7827, 53)
MAC_MIN = (149, 0, 7827, 54)


def parse_ver(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
    return tuple(int(x) for x in m.groups()) if m else None


def cmp_ver(a, b):
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        if p.returncode == 0:
            return (p.stdout or p.stderr).strip()
    except Exception:
        pass
    return None


def get_windows_version():
    candidates = [
        Path(os.environ.get('ProgramFiles', r'C:\Program Files')) / 'Google/Chrome/Application/chrome.exe',
        Path(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)')) / 'Google/Chrome/Application/chrome.exe',
        Path(os.environ.get('LocalAppData', '')) / 'Google/Chrome/Application/chrome.exe',
    ]
    for exe in candidates:
        if exe.exists():
            cmd = [
                'powershell', '-NoProfile', '-Command',
                f"(Get-Item '{str(exe)}').VersionInfo.ProductVersion"
            ]
            out = run_cmd(cmd)
            if out:
                return out, str(exe)
    return None, None


def get_macos_version():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for exe in candidates:
        if Path(exe).exists():
            out = run_cmd([exe, '--version'])
            if out:
                return out, exe
    return None, None


def get_linux_version():
    cmds = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['/opt/google/chrome/chrome', '--version'],
    ]
    for cmd in cmds:
        out = run_cmd(cmd)
        if out:
            return out, cmd[0]
    return None, None


def main():
    system = platform.system().lower()

    if 'windows' in system:
        raw, source = get_windows_version()
        min_ver = WIN_MIN
        platform_name = 'Windows'
    elif 'darwin' in system:
        raw, source = get_macos_version()
        min_ver = MAC_MIN
        platform_name = 'macOS'
    elif 'linux' in system:
        raw, source = get_linux_version()
        min_ver = LINUX_MIN
        platform_name = 'Linux'
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

    if not raw:
        print(f'UNKNOWN: Google Chrome not found on {platform_name}')
        sys.exit(2)

    ver = parse_ver(raw)
    if not ver:
        print(f'UNKNOWN: could not parse Chrome version from: {raw}')
        sys.exit(2)

    if cmp_ver(ver, min_ver) < 0:
        print(f'VULNERABLE: {platform_name} Chrome {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} found at {source}; requires >= {min_ver[0]}.{min_ver[1]}.{min_ver[2]}.{min_ver[3]}')
        sys.exit(1)
    else:
        print(f'PATCHED: {platform_name} Chrome {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} found at {source}; meets >= {min_ver[0]}.{min_ver[1]}.{min_ver[2]}.{min_ver[3]}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, reconcile the ID first: the live record is CVE-2026-11193. Then pull a managed-browser version report, identify every endpoint below 149.0.7827.53 (and 149.0.7827.54 on macOS), and roll those systems into your standard browser update motion; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, though any healthy Chrome program should close this far sooner as routine hygiene. If you still permit Chrome-stored workforce passwords, optionally tighten policy on privileged or crown-jewel domains now, and use the noisgate remediation SLA outer bound of ≤365 days for documented exceptions only.

Sources

  1. Google Chrome stable channel desktop advisory
  2. CVE-2026-11193 aggregation with CNA, EPSS, CWE, and CISA-ADP details
  3. CISA Known Exploited Vulnerabilities Catalog
  4. Chrome Enterprise policy: PasswordManagerEnabled
  5. Chrome Enterprise policy: PasswordManagerBlocklist
  6. Google Chrome Help: Update Google Chrome
  7. Chrome Enterprise Admin help: View Chrome version details
  8. CERT-FR advisory covering affected desktop version floors
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.