CVE-2026-11084 · Google Chrome Password Manager cross-origin data leak

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 · Compensating Control

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.

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.

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.

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.

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.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No confirmed exploitation evidence located in authoritative public sources reviewed; not KEV-listed.
Proof-of-concept availability	No public PoC or exploit repo was located. Chromium issue details appear access-restricted, which is common until patch adoption improves.
EPSS	`0.00035` from the intel provided — effectively low predicted mass exploitation likelihood.
KEV status	Not present in the CISA KEV catalog as of the public catalog state reviewed.
CVSS vector meaning	`CVSS: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 versions	Google 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 versions	Upgrade 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 population	Chrome 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 data	Internet 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 reporter	Disclosed `2026-06-04`; Chrome release notes say it was reported by Google on `2026-04-06`.

Sources.

05 · The Call

Final Verdict

↑ UPGRADED to HIGH (7.4/10)

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.

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()