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

Inappropriate implementation in Password Manager in Google Chrome prior to 149

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

This is a peephole drilled through the wall of the browser’s same-origin apartment building

CVE-2026-11084 is an *inappropriate implementation* flaw in Chrome's Password Manager that affects Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS. Per the vendor description, a remote attacker can use crafted web content to leak cross-origin data, which means a hostile site can potentially read data that should have remained isolated to a different site or origin boundary inside the browser context.

Google tagged it *Medium* at 6.5, and that is understandable from a pure CVSS lens because it is confidentiality-only and still needs user interaction. For enterprise defenders, I would bump it to *HIGH* anyway: Chrome is everywhere, delivery is just normal browsing, and the vulnerable component is Password Manager-adjacent, which turns a 'mere data leak' into a likely credential and session exposure problem on high-value user endpoints.

"Medium on paper, high in practice: a drive-by browser bug touching saved secrets on one of the most deployed apps you own."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the user to attacker-controlled web content

The attacker weaponizes a malicious page or ad-driven landing page and waits for a Chrome user on a vulnerable build to render it. No foothold on the endpoint is required; the browser is the entry point. The practical 'tool' here is just crafted HTML/JavaScript delivered over the web, with Chrome itself as the interpreter.
Conditions required:
  • Target is running Chrome before 149.0.7827.53
  • User visits attacker-controlled or attacker-influenced content
  • JavaScript and normal browser features are available
Where this breaks in practice:
  • Requires user interaction (UI:R), so it is not wormable
  • Web filtering, DNS filtering, and ad blocking reduce reach
  • Attackers still need a reliable lure or compromised site/ad supply chain
Detection/coverage: Network security tools may log the visit, but they generally will not see the browser-internal data boundary failure. Standard vuln scanners can identify outdated Chrome versions on managed endpoints, but they cannot validate exploitability in-session.
STEP 02

Trigger the Password Manager implementation flaw

Once the page is loaded, the attacker attempts to drive the vulnerable Password Manager code path that mishandles origin isolation. The likely weaponized primitive is DOM and navigation choreography via crafted page content rather than a memory corruption exploit. No public exploit chain was located, but the vendor description explicitly says the issue can leak cross-origin data.
Conditions required:
  • The vulnerable Password Manager path is reachable from web content
  • The victim browser state contains useful origin-separated data
Where this breaks in practice:
  • The bug class is narrower than a generic renderer RCE
  • Success may depend on browser state, saved credentials, or specific site interaction patterns
  • Chrome may retain bug details under restriction until most users update
Detection/coverage: There is usually no strong host-based signature for this step. Browser crash telemetry is not the right signal because this is described as a logic/implementation leak, not a memory-safety crash.
STEP 03

Exfiltrate cross-origin secrets

If the boundary failure succeeds, the attacker can pull data that should have been protected by same-origin rules and send it off-origin using ordinary web requests. In the worst case, that includes password-manager-related values, autofill-adjacent metadata, or session-bearing data useful for account compromise. The exfiltration channel is boring by design: fetch, XHR, or beacon-style requests.
Conditions required:
  • Sensitive data is present in the victim browser context
  • Outbound HTTPS to attacker infrastructure is allowed
Where this breaks in practice:
  • Blast radius is usually one browsing session and one user, not fleet-wide server takeover
  • Data value depends on what the user has stored and what sites they use
  • Some outbound controls or browser isolation products can blunt exfiltration
Detection/coverage: Proxy and CASB tooling may see suspicious outbound destinations, but not necessarily the stolen payload semantics. DLP may help only if the exfiltrated material matches known patterns.
STEP 04

Convert leak into account access

The attacker uses the stolen data for follow-on actions such as credential stuffing, session hijack, or targeted phishing with highly specific context. This is where a browser 'data leak' becomes an enterprise incident, especially on privileged or SaaS-heavy user populations. The post-exfiltration tooling is standard identity abuse, not browser exploitation.
Conditions required:
  • Leaked data includes credentials, tokens, or actionable sensitive content
  • Target accounts lack strong session protections
Where this breaks in practice:
  • MFA, device binding, and conditional access can break token reuse and password-only abuse
  • Many leaked artifacts may still require additional attacker work to monetize
Detection/coverage: Identity telemetry is often the first high-confidence signal: impossible travel, new device registration, token replay anomalies, or abnormal SaaS activity.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation evidence located in authoritative public sources reviewed; not KEV-listed.
Proof-of-concept availabilityNo public PoC or exploit repo was located. Chromium issue details appear access-restricted, which is common until patch adoption improves.
EPSS0.00035 from the intel provided — effectively low predicted mass exploitation likelihood.
KEV statusNot present in the CISA KEV catalog as of the public catalog state reviewed.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remote delivery over the web, no auth needed, but user browsing is required and impact is confidentiality-heavy rather than system compromise.
Affected versionsGoogle states Chrome prior to 149.0.7827.53 is affected; the desktop stable post lists 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/Mac as the fixed line.
Fixed versionsUpgrade to at least 149.0.7827.53 on Linux and 149.0.7827.53 or .54 on Windows/macOS, depending on the channel rollout. I did not locate a separate distro-backport advisory for this CVE; use your downstream package changelog if you do not deploy Google's builds directly.
Exposure populationChrome is one of the largest endpoint populations in most enterprises, which amplifies operational risk even though this is *client-side* rather than Internet-facing server software.
Scanning / exposure dataInternet scanners like Shodan/Censys/GreyNoise are a poor fit here because this is not an Internet-exposed service flaw. Exposure must be measured from endpoint inventory, EDR, MDM, package management, or browser enterprise telemetry.
Disclosure and reporterDisclosed 2026-06-04; Chrome release notes say it was reported by Google on 2026-04-06.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to HIGH (7.4/10)

The decisive amplifier is mass reach on a ubiquitous client application with web-only delivery: an attacker only needs a user to browse. I upgraded this because the flaw sits in Password Manager territory, where a confidentiality bug can directly turn into credential or session theft on business-critical endpoints.

MEDIUM Severity reassessment versus Google's MEDIUM baseline
HIGH Affected version boundary and fixed build identification
MEDIUM Assessment that public exploitation is not currently evidenced

Why this verdict

  • Upward pressure: browser ubiquity — Chrome is a near-universal enterprise endpoint application, so a web-delivered client bug has a much larger reachable population than a niche desktop app.
  • Upward pressure: sensitive data class — this is a Password Manager issue with cross-origin leakage, so the likely business impact is stolen secrets, credentials, or session-bearing data rather than harmless page data.
  • Downward pressure: requires user browsing — the attacker needs the victim to render hostile content, which means phishing, malvertising, or site compromise still has to do real work first.
  • Downward pressure: no auth but no code execution — this is not a straight remote code execution or sandbox escape; the blast radius is usually one user context at a time.
  • Downward pressure: no KEV / no public exploit evidence — absent active exploitation or a mature PoC, this does not justify a CRITICAL label.

Why not higher?

I did not score this as CRITICAL because the attack path still needs user interaction and the public description points to data leakage, not arbitrary code execution or fleet-wide takeover. It is also not backed by KEV listing or known in-the-wild exploitation, which removes the biggest urgency multiplier.

Why not lower?

I did not leave this at MEDIUM because CVSS undersells what *Password Manager + cross-origin leak + browser ubiquity* means operationally. In a 10,000-host enterprise, a web-delivered secret-exposure bug on the dominant browser is not backlog filler.

05 · Compensating Control

What to do — in priority order.

  1. Block outdated Chrome builds — Use EDR, MDM, or software inventory policy to identify and quarantine browsers older than 149.0.7827.53; for a HIGH verdict, deploy this control within 30 days if patch rollout lags. This is the cleanest temporary reduction because it targets the vulnerable population directly.
  2. Force browser auto-update compliance — Verify enterprise update channels are enabled and not pinned below the fixed build; enforce policy drift correction within 30 days. Chrome moves fast, and stale channels are what turn browser vulns into long-tail exposure.
  3. Harden web filtering for high-risk categories — Tighten controls on newly registered domains, ad-tech-heavy destinations, and uncategorized sites within 30 days. This does not fix the bug, but it cuts the most likely delivery paths for crafted content.
  4. Prioritize privileged and SaaS-heavy users — Patch and verify admins, finance, executives, developers, and users with broad SaaS access first, within 30 days. If this bug leaks secrets, those users provide the highest-value downstream account takeover opportunities.
  5. Watch for identity follow-on signals — Increase monitoring for anomalous sign-ins, token replay, and unusual SaaS actions within 30 days. This is where a browser data leak is most likely to surface if initial web telemetry misses it.
What doesn't work
  • A WAF does not meaningfully help; the vulnerable component is the client browser, not your server.
  • Generic network perimeter patch scanning will miss most of the problem because Chrome is endpoint software and not Internet-exposed infrastructure.
  • Relying on MFA alone is not sufficient if the leak yields reusable session material or origin-scoped secrets rather than just a password.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it as python3 check_cve_2026_11084.py on macOS/Linux or py check_cve_2026_11084.py on Windows; standard user rights are usually enough because it only reads installed Chrome version data.

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

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

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 run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def check_windows():
    candidates = [
        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 exe in candidates:
        if exe and os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, exe
    return None, None


def check_macos():
    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 os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, exe
    return None, None


def check_linux():
    commands = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
    ]
    for cmd in commands:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver, ' '.join(cmd[:-1])
    return None, None


def main():
    system = platform.system().lower()
    if 'windows' in system:
        ver, source = check_windows()
    elif 'darwin' in system:
        ver, source = check_macos()
    else:
        ver, source = check_linux()

    if not ver:
        print('UNKNOWN: Google Chrome version not found')
        sys.exit(2)

    version_str = '.'.join(str(x) for x in ver)
    fixed_str = '.'.join(str(x) for x in FIXED)

    if ver < FIXED:
        print(f'VULNERABLE: detected Chrome {version_str} via {source}; fixed version is {fixed_str} or newer')
        sys.exit(1)
    else:
        print(f'PATCHED: detected Chrome {version_str} via {source}; fixed threshold is {fixed_str}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a HIGH client-side exposure and clear the stale-browser population fast: identify every endpoint running Chrome below 149.0.7827.53, prioritize privileged and SaaS-heavy users first, and put temporary controls in place for holdouts. Per the noisgate mitigation SLA, deploy compensating controls within 30 days; per the noisgate remediation SLA, complete the actual browser upgrade within 180 days — but in practice, for a mainstream browser carrying a Password Manager cross-origin leak, most mature teams should finish the patch rollout well before that outer boundary.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue tracker - Issue 500124500
  3. NVD - CVE-2026-11084
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS
  6. GreyNoise Vulnerability Prioritization FAQ
  7. Shodan Help Center - Understanding Shodan Vulnerability Assessment
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.