← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11193 · 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 a bad lock on one desk drawer, not a master key to the building

CVE-2026-11193 is an *insufficient policy enforcement* flaw in Chrome Password Manager. Google says Chrome versions *before* 149.0.7827.53 are affected; the stable desktop release shipped as 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS. The attack is delivered through a crafted HTML page, so the vulnerable component is the browser endpoint, not an internet-facing server.

Google's 6.5 MEDIUM is basically fair, and if anything slightly generous for enterprise prioritization. The downdraft is simple: exploitation requires a user to land on attacker content, the bug sits inside a specific feature area of the browser, and the published scoring shows *no confidentiality or integrity impact*—only availability. That makes this an endpoint hygiene problem, not an emergency incident-driver.

"A browser bug with giant reach but small blast radius: user-driven, feature-scoped, and no exploitation signal"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a crafted page

The attacker needs a user running vulnerable Chrome to open attacker-controlled HTML. In practice that means phishing, malvertising, a compromised site, or some other web-content delivery path. There is no public weaponized kit tied to this CVE yet; this is currently a *custom HTML lure* problem, not a commodity exploit-pack problem.
Conditions required:
  • Victim uses Chrome older than 149.0.7827.53
  • Attacker can get the victim to browse attacker-controlled content
  • Normal web access from the endpoint is allowed
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Email gateway, web filtering, Safe Browsing, and user training all cut into delivery success
  • No public PoC or exploit kit lowers opportunistic abuse
Detection/coverage: Traditional network scanners are weak here. Detection is mostly *browser version inventory* plus web-phishing telemetry from email gateway, proxy, Safe Browsing, and EDR browser telemetry.
STEP 02

Trigger Password Manager policy bypass

Once the page is opened, the attacker attempts to exercise the policy-enforcement flaw inside Chrome Password Manager. The public advisory is sparse and the Chromium bug is still restricted, so the exact primitive is not fully documented. What we do know is that the issue is scoped to Password Manager and maps to CWE-284 rather than memory corruption or sandbox escape.
Conditions required:
  • Password Manager code path is present and reachable on the endpoint
  • The vulnerable browser build has not updated
  • The crafted page reaches the relevant browser state
Where this breaks in practice:
  • Many enterprises disable or de-emphasize Chrome Password Manager in favor of third-party vaults
  • Managed browser policy can reduce feature availability
  • Restricted bug details slow copycat exploit development
Detection/coverage: There is no reliable signature-based scanner for the runtime condition. Treat this as a *version-and-policy* exposure: inventory Chrome version and PasswordManagerEnabled policy state.
STEP 03

Cause local browser-side impact

The published CVSS vector assigns *availability high* and *confidentiality/integrity none*, which strongly suggests the practical outcome is disruption of password-manager behavior rather than credential theft or browser-to-OS takeover. Think broken password flows, local feature denial, or workflow interruption on the user profile, not domain compromise.
Conditions required:
  • Exploit reaches the vulnerable code path successfully
  • Victim browser profile is the one using the affected feature
Where this breaks in practice:
  • Impact appears limited to the local browser context
  • No evidence of privilege escalation, code execution, or cross-host spread
  • EDR and browser restart/update can collapse persistence of the condition
Detection/coverage: Helpdesk reports of broken credential autofill/passkey/password-manager behavior may be your first signal. EDR/browser crash telemetry may help, but coverage will be inconsistent.
STEP 04

Translate into business pain

In enterprise terms, this becomes a *user productivity and support-load* event, not a broad compromise path. The realistic downside is localized endpoint disruption, possible friction around sign-in workflows, and more tickets if a campaign targets many users. It is annoying at scale, but still materially below browser RCE or sandbox-escape class bugs.
Conditions required:
  • Enough users are exposed to the lure content
  • Affected users rely on Chrome Password Manager or related browser credential UX
Where this breaks in practice:
  • Blast radius is per-user and per-browser profile
  • No internet-facing service exposure to mass-scan
  • Auto-update channels usually shrink dwell time quickly
Detection/coverage: Operationally, the best coverage is fleet patch compliance dashboards, browser version reporting, and proxy/email telemetry showing lure delivery volume.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found as of 2026-06-05. CISA ADP enrichment shows SSVC Exploitation: none.
Proof-of-concept availabilityNo public PoC located. The GitHub advisory says No known source code, and the Chromium issue remains restricted.
EPSSVery low. GitHub displays 0.016% (4th percentile); the CIRCL mirror showed 0.00016 / 3.633rd percentile on 2026-06-05. Either way, attacker demand is weak.
KEV statusNot listed in the CISA KEV Catalog as of 2026-06-05.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H — remote delivery is possible, but only with user interaction, and the published impact is *availability-only*.
Affected versionsGoogle CNA data marks Chrome earlier than 149.0.7827.53 as affected.
Fixed versionsDesktop stable shipped fixes in 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. Chrome is self-packaged, so distro-style backport guidance is generally not the planning model here.
Exposure/scanning realityThis is an *endpoint browser* issue, so Shodan/Censys/FOFA-style internet census is largely irrelevant. You need EDR, MDM, or browser-management inventory; public internet scan telemetry is not a useful exposure proxy.
Disclosure timelineChrome stable desktop update published 2026-06-02; CVE record published 2026-06-04; GitHub advisory published 2026-06-05.
Researcher / reportingPublic credit is not exposed in the advisory trail I found. The Chromium issue is restricted, so reporter attribution is currently opaque.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.7/10)

The single biggest reason this stays out of HIGH is that the chain starts with user-driven browsing to attacker content and ends with an impact that the published scoring limits to availability, not credential theft or code execution. The bug lives in a broadly deployed product, but the *actual* blast radius looks local to the browser feature and user profile, not enterprise-wide compromise.

HIGH Attack preconditions are materially narrowed by `UI:R` and browser-feature scope
MEDIUM Exact exploitation mechanics and end-state detail remain obscured by restricted Chromium bug data

Why this verdict

  • User interaction drags this down: the attacker needs a victim to load a crafted HTML page, which implies phishing, malvertising, or a compromised site rather than silent network exploitation.
  • Feature scope matters: this is in *Password Manager*, and many enterprises either disable that feature or steer users into a separate enterprise vault, shrinking the reachable population.
  • Published impact is not takeover-grade: the vendor/CISA-adjacent scoring is C:N/I:N/A:H, so this is not a browser RCE, sandbox escape, or credential disclosure bug based on the evidence currently public.
  • Exploit demand is weak right now: no KEV listing, no public PoC found, and EPSS is extremely low.
  • Exposure is endpoint-local, not server-external: there is no mass internet attack surface to sweep with commodity scanners, which sharply reduces opportunistic exploitation at scale.

Why not higher?

To justify HIGH here, I would want either *active exploitation*, a public PoC with reliable abuse, or a stronger impact class such as data theft, account compromise, or code execution. We have none of that. The chain also compounds friction: user interaction first, feature-specific reach second, then a local browser-side impact rather than an enterprise control-plane break.

Why not lower?

I am not pushing this to LOW because Chrome is everywhere and web-delivered bugs can still scale quickly once lures are in the wild. Even with weak attacker demand, a vulnerable browser fleet is a real estate problem, and the attack precondition of 'open a page' is still common enough to merit routine remediation rather than documentation-only dismissal.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update compliance — Make sure browser update policy is actually landing and that endpoints are not pinned behind broken rings. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browser compliance should be verified in your next normal endpoint cycle because dwell time is what turns browser bugs into incident volume.
  2. Audit PasswordManagerEnabled policy — If your standard is to use an enterprise password vault instead of Chrome Password Manager, verify the policy is consistently disabled across managed browsers. This does not replace patching, but it can reduce reachable exposure while you work through normal remediation.
  3. Keep Safe Browsing and web filtering on — This bug needs delivery through attacker-controlled HTML, so web-phishing controls still matter. Use them to suppress lure delivery and malicious destinations while patching proceeds under the MEDIUM 365-day remediation window.
  4. Use browser inventory, not network scans — Track version state with EDR, MDM, Chrome Browser Cloud Management, SCCM/Intune, or similar tooling. Internet-facing scanners will not tell you which users have vulnerable browser builds.
What doesn't work
  • A WAF does not help much; this is a client-side browser flaw triggered by rendered web content, not a server endpoint you can shield centrally.
  • An IPS signature is unlikely to be dependable; there is no stable published exploit pattern and the vulnerable condition sits inside browser behavior rather than a simple network protocol primitive.
  • Perimeter vulnerability scanning is the wrong instrument; Shodan/Censys-style exposure views do not inventory desktop Chrome versions in a way that drives remediation.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-inventory/EDR remote execution channel. Invoke it with python3 check_chrome_cve_2026_11193.py; no admin rights are usually needed unless your EDR wrapper requires them. The script checks common install locations on Windows, macOS, and Linux and compares the discovered browser version to the fixed baseline 149.0.7827.53.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11193.py
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

FIXED = (149, 0, 7827, 53)
CANDIDATES = []

SYSTEM = platform.system().lower()

if SYSTEM == 'windows':
    local = os.environ.get('LOCALAPPDATA', '')
    program_files = os.environ.get('ProgramFiles', '')
    program_files_x86 = os.environ.get('ProgramFiles(x86)', '')
    CANDIDATES = [
        os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(local, 'Chromium', 'Application', 'chrome.exe'),
    ]
elif SYSTEM == 'darwin':
    CANDIDATES = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
    ]
else:
    CANDIDATES = [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
        '/snap/bin/chromium',
        which('google-chrome') or '',
        which('google-chrome-stable') or '',
        which('chromium') or '',
        which('chromium-browser') or '',
    ]


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 get_version_from_binary(path):
    try:
        result = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
        output = (result.stdout or '') + ' ' + (result.stderr or '')
        return parse_version(output)
    except Exception:
        return None


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


seen = []
for candidate in CANDIDATES:
    if candidate and os.path.exists(candidate):
        ver = get_version_from_binary(candidate)
        if ver:
            seen.append((candidate, ver))

if not seen:
    print('UNKNOWN: Chrome/Chromium binary not found in common locations')
    sys.exit(2)

# Use the highest discovered version if multiple are installed.
path, version = sorted(seen, key=lambda x: x[1], reverse=True)[0]
version_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in FIXED)

if compare_versions(version, FIXED) >= 0:
    print(f'PATCHED: {path} -> {version_str} (fixed baseline {fixed_str})')
    sys.exit(0)
else:
    print(f'VULNERABLE: {path} -> {version_str} (needs >= {fixed_str})')
    sys.exit(1)
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as standard browser patching, not a fire drill. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use that as the formal deadline, but operationally you should validate Chrome auto-update health now and fold stragglers into your next endpoint/browser maintenance wave. Under the noisgate remediation SLA, have vulnerable Chrome builds remediated within 365 days, and use policy review (PasswordManagerEnabled, Safe Browsing, browser inventory) to keep exposure from lingering unnoticed.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue tracker - issue 503642586
  3. GitHub Advisory Database - GHSA-cw7x-6q47-qrj7
  4. CIRCL Vulnerability-Lookup - CVE-2026-11193
  5. NVD - CVE-2026-11193
  6. CISA Known Exploited Vulnerabilities Catalog
  7. Chrome Enterprise Help - Security and privacy policies
  8. Chrome Enterprise Help - Set up active password detection
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.