This is a fake badge on the download door, not a master key to the building
CVE-2026-11107 is a Downloads UI spoofing flaw in Google Chrome caused by inappropriate implementation in the Downloads component. A remote attacker can use a crafted HTML page to make Chrome present misleading download-related UI, which can trick a user about what file is being downloaded or what action they are approving. Affected versions are Chrome prior to 149.0.7827.53; Google's stable rollout notes show 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS as the fixed train.
Google's MEDIUM 4.3 label is technically fair in CVSS terms, but operationally it is still below the line for urgent enterprise disruption. The exploit chain stops at deception: the attacker still needs a user to visit the page, believe the fake UI, and take a follow-on action, and the bug by itself does not provide code execution, sandbox escape, account takeover, or a security-boundary break.
4 steps from start to impact.
Deliver a crafted web page using plain browser primitives
- Unauthenticated remote reachability to a target user
- User must open attacker-controlled content in vulnerable Chrome
- Chrome version is below 149.0.7827.53
- Email gateways, browser isolation, URL filtering, and user suspicion all reduce opens
- Enterprise Chrome often auto-updates quickly, shrinking the vulnerable population
- There is no evidence of a public turnkey exploit kit for this CVE
Trigger spoofed Downloads UI inside Chrome
- The victim must remain on the page long enough for the spoof to render
- The specific UI path must still be reachable in the user's browser state
- Modern browser UX, Safe Browsing warnings, and pop-up restrictions can break or blunt the illusion
- UI spoofing is brittle across window size, locale, theme, and OS chrome differences
Convert deception into a user action
- User interaction is required
- The spoof must be convincing in the victim's environment
- MFA, download restrictions, SmartScreen/Gatekeeper, and application control often stop the follow-on objective
- Awareness training and browser familiarity reduce conversion rates
Land the real payload outside the vulnerability
- Attacker has a separate payload or fraud objective
- Endpoint or identity controls fail to stop the next step
- EDR, app allowlisting, sandbox detonation, and identity protections routinely stop post-download abuse
- Blast radius is per-user and non-wormable
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in reviewed primary sources, and Google did not attach an exploited-in-the-wild warning in the release notes. |
|---|---|
| KEV status | Not listed in CISA KEV as of the current catalog review; that materially lowers urgency versus browser zero-days with confirmed abuse. |
| Proof-of-concept availability | No public PoC or exploit repo found in reviewed primary-source references. The Chromium bug reference exists, but bug details are restricted. |
| EPSS | 0.00035 (about 0.035% probability over 30 days per the user-supplied intel). That is extremely low and lines up with the absence of exploit reporting. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N means remote reachability with no auth, but it still needs user interaction and only claims low integrity impact—no confidentiality or availability impact. |
| Affected versions | Google Chrome before 149.0.7827.53; the CVE record and Chrome release notes tie the fix to the Chrome 149 stable train. |
| Fixed versions | 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and macOS per Google's Chrome 149 stable rollout and early-stable notes. |
| Exposure / scanning reality | This is a client-side browser issue, so Shodan/Censys/FOFA-style internet exposure counts are not meaningful. You need endpoint version inventory, not perimeter scanning. |
| Disclosure and reporting timeline | CVE publication landed on 2026-06-04; Google shipped Chrome 149 stable on 2026-06-02 and lists this bug as reported by Google on 2026-04-08. |
| Researcher / reporting org | Google is listed as the reporter in the Chrome release notes; no external researcher credit or bug bounty is shown for this CVE. |
noisgate verdict.
The decisive downgrade factor is the mandatory user-belief step: the bug only creates misleading Downloads UI and still needs a victim to trust it and act. In a 10,000-host enterprise, that makes this a social-engineering multiplier, not a reliable direct-compromise path, and modern endpoint and identity controls usually have another chance to stop the kill chain afterward.
Why this verdict
- User interaction is the real gate: the attacker is remote and unauthenticated, but exploitation still requires the victim to open hostile content and believe spoofed download UI.
- No direct compromise primitive: this bug provides UI deception only; it does not itself grant code execution, sandbox escape, credential theft, or policy bypass with durable host impact.
- Broad deployment, narrow blast radius: Chrome is everywhere, but exploitation is one-user-at-a-time and non-wormable, so exposure breadth does not translate into emergency patch priority.
Why not higher?
There is no KEV listing, no reviewed evidence of active exploitation, and no public PoC that would make this a fast-moving campaign enabler. More importantly, the vulnerability's effect ends at spoofing; the attacker still needs a second-stage payload or phishing objective and another user decision.
Why not lower?
This is still a real security weakness in a ubiquitous client application, and convincing download UI spoofing can materially improve phishing or malware-delivery conversion rates. On populations with weak browser update hygiene or permissive download execution, the business risk is not zero.
What to do — in priority order.
- Enforce Chrome auto-update and relaunch — Make sure enterprise policy forces Chrome onto the fixed 149 train and actually relaunches long-lived sessions so the patched binary is in use. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and close it during normal browser maintenance.
- Harden download handling — Use Chrome enterprise policies, secure web gateway rules, and attachment controls to restrict risky file types from webmail, chat, and newly observed domains. This directly cuts the payoff of a spoofed Downloads prompt and is appropriate as standard hygiene rather than an urgent exception action.
- Block execution from user download paths — Use AppLocker, WDAC, Gatekeeper, or equivalent endpoint controls so a tricked user cannot easily convert a spoofed download into code execution. This is the best compensating layer because it attacks the post-spoof stage where most real harm occurs.
- Watch for browser-to-payload pivots — Tune EDR analytics for browser-originated downloads followed by execution from
Downloads, temp paths, disk images, scripts, or archive extraction chains. That is where you will actually catch abuse if someone uses this flaw in a phishing flow.
- A WAF does not meaningfully solve this; the problem is client-side browser UI rendering, not a server request pattern you can reliably normalize away.
- External internet exposure scanners do not help because there is no listening service to fingerprint; you need endpoint version inventory.
- Generic phishing awareness alone is not enough because the whole point of the bug is to make malicious download flows look more trustworthy.
Crowdsourced verification payload.
Run this on the target endpoint or through your EDR live-response shell. Invoke it as python3 chrome_cve_check.py for auto-discovery or python3 chrome_cve_check.py --version 149.0.7827.52 / python3 chrome_cve_check.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; local user privileges are usually enough, though some locked-down systems may require elevated read access to program files.
#!/usr/bin/env python3
# CVE-2026-11107 Chrome version checker
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import argparse
import os
import platform
import re
import subprocess
import sys
from shutil import which
PATCHED_MIN = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_ver(s):
if not s:
return None
m = VERSION_RE.search(s)
if not m:
return None
return tuple(int(x) for x in m.groups())
def ver_to_str(v):
return '.'.join(str(x) for x in v)
def is_patched(v):
return v >= PATCHED_MIN
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def candidate_paths():
system = platform.system().lower()
paths = []
if 'windows' in system:
envs = [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]
rels = [
r'Google\Chrome\Application\chrome.exe',
r'Chromium\Application\chrome.exe'
]
for base in envs:
if base:
for rel in rels:
paths.append(os.path.join(base, rel))
elif 'darwin' in system:
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium'
])
else:
paths.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/usr/bin/chromium',
'/usr/bin/chromium-browser',
'/snap/bin/chromium'
])
return [p for p in paths if p and os.path.exists(p)]
def detect_version_from_path(path):
out = run_cmd([path, '--version'])
return parse_ver(out), out.strip()
def detect_version_auto():
for exe in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
p = which(exe)
if p:
v, raw = detect_version_from_path(p)
if v:
return p, v, raw
for p in candidate_paths():
v, raw = detect_version_from_path(p)
if v:
return p, v, raw
return None, None, ''
def main():
ap = argparse.ArgumentParser(description='Check whether installed Chrome/Chromium is vulnerable to CVE-2026-11107.')
ap.add_argument('--version', help='Version string to evaluate directly, e.g. 149.0.7827.52')
ap.add_argument('--path', help='Path to browser executable, e.g. C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe')
args = ap.parse_args()
if args.version:
v = parse_ver(args.version)
if not v:
print('UNKNOWN - Could not parse supplied version string')
sys.exit(2)
if is_patched(v):
print(f'PATCHED - Version {ver_to_str(v)} is >= {ver_to_str(PATCHED_MIN)}')
sys.exit(0)
else:
print(f'VULNERABLE - Version {ver_to_str(v)} is < {ver_to_str(PATCHED_MIN)}')
sys.exit(1)
if args.path:
if not os.path.exists(args.path):
print(f'UNKNOWN - File not found: {args.path}')
sys.exit(2)
v, raw = detect_version_from_path(args.path)
if not v:
print(f'UNKNOWN - Could not determine version from {args.path}')
sys.exit(2)
if is_patched(v):
print(f'PATCHED - {args.path} reports {raw}')
sys.exit(0)
else:
print(f'VULNERABLE - {args.path} reports {raw}')
sys.exit(1)
path, v, raw = detect_version_auto()
if not v:
print('UNKNOWN - Could not automatically locate Chrome/Chromium or parse its version')
sys.exit(2)
if is_patched(v):
print(f'PATCHED - {path} reports {raw}')
sys.exit(0)
else:
print(f'VULNERABLE - {path} reports {raw}')
sys.exit(1)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
- Google Chrome Releases - Early Stable Update for Desktop
- Chromium issue reference for CVE-2026-11107
- CIRCL Vulnerability-Lookup mirror of Chrome CVE records
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- Chrome Enterprise browser release channels
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.