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.
4 steps from start to impact.
Lure the target into attacker-controlled web content
- Target is running Chrome before
149.0.7827.53 - User visits attacker-controlled content
- Attacker has a separate route to renderer compromise
- Requires user interaction
- Requires an additional exploit beyond this CVE
- Safe Browsing, URL filtering, and browser isolation can block the first mile
Land a renderer foothold with a separate exploit
- A renderer compromise exists before this CVE is used
- Chrome sandbox and site isolation defenses are not enough to stop the earlier stage
- 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
Abuse the Passwords flaw to read process memory
- Renderer process already compromised
- Vulnerable Chrome build present
- Passwords-related data resident in accessible process memory
- 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
Harvest and exfiltrate usable secrets
- Sensitive data is successfully recovered from memory
- Attacker has outbound exfiltration path
- Exfiltrated data may be partial or stale
- MFA and conditional access can blunt stolen-password value
- Credential managers outside the browser reduce blast radius
The supporting signals.
| Record mismatch | Your 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 status | No evidence of active exploitation found in searched primary sources, and it is not in CISA's Known Exploited Vulnerabilities catalog. |
| Proof-of-concept availability | No 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. |
| EPSS | User-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 status | Not KEV-listed. No CISA due date, no federal emergency signal, no immediate-exploitation override. |
| CVSS vector readout | CVSS: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 versions | Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS per Google's stable-channel advisory. |
| Fixed versions | Upgrade 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 reality | This 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 reporter | Google 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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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. - 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.