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

Inappropriate implementation in Passwords in Google Chrome prior to 149

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

This is a thief rifling the glove box after someone else already stole the car

The supplied description is a Chrome Passwords information-disclosure bug fixed in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS. The important catch: the described issue only matters after the attacker already has a compromised renderer process and can then use a crafted HTML page to read sensitive data from browser memory. That is a classic chain component, not a clean one-shot remote compromise.

Vendor MEDIUM 6.5 is defensible in pure CVSS terms, but it overstates the Monday-morning urgency for an enterprise fleet. The decisive downward pressure is the prerequisite stack: user must browse attacker content, the attacker must already land a separate renderer compromise, and only then can this bug leak memory. That moves it from 'internet attack surface' into 'post-initial-browser-compromise amplifier' territory.

"This is a second-stage browser chain bug, not an enterprise patch fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the target into attacker-controlled web content

The chain starts with the victim opening a malicious page or attacker-controlled content path. This CVE does not provide initial code execution by itself; it only becomes useful when paired with a separate browser exploit chain or equivalent renderer foothold.
Conditions required:
  • Target is running Chrome before 149.0.7827.53
  • User visits attacker-controlled content
  • Attacker has a separate route to renderer compromise
Where this breaks in practice:
  • Requires user interaction
  • Requires an additional exploit beyond this CVE
  • Safe Browsing, URL filtering, and browser isolation can block the first mile
Detection/coverage: Generic web filtering and secure web gateways may see the lure, but vuln scanners will not reliably infer exploitability from page visits alone.
STEP 02

Land a renderer foothold with a separate exploit

The weaponized tool here is not public for this CVE; the attacker needs a custom or separate renderer exploit first. That prerequisite is the big severity reducer because it implies the attacker already burned another browser bug or delivered a malicious extension/chain that achieved equivalent access.
Conditions required:
  • A renderer compromise exists before this CVE is used
  • Chrome sandbox and site isolation defenses are not enough to stop the earlier stage
Where this breaks in practice:
  • No public PoC for this full chain was found in the searched sources
  • Modern Chrome exploit mitigations raise the bar materially
  • EDR and browser hardening may catch or break the earlier exploit stage
Detection/coverage: Traditional vulnerability scanners do not validate renderer compromise prerequisites. Detection mostly falls to browser telemetry, EDR, crash analytics, and extension governance.
STEP 03

Abuse the Passwords flaw to read process memory

Once inside the renderer context, the attacker can use a crafted HTML page to trigger the Passwords bug and pull sensitive data from process memory. The practical concern is credential-adjacent data or password-related material becoming accessible beyond what the renderer should normally expose.
Conditions required:
  • Renderer process already compromised
  • Vulnerable Chrome build present
  • Passwords-related data resident in accessible process memory
Where this breaks in practice:
  • Memory disclosure scope depends on runtime state, not just version
  • Site Isolation and process separation reduce cross-site spill paths
  • Not every session will have high-value password material resident
Detection/coverage: Version scanners can identify vulnerable builds, but they cannot tell whether exploitable memory state is present. No dependable network signature exists.
STEP 04

Harvest and exfiltrate usable secrets

If the memory disclosure yields credentials or related sensitive artifacts, the attacker can exfiltrate them and pivot into SaaS accounts or internal apps. At that point the business impact can be real, but it is still downstream of a much harder earlier browser compromise.
Conditions required:
  • Sensitive data is successfully recovered from memory
  • Attacker has outbound exfiltration path
Where this breaks in practice:
  • Exfiltrated data may be partial or stale
  • MFA and conditional access can blunt stolen-password value
  • Credential managers outside the browser reduce blast radius
Detection/coverage: DLP, browser telemetry, CASB, and identity anomaly detection may catch follow-on abuse better than they catch the memory leak itself.
03 · Intelligence Metadata

The supporting signals.

Record mismatchYour intel block's description/CVSS matches CVE-2026-11209, while Google's June 2, 2026 Chrome 149 release shows CVE-2026-11271 as a separate Low Passwords issue. This assessment follows the *supplied description* because that's the exploit story you asked to reassess.
In-the-wild statusNo evidence of active exploitation found in searched primary sources, and it is not in CISA's Known Exploited Vulnerabilities catalog.
Proof-of-concept availabilityNo public PoC or weaponized exploit chain for the supplied renderer-compromise memory disclosure was found in the searched sources. That matters because this bug is only valuable as a second-stage primitive.
EPSSUser-supplied EPSS is 0.00028, which is effectively floor-level. FIRST describes EPSS as a 30-day exploitation probability estimate in its overview and API documentation.
KEV statusNot KEV-listed. No CISA due date, no federal emergency signal, no immediate-exploitation override.
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N says remote, low complexity, no privileges, but user interaction required and confidentiality-only impact. CVSS does not capture the crucial real-world prerequisite that the attacker already compromised the renderer.
Affected versionsChrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS per Google's stable-channel advisory.
Fixed versionsUpgrade to at least 149.0.7827.53 Linux or 149.0.7827.53/54 Windows/macOS. For enterprise packaging, accept vendor-managed evergreen updates rather than waiting for distro-style backport language that does not usually apply to Chrome desktop.
Scanning and exposure realityThis is a client-side browser flaw, so Shodan/Censys/FOFA-style exposure counts are basically meaningless. The reachable population is broad in install base, but narrow in exploitability because there is no directly exposed server daemon to sweep.
Disclosure and reporterGoogle published the Chrome 149 stable update on 2026-06-02; NVD shows the CVE record received on 2026-06-04. Google's release note attributes the matching Passwords issue to Google and lists it as reported on 2026-04-25.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

The single decisive factor is the renderer-compromise prerequisite. This bug is not initial access; it is a follow-on memory disclosure that only matters after the attacker already won a much harder earlier stage inside Chrome.

HIGH Attack-path friction from the renderer-compromise prerequisite
MEDIUM Exact CVE mapping, because the supplied description appears to align to CVE-2026-11209 rather than CVE-2026-11271

Why this verdict

  • Major downgrade for attacker position: vendor starts at 6.5, but the supplied description requires a pre-existing renderer compromise. That implies prior exploitation or equivalent malicious code already running in the browser, which is strong downward pressure.
  • Reachable population is narrower than CVSS suggests: Chrome is everywhere, but this is not a naked unauthenticated remote bug that any internet host can spray. It only applies to endpoints on vulnerable versions *and* only after the attacker lands another browser stage.
  • Threat intel is cold: no KEV, no active exploitation evidence found, and EPSS is effectively near-zero. Without live-fire signals, this stays in backlog territory rather than front-of-queue emergency work.

Why not higher?

Because the exploit chain assumes a prior compromise stage that most enterprise severity models should treat as compounding friction, not as a footnote. If you need internal browser code execution first, you are grading a chain component, not a standalone enterprise-breaker.

Why not lower?

Because the impacted component is Passwords, and the stated effect is sensitive memory disclosure. Even as a second-stage bug, a successful chain could expose credentials or adjacent secrets that materially help lateral SaaS or identity abuse.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome evergreen compliance — Make sure endpoints are actually receiving Chrome auto-updates and are not pinned below 149.0.7827.53. For a LOW verdict there is no SLA; treat as backlog hygiene, but browser drift is unnecessary risk and should be cleaned up in the next normal compliance sweep.
  2. Reduce browser-stored credential exposure for privileged users — For admins, help desk, and high-value operators, prefer enterprise password managers or hardened identity flows over storing broad credential sets in the browser. For LOW, there is no SLA; treat as backlog hygiene, but this sharply reduces the payoff if a browser chain succeeds.
  3. Tighten extension and browsing controls — Use Safe Browsing, extension allowlisting, remote browser isolation where justified, and web filtering to make the prerequisite renderer-compromise stage harder to achieve. For LOW, there is no SLA; treat as backlog hygiene, but these controls hit the attack path earlier than this specific patch does.
What doesn't work
  • Perimeter vulnerability scanning does not meaningfully reduce risk here; this is a client-side browser issue, not an exposed server listener.
  • A WAF does not solve the problem; there is no single inbound enterprise web app to shield from exploitation.
  • Credential rotation alone is weak as a primary control because it does nothing to stop the initial browser compromise chain.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory/EDR remote script runner. Invoke it with python3 check_chrome_149.py on macOS/Linux or py check_chrome_149.py on Windows; it needs only standard user rights and reports VULNERABLE, PATCHED, or UNKNOWN based on the installed Chrome version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_149.py
# Detect whether locally installed 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

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    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, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def compare_versions(a, b):
    return (a > b) - (a < b)


def get_windows_version():
    # Try registry first
    try:
        import winreg
        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:
                with winreg.OpenKey(hive, path) as key:
                    val, _ = winreg.QueryValueEx(key, 'version')
                    ver = parse_version(str(val))
                    if ver:
                        return ver, f'registry:{path}'
            except OSError:
                pass
    except Exception:
        pass

    # Fall back to executable --version
    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%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, ''


def get_macos_version():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/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, ''


def get_linux_version():
    cmds = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['/opt/google/chrome/chrome', '--version'],
    ]
    for cmd in cmds:
        exe = cmd[0]
        if os.path.isabs(exe) and not os.path.exists(exe):
            continue
        if not os.path.isabs(exe) and shutil.which(exe) is None:
            continue
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver, exe
    return None, ''


def main():
    system = platform.system().lower()
    if 'windows' in system:
        ver, source = get_windows_version()
    elif 'darwin' in system:
        ver, source = get_macos_version()
    elif 'linux' in system:
        ver, source = get_linux_version()
    else:
        print('UNKNOWN - unsupported platform')
        sys.exit(2)

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

    current = '.'.join(str(x) for x in ver)
    fixed = '.'.join(str(x) for x in FIXED)

    if compare_versions(ver, FIXED) < 0:
        print(f'VULNERABLE - installed Chrome {current} from {source}; fixed version is {fixed} or later')
        sys.exit(1)
    else:
        print(f'PATCHED - installed Chrome {current} from {source}; fixed baseline is {fixed}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: do not let the vendor's medium tag cut the patch queue. Because this reassessment lands at LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA beyond treating it as backlog hygiene; verify Chrome auto-update health, identify endpoints still below 149.0.7827.53, and let normal evergreen browser maintenance burn it down rather than launching an emergency sprint. The one caveat is the record mismatch: validate whether your tooling means the supplied renderer-compromise memory leak (mapping to CVE-2026-11209) or the actual CVE-2026-11271 Passwords UI issue before you open tickets.

Sources

  1. Google Chrome Releases: Stable Channel Update for Desktop (Chrome 149)
  2. NVD detail for CVE-2026-11209
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS overview
  5. FIRST EPSS API documentation
  6. Chromium Security overview
  7. Chromium Site Isolation overview
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.