← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11083 · 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 mail slot cut into the browser wall, not a front-door smash

CVE-2026-11083 is a cross-origin data leak in Google Chrome's Password Manager implementation affecting desktop Chrome versions before 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. Per the disclosed intel, the bug lets a remote attacker use a crafted HTML page to bypass intended isolation and extract data across origin boundaries, with the vulnerable component sitting in the Password Manager path rather than a memory-corruption primitive.

Google's MEDIUM is basically fair. The upside pressure is obvious: Chrome is everywhere, the attack starts from a normal webpage, and confidentiality impact is the whole point of the bug. The downside pressure is stronger in practice: there is no known in-the-wild exploitation, EPSS is near floor level, the user must be steered to attacker content, and this is an information leak rather than a clean code-exec or sandbox-escape building block.

"A browser-wide client bug with real confidentiality impact, but it still needs user browsing and has no exploitation signal."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land the victim on attacker HTML

The attacker needs the target to render a crafted web page in vulnerable Chrome. That can come from phishing, malvertising, compromised sites, or a benign site serving attacker-controlled content. Weaponized tool at this stage is just the browser itself plus a crafted HTML/JavaScript page; no exploit framework is required from the available evidence.
Conditions required:
  • Target uses Chrome earlier than 149.0.7827.53
  • Victim visits attacker-controlled or attacker-influenced content
  • JavaScript and normal browser features are permitted
Where this breaks in practice:
  • Requires *user interaction* (UI:R) rather than blind network reachability
  • Enterprise DNS/web filtering, URL rewriting, and safe browsing controls cut down delivery success
  • Auto-update shrinks the vulnerable population quickly on managed fleets
Detection/coverage: Network scanners will not see this. Detection is mostly indirect via browser version inventory, web proxy telemetry, Safe Browsing hits, phishing detections, and EDR/browser telemetry for suspicious navigation chains.
STEP 02

Trigger the Password Manager logic flaw

Once the page runs, it exercises the vulnerable Password Manager implementation to violate origin boundaries and access data it should not have. Based on the vendor text, this is a security-model failure, not memory corruption, so exploitation should be more deterministic but narrower in outcome. Public bug details are still restricted, so exact DOM/API mechanics are not yet available from primary sources.
Conditions required:
  • Victim browser is still unpatched
  • The relevant Password Manager code path is reachable in that browsing context
Where this breaks in practice:
  • Lack of public technical detail slows broad weaponization
  • Browser hardening features like site isolation and general SOP protections still limit adjacent abuse paths
  • The bug appears to target confidentiality only, which narrows attacker options
Detection/coverage: No reliable signature-based scanner coverage expected yet. Treat it as a version-and-exposure problem until browser vendors or security tooling publish specific detections.
STEP 03

Exfiltrate cross-origin data

If successful, the attacker can extract protected data from another origin and send it off-box over normal web requests. The most relevant risk is session-linked confidentiality loss inside the user's browser context, not host takeover. Tooling at this stage is ordinary JavaScript exfiltration to attacker infrastructure.
Conditions required:
  • Cross-origin data of value is present in the victim's active browser context
  • Outbound web traffic to attacker-controlled endpoints is possible
Where this breaks in practice:
  • Blast radius is generally limited to the browser/profile/session rather than the whole endpoint
  • Impact depends on what the user is already signed into and what data is exposed through the flawed path
  • CASB/SWG/DLP may catch obvious exfiltration but will not prevent the underlying browser-side read
Detection/coverage: Look for suspicious browser-originated POST/Beacon/XHR traffic after navigation to untrusted pages. DLP can occasionally catch payload leakage, but there is no dependable network-side preventative signature for the flaw itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found in the retrieved primary-source set; Google did not flag it as exploited.
KEV statusNot listed in CISA KEV as assessed; no KEV add date or due date applies.
Proof-of-concept availabilityNo public PoC located in the retrieved source set. Chromium bug details remain restricted, which is normal early in Chrome release cycles.
EPSS0.00035 from provided intel; very low exploit-likelihood signal. Percentile was not independently confirmed from retrieved FIRST output.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote, low complexity, no privileges, but user browsing is mandatory and impact is confidentiality-only.
Affected versionsChrome desktop before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS per Google's stable release advisory.
Fixed versionsUpdate to Chrome 149.0.7827.53 on Linux or 149.0.7827.53/54 on Windows/macOS. This is an upstream browser release, not a server package with distro backports.
Exposure/scanning realityNot internet-enumerable in any meaningful way. Shodan/Censys/FOFA are not the right lens for desktop browser versioning; use EDR, MDM, SCCM/Intune/Jamf, or software inventory.
Disclosure timelineChrome stable update published 2026-06-02; CVE disclosure metadata provided as 2026-06-04.
ReporterGoogle release notes attribute the finding to Google and reference Chromium issue 500095743.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.6/10)

The decisive factor is required user browsing to attacker content combined with no active exploitation signal. This is a meaningful confidentiality bug in a ubiquitous client, but it is still a client-side data leak without evidence of broad weaponization or a path to host compromise on its own.

HIGH Affected version floor and fixed release
MEDIUM Practical exploitability assessment
LOW Specific exfiltrable data scope because bug details remain restricted

Why this verdict

  • Baseline accepted: Google scored it 6.5/MEDIUM, and that is a reasonable starting point for a remote browser confidentiality bug in a massively deployed product.
  • Downward adjustment for attacker delivery: exploitation requires the victim to render attacker-controlled HTML (UI:R), which means phish/ad/malvertising success is part of the chain rather than the bug being directly reachable over the network.
  • Downward adjustment for threat signal: EPSS 0.00035, no KEV listing, and no retrieved evidence of active exploitation materially reduce patch urgency versus memory-corruption or zero-day Chrome bugs.
  • Upward adjustment for exposure population: Chrome is common across enterprise fleets, so once delivery works the reachable population can be large.
  • Downward adjustment for blast radius: this is a confidentiality leak inside browser context, not a privilege escalation, sandbox escape, or endpoint RCE; impact is serious but narrower.

Why not higher?

There is no evidence in the retrieved sources that this bug is being exploited, no KEV signal, and no public PoC accelerating copycat use. More importantly, it still depends on the victim visiting attacker content and appears limited to data disclosure rather than arbitrary code execution or device takeover.

Why not lower?

It is still a browser-origin isolation failure in a ubiquitous client, and the component named is Password Manager, which raises the value of potential disclosures even if the exact data scope is not public yet. If an attacker can reliably steal cross-origin data from normal browsing sessions, that is above backlog-only hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Verify Chrome auto-update health — Check that Google Update, enterprise browser update rings, and managed package channels are actually moving endpoints to 149.0.7827.53/54 or later. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browser self-update failures should be corrected immediately because they create silent long-tail exposure.
  2. Tighten web filtering for untrusted destinations — Use SWG/DNS filtering, Safe Browsing enforcement, and phishing controls to reduce the odds users ever load the crafted HTML that starts the chain. This is a compensating control only; for a MEDIUM finding there is no mitigation SLA, so deploy as part of normal browser-risk reduction rather than a break-glass response.
  3. Prioritize high-risk user groups — Force-update browsers first for admins, finance, executives, and users with privileged SaaS access because the value of cross-origin disclosure is much higher in those sessions. Even without a mitigation deadline, this is the best risk-weighted sequencing while you complete remediation inside the 365-day window.
  4. Inventory browser version drift — Use EDR/MDM/SCCM/Intune/Jamf to find endpoints stuck below 149.0.7827.53. This matters more than external scanning because internet-facing telemetry will not tell you which user workstations are still vulnerable.
What doesn't work
  • A WAF does not help; the vulnerable surface is the local browser rendering attacker content, not your server-side app stack.
  • Generic network vulnerability scanners will miss this in practice because desktop Chrome version exposure is not meaningfully discoverable from the internet.
  • Relying on MFA is insufficient; MFA may protect account takeover workflows, but it does not stop browser-side cross-origin data disclosure inside an already authenticated session.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-deployment/EDR tooling. Invoke it with python3 check_chrome_cve_2026_11083.py on macOS/Linux or py check_chrome_cve_2026_11083.py on Windows; standard user rights are usually enough, but Windows registry fallback may work better with local read access.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check for CVE-2026-11083 exposure by inspecting local Google Chrome version.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

THRESHOLD = (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 cmp_version(a, b):
    return (a > b) - (a < b)


def try_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return parse_version(out)
    except Exception:
        return None


def windows_version():
    candidates = [
        [r'C:\Program Files\Google\Chrome\Application\chrome.exe', '--version'],
        [r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe', '--version'],
    ]
    for cmd in candidates:
        if os.path.exists(cmd[0]):
            v = try_cmd(cmd)
            if v:
                return v, cmd[0]

    # Registry fallback
    try:
        import winreg  # type: ignore
        reg_paths = [
            (winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
            (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
            (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
        ]
        for hive, path in reg_paths:
            try:
                key = winreg.OpenKey(hive, path)
                version, _ = winreg.QueryValueEx(key, 'version')
                v = parse_version(str(version))
                if v:
                    return v, f'registry:{path}'
            except OSError:
                continue
    except Exception:
        pass

    return None, None


def mac_version():
    candidates = [
        ['/Applications/Google Chrome.app/Contents/MacOS/Google Chrome', '--version'],
        [os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'), '--version'],
    ]
    for cmd in candidates:
        if os.path.exists(cmd[0]):
            v = try_cmd(cmd)
            if v:
                return v, cmd[0]
    return None, None


def linux_version():
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['/opt/google/chrome/chrome', '--version'],
        ['/usr/bin/google-chrome', '--version'],
        ['/usr/bin/google-chrome-stable', '--version'],
    ]
    for cmd in candidates:
        exe = cmd[0]
        if '/' in exe and not os.path.exists(exe):
            continue
        v = try_cmd(cmd)
        if v:
            return v, exe
    return None, None


def main():
    system = platform.system().lower()
    version = None
    source = None

    if 'windows' in system:
        version, source = windows_version()
    elif 'darwin' in system:
        version, source = mac_version()
    else:
        version, source = linux_version()

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

    current = '.'.join(map(str, version))
    fixed = '.'.join(map(str, THRESHOLD))

    if cmp_version(version, THRESHOLD) < 0:
        print(f'VULNERABLE - Google Chrome {current} detected via {source}; fixed version is {fixed} or later')
        sys.exit(1)
    else:
        print(f'PATCHED - Google Chrome {current} detected via {source}; meets fixed version threshold {fixed}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like a Chrome zero-day fire drill; treat it like a managed browser fleet correctness check. Use endpoint inventory to find machines below 149.0.7827.53/54, confirm auto-update is not broken, and roll the fixed version through your normal browser maintenance motion; for this MEDIUM assessment there is noisgate mitigation SLA — go straight to the 365-day remediation window. In practice, you should still clean up browser update drift fast because Chrome is easy to patch, but the formal noisgate remediation SLA here is ≤365 days since there is no KEV listing or active exploitation evidence.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Chromium issue 500095743
  3. Chromium issue 500095743 (Chrome release reference context)
  4. Canadian Centre for Cyber Security advisory AV26-544
  5. FIRST EPSS API documentation
  6. FIRST EPSS overview
  7. CISA Known Exploited Vulnerabilities catalog feed
  8. FIRST CVSS resources
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.