This is a peephole in a front door, not a battering ram
CVE-2026-11265 is a Google Chrome Autofill bug that affects versions prior to 149.0.7827.53 and can let a malicious site leak data across origins. Public package metadata also labels it as an Autofill validation flaw, and Google shipped fixes in the 149.0.7827.53/.54 release line on May 29, 2026; downstream Chromium packaging picked up the same fix train.
Google's HIGH 7.5 baseline overstates enterprise urgency in real life. This is still a browser-delivered remote bug, but the observed impact is *confidentiality-only*, public exploit detail is sparse, there is no KEV listing, EPSS is near-zero, and the attack usually depends on the victim hitting a malicious page *plus* having useful Autofill data present to steal.
4 steps from start to impact.
Land the victim on a crafted page
- Victim uses vulnerable Chrome prior to
149.0.7827.53 - Victim browses attacker-controlled or attacker-influenced web content
- This is endpoint delivery, not unauthenticated exploitation of an exposed server
- Public exploit details are limited, which raises attacker development cost
Trigger the Autofill validation flaw
- Autofill-relevant browser state is present
- The vulnerable UI/data handling path is reachable in the victim session
- Not every user profile will hold interesting Autofill material
- Enterprise browser hardening, disabled Autofill, or profile separation can reduce payoff
Read and stage cross-origin data
- Leaked data exists and is accessible to the exploit
- Browser policies do not otherwise block the exfil path
- Impact is bounded to what the browser/session can leak
- No evidence in reviewed sources of privilege escalation, persistence, or sandbox escape
Exfiltrate to attacker infrastructure
- Outbound browser traffic to attacker infrastructure is allowed
- DLP, SWG, DNS filtering, and egress controls can still catch or block commodity exfil domains
- Attack value is lower if only low-sensitivity profile data is exposed
The supporting signals.
| In-the-wild status | No public evidence of active exploitation in the reviewed sources, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit repo was found during review. That does not mean unexploitable; it means attacker tradecraft is likely private right now. |
| EPSS | 0.00014 from the user intel block — effectively near-zero predicted exploitation probability. Percentile was not independently confirmed from an authoritative record. |
| KEV status | Not present in the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector reality check | Vendor vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, which models a no-auth remote confidentiality hit. In practice, the missing friction is victim browsing context and useful Autofill state. |
| Affected versions | Google states Chrome versions prior to 149.0.7827.53 are affected; the early stable desktop fix landed as 149.0.7827.53/.54. |
| Fixed versions | Google desktop fix floor: 149.0.7827.53/.54. Beta moved to 149.0.7827.53 on the same date. openSUSE package metadata shows Chromium 149 updates carrying this CVE as well. |
| Exposure / scanability | Shodan/Censys/FOFA-style internet exposure data is basically not meaningful here because Chrome is a client application, not a remotely enumerable service. Your risk lives in endpoint population and browser lag, not public attack surface counts. |
| Timeline | User-supplied disclosure date is 2026-06-05; Google shipped the relevant fixed desktop build on 2026-05-29. Public downstream metadata appeared around 2026-06-04 to 2026-06-05. |
| Researcher / credit | No public researcher credit was confirmed from the accessible vendor and CVE-facing sources reviewed. |
noisgate verdict.
The decisive downgrade is that this is a *browser-session data leak*, not server-side unauthenticated compromise or client RCE. The reachable population is large because Chrome is everywhere, but the blast radius is narrower because the attacker still needs a victim browsing event and only gets what the vulnerable Autofill/session context can expose.
Why this verdict
- Vendor starts at 7.5, but the outcome is confidentiality-only — there is no public indication of code execution, persistence, or host compromise.
- Requires a victim browser session — this is not an internet-facing service flaw you can hit blindly across a subnet; the attacker needs users to render crafted content.
- Useful payload depends on local browser state — the bug matters more when Autofill holds valuable data, which is a real but narrowing condition compared with a universal browser takeover primitive.
- Threat intel is cold — no KEV, no public campaign reporting, and an EPSS of
0.00014all push downward. - Public exploit detail is thin — absent public PoC or issue disclosure, mass weaponization is less likely in the immediate term.
Why not higher?
If this had public exploit code, active abuse, or a path to credential theft at scale with no meaningful per-user dependency, I would keep it in HIGH. But the available evidence says *data leak via browser context*, not one-click fleet compromise, and that matters more than the theoretical CVSS top line.
Why not lower?
Chrome is massively deployed, and a malicious page is a realistic delivery channel. Even a confidentiality-only browser bug can still expose sensitive user data, so this is not backlog fluff or something to ignore.
What to do — in priority order.
- Enforce browser auto-update health — Verify managed endpoints are actually consuming Chrome updates and not pinned below
149.0.7827.53/.54. For aMEDIUMverdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice you should fix update drift in the next normal browser cycle because this is a user-facing internet entry point. - Reduce Autofill exposure where feasible — For high-risk cohorts, disable or restrict Autofill storage/use through enterprise browser policy if business impact is acceptable. This cuts the value of exploitation while you remediate; for
MEDIUM, there is no separate mitigation SLA, so treat it as risk reduction rather than a mandated emergency control. - Tighten egress filtering for browsers — Use SWG, DNS filtering, and reputation-based blocking to make exfiltration harder from browser processes. That will not cure the vuln, but it can reduce the success rate of commodity attacker infrastructure during the remediation window.
- Prioritize sensitive user groups first — Patch executives, finance, admins, developers, and researcher workstations ahead of the broad fleet if you cannot update all endpoints at once. The impact here is data exposure, so the *value of the victim profile* should drive sequencing.
- A perimeter vuln scanner does not solve this, because it cannot see browser-session exploitation and Chrome is not an externally exposed service.
- Server-side WAF rules are unreliable here, because the vulnerable logic sits in the client browser and the triggering page can look like ordinary web content.
- MFA does not meaningfully reduce the core browser data-leak condition unless the only thing exposed would have been session establishment secrets that are separately protected.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tooling. Invoke it as python3 check_chrome_cve_2026_11265.py on macOS/Linux or py check_chrome_cve_2026_11265.py on Windows; no admin rights are required, but the script must be able to execute Chrome or read its installed version from common locations.
#!/usr/bin/env python3
# check_chrome_cve_2026_11265.py
# Determine whether installed Google Chrome is vulnerable to CVE-2026-11265.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIXED_VERSION = (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 cmp_ver(a, b):
return (a > b) - (a < b)
def run_and_get_version(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=5)
out = (p.stdout or '').strip()
v = parse_version(out)
if v:
return v, out, ' '.join(cmd)
except Exception:
pass
return None, None, None
def candidate_commands():
system = platform.system().lower()
cmds = []
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
pf = os.environ.get('PROGRAMFILES', '')
pf86 = os.environ.get('PROGRAMFILES(X86)', '')
paths = [
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for p in paths:
if p and os.path.exists(p):
cmds.append([p, '--version'])
for name in ['chrome', 'google-chrome', 'google-chrome-stable']:
resolved = shutil.which(name)
if resolved:
cmds.append([resolved, '--version'])
elif system == 'darwin':
mac_paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for p in mac_paths:
if os.path.exists(p):
cmds.append([p, '--version'])
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
resolved = shutil.which(name)
if resolved:
cmds.append([resolved, '--version'])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
resolved = shutil.which(name)
if resolved:
cmds.append([resolved, '--version'])
linux_paths = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
]
for p in linux_paths:
if os.path.exists(p):
cmds.append([p, '--version'])
# Deduplicate while preserving order
seen = set()
uniq = []
for cmd in cmds:
key = tuple(cmd)
if key not in seen:
seen.add(key)
uniq.append(cmd)
return uniq
def main():
cmds = candidate_commands()
if not cmds:
print('UNKNOWN - Chrome executable not found in common locations')
sys.exit(2)
found = []
for cmd in cmds:
v, raw, used = run_and_get_version(cmd)
if v:
found.append((v, raw, used))
if not found:
print('UNKNOWN - Could not determine Chrome version from discovered executables')
sys.exit(2)
# Use the highest discovered version; multiple channels may coexist.
found.sort(key=lambda x: x[0], reverse=True)
version, raw, used = found[0]
version_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in FIXED_VERSION)
if cmp_ver(version, FIXED_VERSION) < 0:
print(f'VULNERABLE - Found version {version_str} via [{used}] ; fixed version is {fixed_str} or later')
sys.exit(1)
else:
print(f'PATCHED - Found version {version_str} via [{used}] ; fixed threshold is {fixed_str}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53/.54, and clean up update drift rather than treating this like a zero-day fire drill. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA, but because this is a browser-facing internet delivery path, most enterprises should still roll the fix in their next managed browser update wave and verify laggards instead of letting it age indefinitely.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.