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.
3 steps from start to impact.
Land the victim on attacker HTML
- Target uses Chrome earlier than
149.0.7827.53 - Victim visits attacker-controlled or attacker-influenced content
- JavaScript and normal browser features are permitted
- 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
Trigger the Password Manager logic flaw
- Victim browser is still unpatched
- The relevant Password Manager code path is reachable in that browsing context
- 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
Exfiltrate cross-origin data
- Cross-origin data of value is present in the victim's active browser context
- Outbound web traffic to attacker-controlled endpoints is possible
- 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
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.149.0.7827.53. This matters more than external scanning because internet-facing telemetry will not tell you which user workstations are still vulnerable.- 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.
The supporting signals.
| In-the-wild status | No active exploitation evidence found in the retrieved primary-source set; Google did not flag it as exploited. |
|---|---|
| KEV status | Not listed in CISA KEV as assessed; no KEV add date or due date applies. |
| Proof-of-concept availability | No public PoC located in the retrieved source set. Chromium bug details remain restricted, which is normal early in Chrome release cycles. |
| EPSS | 0.00035 from provided intel; very low exploit-likelihood signal. Percentile was not independently confirmed from retrieved FIRST output. |
| CVSS vector | CVSS: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 versions | Chrome 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 versions | Update 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 reality | Not 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 timeline | Chrome stable update published 2026-06-02; CVE disclosure metadata provided as 2026-06-04. |
| Reporter | Google release notes attribute the finding to Google and reference Chromium issue 500095743. |
Sources.
- Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
- Chromium issue 500095743
- Chromium issue 500095743 (Chrome release reference context)
- Canadian Centre for Cyber Security advisory AV26-544
- FIRST EPSS API documentation
- FIRST EPSS overview
- CISA Known Exploited Vulnerabilities catalog feed
- FIRST CVSS resources
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.
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.
#!/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()