← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11151 · 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 the deadbolt failing after the intruder is already in the hallway

CVE-2026-11151 is an input-validation flaw in Chrome Password Manager that affects Google Chrome versions earlier than 149.0.7827.53. The authoritative record published on 2026-06-04 says exploitation requires a remote attacker to have already compromised the renderer process, then use a crafted HTML page to *potentially* turn that foothold into a sandbox escape. For defenders, that means this is not a stand-alone drive-by; it is a chainable browser post-compromise primitive.

The vendor/CISA-ADP 7.5 HIGH score captures the *possible* end impact, but it overshoots enterprise patch priority when you audit the real attack path. The decisive friction is the prerequisite renderer compromise: the attacker needs another browser bug first, plus user interaction, and there is no KEV listing, no public exploitation evidence, and a very low EPSS. That pushes this down into MEDIUM in real-world fleet prioritization, even though it remains strategically interesting to browser exploit developers.

"A useful second-stage Chrome escape, but it is not a clean-state one-click compromise"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker content

The attacker first needs a user to open or interact with a malicious HTML page. This is the delivery stage for the later chain, typically via phishing, malvertising, or a compromised site. The page by itself is not enough to realize the full impact described for this CVE.
Conditions required:
  • User is running Chrome older than 149.0.7827.53
  • User visits attacker-controlled or attacker-influenced content
  • Chrome Password Manager feature set is present on the endpoint
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Enterprise URL filtering, Safe Browsing, DNS filtering, and email controls often kill the lure before execution
Detection/coverage: Secure web gateways, email gateways, and browser telemetry may catch the lure. Vulnerability scanners can only confirm Chrome version, not whether this stage was reachable.
STEP 02

Gain a renderer foothold with a separate bug

The published CVE description explicitly requires that the attacker has already compromised the renderer process. In practice, that means a separate renderer-side browser vulnerability, exploit kit stage, or memory-corruption primitive must fire first. CVE-2026-11151 is therefore a second-stage building block, not the initial compromise vector.
Conditions required:
  • A separate exploitable renderer bug is available and reliable against the target build
  • The earlier exploit stage succeeds inside the browser sandbox
Where this breaks in practice:
  • This is the biggest downward-pressure factor: it assumes another exploit already worked
  • Modern browser hardening, site isolation, and crash telemetry reduce reliability of chained exploitation
  • EDR often sees anomalous browser child-process behavior, crash loops, or exploit mitigation events
Detection/coverage: Version scanners cannot validate this prerequisite. Detection is mainly endpoint-side: browser crash spikes, exploit protection events, and suspicious browser process trees.
STEP 03

Trigger the Password Manager weakness

With renderer control already in hand, the attacker uses a crafted HTML page to exercise the Password Manager validation flaw. The published impact is a potential sandbox escape, meaning the bug can help bridge from renderer compromise toward more meaningful host access. Public technical details are still sparse, so exact exploit mechanics are not available.
Conditions required:
  • Renderer compromise from step 2 is active
  • Target is still on a vulnerable Chrome build
  • The attacker can drive the relevant Password Manager code path
Where this breaks in practice:
  • No public PoC currently lowers opportunistic abuse
  • The affected code path may not be uniformly reachable in every browsing session or profile state
Detection/coverage: No strong network signature. Best coverage is browser version inventory plus crash/mitigation telemetry around Chrome internals.
STEP 04

Convert browser foothold into host impact

If the chain works, the attacker may escape the renderer sandbox and gain broader impact on the endpoint than a normal in-sandbox browser exploit allows. That is why the raw CVSS impact fields are high. But this outcome depends on the full chain succeeding, not on CVE-2026-11151 alone.
Conditions required:
  • Successful chaining through steps 1-3
  • No exploit prevention or application isolation breaking the chain
Where this breaks in practice:
  • Browser isolation, VDI reset models, and strong EDR materially reduce blast radius
  • Failure at any earlier stage collapses the chain
Detection/coverage: EDR is the main safety net here. Look for suspicious actions spawned from Chrome, token abuse, unexpected file drops, or browser-originated privilege boundary crossings.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusAs of 2026-06-06, I found no KEV listing and the CISA ADP/SSVC metadata shows Exploitation: none for this CVE.
Proof-of-concept availabilityI found no public PoC, no Metasploit module, and no public GitHub exploit tied to CVE-2026-11151. The Chromium issue is referenced but not publicly useful for exploit replication.
EPSS0.00047 with percentile 0.14822 on 2026-06-05 — basically background noise, not a signal of likely mass exploitation.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities catalog as of 2026-06-06.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H (7.5 HIGH). Read that as: remote delivery and high potential impact, but high complexity and user interaction required.
Critical prerequisiteThe authoritative CVE description says the attacker must have already compromised the renderer process. That is the single biggest reason this gets downgraded in operational priority.
Affected versionsGoogle Chrome earlier than 149.0.7827.53. CERT-FR also reflects packaging nuance across desktop platforms: earlier than 149.0.7827.53 for Windows/Linux and earlier than 149.0.7827.54 for Mac.
Fixed versionsPatch floor is 149.0.7827.53 on desktop Chrome, with Chrome Releases and CERT-FR indicating 149.0.7827.53/.54 depending on platform packaging.
Scanning and exposure realityThis is client-side browser software, not a server-exposed service. Shodan/Censys-style internet exposure counts are not meaningful; you need endpoint inventory or authenticated vuln scanning to measure exposure.
Disclosure and attributionPublished by the Chrome CNA on 2026-06-04. No public researcher credit was visible in the sources I reviewed.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.4/10)

The decisive factor is the renderer-compromise prerequisite: this is a post-initial-compromise browser chain component, not a clean-state remote compromise path. Chrome’s footprint keeps it relevant, but the absence of active exploitation, lack of a public PoC, and very low EPSS keep it out of the HIGH bucket.

HIGH Affected version range and fixed build floor
HIGH Downgrade rationale driven by the renderer-compromise prerequisite
MEDIUM Exploitability assessment given limited public technical detail

Why this verdict

  • Start at 7.5 HIGH: the published CVSS assumes total impact if the chain succeeds, so the baseline is fair in a vacuum
  • Major downward pressure: the attacker must have *already* compromised the Chrome renderer, which implies a prior exploit stage and makes this post-initial-access within the browser attack chain
  • More friction: exploitation needs user interaction and a crafted HTML page, so this is not a silent wormable path
  • No current threat signal: no KEV entry, SSVC says exploitation none, and EPSS 0.00047 is extremely low
  • Still not low-value: Chrome is ubiquitous and sandbox-escape primitives are strategically valuable when paired with another renderer bug

Why not higher?

Because this is not a one-bug compromise from a clean browser state. Requiring a prior renderer compromise compounds friction hard: the attacker needs another exploit first, then needs this bug to extend that foothold. That sharply narrows the reachable population and raises operational complexity.

Why not lower?

Because if an attacker already has renderer execution, a sandbox-escape-capable primitive inside Chrome is still meaningful. On a fleet with lots of Chrome usage, chained browser exploitation remains a credible risk class even when opportunistic mass exploitation is unlikely.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update policy — Use enterprise browser policy, MDM, or software distribution to pin the fleet at 149.0.7827.53/.54 or later. For a MEDIUM verdict there is no mitigation SLA, so treat this as part of the normal remediation cycle and complete it within the <=365 day remediation window.
  2. Prioritize high-risk user tiers — Move admins, developers, executives, and external-facing staff onto the patched build first because they are the most realistic browser exploit-chain targets. There is no mitigation SLA here, but risk-based acceleration inside the <=365 day remediation window is sensible.
  3. Reduce credential exposure in-browser — Where business-tolerable, restrict browser password storage/autofill for privileged accounts and service admin workflows so a successful browser chain yields less value. For this MEDIUM verdict, use it as a defense-in-depth measure during the normal remediation window rather than as an emergency containment step.
  4. Hunt for browser exploit telemetry — Review EDR and browser crash telemetry for abnormal Chrome child processes, exploit mitigation events, repeated renderer crashes, and suspicious browser-originated process launches. This does not replace patching, but it is the best available control while the fleet rolls through the <=365 day remediation cycle.
What doesn't work
  • A WAF does not meaningfully help because the vulnerable surface is the endpoint browser, not your server-side app tier.
  • A perimeter vuln scanner will miss most of the problem because Chrome is client software; you need endpoint inventory or authenticated checks.
  • Network ACLs alone do not solve this if users can still browse attacker-controlled content.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint itself or through your RMM/EDR remote script runner. Invoke it with python3 check_chrome_cve_2026_11151.py on macOS/Linux or py check_chrome_cve_2026_11151.py on Windows; no admin rights are normally required, but the account must be able to execute Chrome and read standard install paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11151.py
# Detects whether Google Chrome is below 149.0.7827.53
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple

PATCH_FLOOR = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, ...]]:
    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_version(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=10)
        if p.returncode == 0 or p.stdout:
            return p.stdout.strip()
    except Exception:
        pass
    return None


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

    if system == 'windows':
        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 paths:
            if p and os.path.exists(p):
                cmds.append([p, '--version'])
    elif system == 'darwin':
        mac_path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
        if os.path.exists(mac_path):
            cmds.append([mac_path, '--version'])
        user_mac_path = os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
        if os.path.exists(user_mac_path):
            cmds.append([user_mac_path, '--version'])
    else:
        for name in ['google-chrome', 'google-chrome-stable', '/usr/bin/google-chrome', '/opt/google/chrome/chrome']:
            resolved = shutil.which(name) if not name.startswith('/') else (name if os.path.exists(name) else None)
            if resolved:
                cmds.append([resolved, '--version'])

    return cmds


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

    if seen:
        joined = '; '.join([f'{path}: {out}' for path, out in seen])
        print(f'UNKNOWN - Chrome was found but version parsing failed: {joined}')
    else:
        print('UNKNOWN - Google Chrome not found in standard install paths or PATH')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: pull an endpoint inventory for Chrome versions and identify anything below 149.0.7827.53 (or below 149.0.7827.54 on macOS packaging where applicable), then roll those systems through your normal browser patch channel. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for this MEDIUM verdict; with disclosure on 2026-06-04, that means documenting that there is no separate mitigation deadline and meeting the noisgate remediation SLA by patching affected managed endpoints no later than 2027-06-04. In practice, because this is Chrome and easy to update, do it in your next standard browser wave rather than letting it rot in backlog hygiene.

Sources

  1. CIRCL Vulnerability Lookup: CVE-2026-11151
  2. Google Chrome Releases: Stable Channel Update for Desktop
  3. Chromium issue 501740323
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS FAQ
  6. SecurityWeek: Chrome 149 Patches 429 Vulnerabilities
  7. CERT-FR advisory on multiple Chrome vulnerabilities
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.