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

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 an interior office door, not an open front gate

CVE-2026-11251 is a Chrome Password Manager policy-enforcement flaw affecting desktop Chrome before 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. Per NVD, the attacker must already have compromised the renderer process and then use a crafted HTML page to bypass a discretionary access-control check in Password Manager; this is not a clean unauthenticated web-to-host bug by itself.

Google's LOW 3.1 label is already restrained, and in enterprise triage reality the case gets weaker, not stronger. The decisive friction is the prerequisite: a renderer compromise means the attacker already burned or chained another browser bug first, so this CVE is mostly a post-exploitation amplifier inside an existing browser compromise, with limited standalone prioritization value and no current exploitation evidence.

"This is a post-compromise browser chain link, not a stand-alone enterprise fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Win code execution inside the renderer

The attacker first needs a separate browser exploit, malicious extension path, or equivalent chain that yields control of Chrome's renderer process. This CVE does not provide that foothold; it only matters after the attacker is already executing in a constrained browser process. In practice the weaponized tool here is a separate browser exploit chain, not CVE-2026-11251 itself.
Conditions required:
  • Victim is running vulnerable Chrome prior to 149.0.7827.53
  • Attacker has a working renderer compromise path
  • Victim reaches attacker-controlled web content or another compromise vector
Where this breaks in practice:
  • Renderer compromise is a major prerequisite and usually the hardest part of the chain
  • Modern Chrome hardening, sandboxing, Site Isolation, and rapid auto-update reduce exploit reliability
  • No public PoC or in-the-wild chain is currently documented for this CVE
Detection/coverage: This step is usually detected, if at all, by browser exploit telemetry, EDR child-process anomalies, crash clustering, and Safe Browsing signals; generic vuln scanners do not prove renderer compromise.
STEP 02

Trigger Password Manager policy bypass logic

With renderer control, the attacker uses a crafted HTML page to reach the flawed Password Manager code path and bypass a discretionary access-control decision. The NVD description frames the effect as bypassing access control, while the Chrome advisory classifies it as a low-severity Password Manager validation issue. The likely weaponized artifact is a malicious page embedded in the broader exploit chain.
Conditions required:
  • Renderer is already attacker-controlled
  • Password Manager functionality is present and reachable in the victim session
  • The targeted policy edge case is hit successfully
Where this breaks in practice:
  • The bug appears constrained to a narrow browser-internal policy path
  • Impact is confidentiality-limited rather than code-execution or sandbox-escape level
  • Real exploit development must align renderer state, UI state, and the affected password flow
Detection/coverage: No reliable network signature is expected. Browser forensic telemetry may show suspicious page flows, but commodity scanners generally only identify version exposure.
STEP 03

Access data or capability gated by the policy

If successful, the attacker gains access to data or actions that the Password Manager policy should have blocked. The published CVSS reflects only low confidentiality impact and no integrity or availability impact, which is consistent with a narrow disclosure-style outcome rather than credential vault exfiltration at scale. The practical blast radius is the active browser context and user profile already under attack.
Conditions required:
  • Target user has relevant Password Manager data or state
  • Attacker remains inside the compromised browsing session
Where this breaks in practice:
  • No evidence the bug yields unrestricted password dump capability
  • Per-user scope limits enterprise-wide blast radius
  • Any meaningful follow-on still depends on the pre-existing browser compromise
Detection/coverage: Browser telemetry and user-profile access monitoring may help, but no mainstream signature-based detection is specific to this CVE.
STEP 04

Chain into broader account abuse

The attacker can only turn this into meaningful business impact if the previously compromised browser session already has valuable authenticated contexts. That makes this CVE a chain enhancer for phishing-resistant account takeover or session abuse scenarios, not an initial-access event by itself. The real risk comes from the preceding exploit and the value of the victim's active session.
Conditions required:
  • Victim session contains valuable credentials, autofill context, or authenticated applications
  • Attacker has operational control long enough to monetize the access
Where this breaks in practice:
  • Enterprise SSO, conditional access, and downstream MFA still limit follow-on abuse
  • Lack of code execution or sandbox escape from this CVE keeps the impact bounded
  • No known campaign evidence suggests attackers currently prefer this bug
Detection/coverage: Downstream detection is more likely in IdP logs, impossible-travel controls, SaaS detections, and EDR telemetry than in CVE-specific browser signatures.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found. CISA KEV does not list this CVE, and Google did not flag it as exploited in the stable-channel advisory.
Proof-of-concept availabilityNo public PoC located. The referenced Chromium issue 498301853 exists, but Chrome notes that bug details may remain restricted until most users are patched.
EPSS0.00026 supplied in the intel block — effectively negligible predicted exploitation pressure.
KEV statusNot KEV-listed as of the CISA catalog checked for this assessment.
CVSS vector reality checkAV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N is directionally fair, but it still understates the real friction because the published description also requires a renderer compromise first.
Affected versionsDesktop Google Chrome before 149.0.7827.53; NVD models this across Windows, macOS, and Linux Chrome installs.
Fixed versionsPatched in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS in Google's June 2, 2026 stable release.
Exposure / scanning realityNot internet-scannable in the normal sense. Shodan/Censys-style external exposure counts are not useful because this is a client-side browser flaw, not a remotely enumerable network service.
Disclosure timelineChrome shipped the fix on 2026-06-02; NVD shows the CVE record published on 2026-06-04 and modified on 2026-06-05.
Researcher / reporterGoogle credits the issue as reported by Google on 2026-03-31 in the Chrome stable advisory.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to LOW (1.8/10)

The single biggest severity suppressor is the prerequisite of an existing renderer compromise. That means this CVE is not an initial-access browser bug for most enterprises; it is a narrow post-compromise policy bypass with low standalone blast radius and no active-exploitation signal.

HIGH Version range and vendor metadata
HIGH Assessment that this is post-initial-access due to renderer-compromise requirement
MEDIUM Practical impact inside Password Manager because the public bug details remain restricted

Why this verdict

  • Major downward adjustment: requires renderer compromise first — attacker position is neither clean unauthenticated remote nor simple user-click exploitation; it implies a prior browser exploit or equivalent foothold has already succeeded.
  • **Reachable population is broad, but reachable *attack path* is narrow** — Chrome is everywhere, yet only already-compromised renderer contexts can exercise this bug, which sharply cuts real-world exploitability.
  • Low-confidence monetization path — public metadata only supports low confidentiality impact, with no integrity/availability impact, no KEV listing, and no public PoC or campaign evidence.

Why not higher?

It is not higher because the bug is not a stand-alone drive-by compromise. Requiring prior renderer compromise compounds multiple layers of friction: an attacker must already beat Chrome's front-line defenses, then successfully hit a narrow Password Manager policy path, then still extract enough value to matter.

Why not lower?

It is not IGNORE because Password Manager touches sensitive user data and Chrome is extremely widespread. If you are already running disciplined browser patching, this fix should still ride the normal evergreen compliance process rather than being written off completely.

05 · Compensating Control

What to do — in priority order.

  1. Enforce rapid Chrome auto-update compliance — Make sure enterprise policy does not leave desktop Chrome pinned below 149.0.7827.53; for a LOW verdict there is no SLA, so treat this as backlog hygiene and absorb it in the next normal browser compliance sweep.
  2. Reduce browser attack-surface add-ons — Limit unapproved extensions and high-risk browser features through enterprise policy because the meaningful prerequisite is prior renderer compromise; reducing the number of viable browser footholds is the best indirect control. For LOW, fold this into routine hardening work rather than emergency change.
  3. Monitor for browser-compromise indicators — Tune EDR and proxy telemetry for suspicious Chrome child processes, crash bursts, and access to credential stores because any attack using this CVE has likely already crossed into a broader browser exploit chain. For LOW, add this in your normal engineering queue, not as a break-fix action.
  4. Prefer IdP-side controls over browser-only trust — Strengthen MFA, device trust, and session-risk controls because the business harm here comes from abusing an already-compromised authenticated browser session. That reduces payoff even if a browser chain reaches Password Manager internals.
What doesn't work
  • A perimeter WAF does not meaningfully help because the target is a local browser code path, not an exposed enterprise web service.
  • Network vulnerability scanning does not prove safety because this is a client-side version problem with no externally enumerable socket or banner.
  • Password rotation by itself does not address the browser exploit prerequisite and does nothing for session theft or active authenticated abuse.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your RMM/EDR script runner. Invoke it as python3 check_cve_2026_11251.py for auto-detection, or python3 check_cve_2026_11251.py --path "/usr/bin/google-chrome"; user-level rights are usually enough, but Windows registry reads may work more reliably with standard local-user access to installed app metadata.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check Google Chrome version for CVE-2026-11251
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

TARGET = (149, 0, 7827, 53)

def norm(ver):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', ver or '')
    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:
        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 detect_from_arg():
    if '--path' in sys.argv:
        try:
            idx = sys.argv.index('--path')
            path = sys.argv[idx + 1]
            out = run_cmd([path, '--version'])
            if out:
                return ('path', out)
        except Exception:
            return ('path', None)
    return None

def detect_linux():
    candidates = [
        'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser'
    ]
    for c in candidates:
        out = run_cmd([c, '--version'])
        if out and 'Chrome' in out or out and 'Chromium' in out:
            return (c, out)
    return (None, None)

def detect_macos():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
    ]
    for c in candidates:
        if os.path.exists(c):
            out = run_cmd([c, '--version'])
            if out:
                return (c, out)
    return (None, None)

def detect_windows():
    candidates = []
    for base in [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]:
        if base:
            candidates.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
    for c in candidates:
        if c and os.path.exists(c):
            ps = [
                'powershell', '-NoProfile', '-Command',
                f"(Get-Item '{c}').VersionInfo.ProductVersion"
            ]
            out = run_cmd(ps)
            if out:
                return (c, out)
    try:
        import winreg  # type: ignore
        keys = [
            r'SOFTWARE\Google\Chrome\BLBeacon',
            r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'
        ]
        for hive in [winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE]:
            for key in keys:
                try:
                    with winreg.OpenKey(hive, key) as k:
                        version, _ = winreg.QueryValueEx(k, 'version')
                        if version:
                            return ('registry', version)
                except Exception:
                    pass
    except Exception:
        pass
    return (None, None)

def main():
    res = detect_from_arg()
    if res:
        source, out = res
    else:
        system = platform.system().lower()
        if system == 'windows':
            source, out = detect_windows()
        elif system == 'darwin':
            source, out = detect_macos()
        else:
            source, out = detect_linux()

    if not out:
        print('UNKNOWN - Could not detect Chrome/Chromium version')
        sys.exit(2)

    ver = norm(out)
    if not ver:
        print(f'UNKNOWN - Unparseable version string from {source}: {out}')
        sys.exit(2)

    if cmp_ver(ver, TARGET) < 0:
        print(f'VULNERABLE - Detected version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} < 149.0.7827.53')
        sys.exit(1)
    else:
        print(f'PATCHED - Detected version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} >= 149.0.7827.53')
        sys.exit(0)

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

If you remember one thing.

TL;DR
Monday morning: do not treat CVE-2026-11251 like an emergency browser zero-day. Keep it in your normal Chrome evergreen hygiene lane, verify endpoints are drifting to 149.0.7827.53+, and spend urgent attention on any upstream renderer-compromise bugs instead; for this LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so fold the fix into the next standard browser compliance cycle and document any deferred stragglers rather than launching a special patch campaign.

Sources

  1. NVD CVE-2026-11251
  2. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  3. Chromium issue 498301853
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS
  6. FIRST EPSS Model
  7. Chromium Security
  8. Chromium Site Isolation
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.