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.
4 steps from start to impact.
Lure the user to attacker-controlled web content
- Target is running Chrome before
149.0.7827.53 - User visits attacker-controlled or attacker-influenced content
- JavaScript and normal browser features are available
- 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
Trigger the Password Manager implementation flaw
- The vulnerable Password Manager path is reachable from web content
- The victim browser state contains useful origin-separated data
- 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
Exfiltrate cross-origin secrets
fetch, XHR, or beacon-style requests.- Sensitive data is present in the victim browser context
- Outbound HTTPS to attacker infrastructure is allowed
- 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
Convert leak into account access
- Leaked data includes credentials, tokens, or actionable sensitive content
- Target accounts lack strong session protections
- 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
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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.