This is a crooked road sign inside a very common car, not a missing door lock
CVE-2026-11243 affects Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. A crafted HTML page can abuse the Downloads/navigation flow to weaken a browser restriction, but the public record is messy: NVD describes it as an *inappropriate implementation* that lets an attacker bypass navigation restrictions, while Google's June 2, 2026 stable-release notes label the same CVE as *incorrect security UI in Downloads*. Either way, this is a client-side browser trust/UX problem reached through web content, not a memory-corruption or sandbox-escape bug.
The vendor baseline of 5.4 MEDIUM is defensible in CVSS math but too generous for enterprise patch triage. Real-world exploitation still requires a user to hit attacker-controlled content and then benefit from a narrow browser-UI edge case, with low blast radius and no evidence of in-the-wild exploitation, no KEV listing, and an extremely low EPSS; that pushes this down into LOW despite Chrome's huge install base.
4 steps from start to impact.
Deliver a crafted web page
- Victim uses Chrome earlier than
149.0.7827.53 - Victim reaches attacker-controlled content
- Normal web browsing is permitted
- Email/web filtering, Safe Browsing, ad blocking, and DNS filtering reduce reach
- Enterprise browsers usually auto-update quickly, shrinking the vulnerable window
Trigger the Downloads/navigation edge case
- Specific Downloads UI code path must be reachable
- Browser behavior must match the vulnerable build
- Issue details are still restricted, limiting copy-paste exploitation
- Minor UI timing or browser-state assumptions often make these bugs brittle in the field
Rely on user interaction
UI:R, and recent analogous Chrome Downloads UI bugs required the victim to engage with misleading prompts or gestures. In practice, the attacker still needs the user to trust or click through the manipulated flow. That sharply narrows reliable exploitation compared with silent browser compromise.- Victim interacts with the page or related download prompt
- User trusts the page enough to continue
- Security awareness, browser warnings, and download reputation checks all cut success rates
- Privileged admins are not the default target population for routine web-browsing lures
Cash out limited browser-level impact
- Attacker achieves the UI/navigation misrepresentation outcome
- Victim continues into the next malicious step
- Chrome sandboxing and OS execution prompts still stand between this bug and host compromise
- Without a second-stage flaw or social-engineering success, enterprise impact is usually limited
The supporting signals.
| In-the-wild status | No public exploitation evidence located. As of 2026-06-05, Google did not flag exploitation in the release notes, and CISA does not list this CVE in KEV. |
|---|---|
| Proof-of-concept availability | No public PoC found. The Chromium issue is permission-restricted, which slows opportunistic weaponization but does not eliminate private research risk. |
| EPSS | 0.00011 *(user-provided intel)* — effectively noise-floor exploit probability for the next 30 days. |
| KEV status | Not KEV-listed as of 2026-06-05; no CISA due date applies. |
| CVSS vector readout | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L — network-reachable but user interaction required, with only light confidentiality/availability impact and no integrity change in the published vector. |
| Affected versions | Google Chrome before 149.0.7827.53; NVD maps this to Chrome on Windows, Linux, and macOS. |
| Fixed versions | Google's stable rollout lists Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54 as fixed. I found no official distro backport advisory for this specific CVE in the sources reviewed, so treat the browser build itself as the remediation target. |
| Exposure / population | Chrome's desktop footprint is enormous — Statcounter shows roughly 71.48% worldwide desktop browser share — so install base is broad, but this is not an internet-exposed server surface and cannot be found via Shodan-style perimeter scanning. |
| Disclosure / reporting timeline | Public dates do not line up cleanly: Google published Chrome 149 stable on 2026-06-02, NVD shows the CVE was published 2026-06-04 and modified by CISA-ADP 2026-06-05. Google's release notes say the issue was reported by Google on 2026-03-29. |
| Pattern match with prior bugs | This looks like another member of Chrome's recurring Downloads UI/security-boundary bug class. Similar issues include CVE-2026-5897 and CVE-2024-8906, both Downloads UI spoofing problems with low-to-medium scoring and user-interaction dependence. |
noisgate verdict.
The decisive factor is mandatory user interaction inside a narrow browser UI path: this is not silent remote compromise, it is a user-driven trust-boundary glitch. Chrome's large footprint keeps it relevant, but the absence of exploitation evidence and the limited browser-level blast radius keep it out of the MEDIUM bucket.
Why this verdict
- **Downward adjustment: attacker position is only *unauthenticated remote via web content*, but it still requires
UI:R.** That means no hands-off exploitation; the victim must browse to attacker content and interact with the flawed flow. - Downward adjustment: the prerequisite implies social-engineering success, not initial access by itself. Requiring the user to do something meaningful inside Chrome sharply reduces conversion versus silent browser RCE or sandbox escape.
- Downward adjustment: blast radius is per-user and browser-scoped. The published impact is a navigation/security-boundary bypass, not arbitrary code execution, privilege escalation, or tenant-wide compromise.
- Downward adjustment: real deployment exposure is broad in population but narrow in exploit surface. Chrome is everywhere, but this is not a server endpoint and not something an internet scanner can sweep up at enterprise scale.
- Downward adjustment: modern controls should interrupt the chain. Safe Browsing, web filtering, ad filtering, DNS controls, and rapid browser auto-update all act before the attacker can monetize the bug.
- Small upward adjustment: Chrome is massively deployed. A flaw in a high-share browser matters operationally, but ubiquity alone does not overcome the heavy friction from user interaction and low impact.
Why not higher?
This is not a memory-corruption bug, sandbox escape, auth bypass into enterprise infrastructure, or a silent browser compromise. The attacker still needs a victim to hit malicious content and then successfully leverage a low-detail Downloads/UI edge case for limited payoff, with no public evidence of active exploitation.
Why not lower?
It is still a real browser security-boundary weakness in a massively deployed product, reachable through normal web content with no authentication required. If you run a large unmanaged or slow-to-update endpoint fleet, the population at risk is large enough that this should stay on the patch radar rather than being ignored outright.
What to do — in priority order.
- Enforce Chrome auto-update health — Validate that enterprise policy is actually moving endpoints to
149.0.7827.53+during the next normal browser maintenance cycle. For a LOW verdict there is no SLA; treat this as backlog hygiene and use routine endpoint compliance reporting instead of emergency change control. - Tighten download reputation controls — Keep Google Safe Browsing, browser download warnings, and any secure web gateway file-reputation features enabled so a misleading Downloads flow has less room to trick users. For LOW, do this in the next routine policy review rather than as an urgent exception.
- Reduce risky web reach for high-exposure users — Apply stronger DNS/web filtering or browser isolation to admins, finance, and other phishing-prone roles that routinely touch untrusted content. There is no mitigation SLA here, so fold the control into your standard hardening roadmap.
- Watch for stale browser cohorts — Use EDR, MDM, RMM, or software inventory to find endpoints stuck below the fixed build, especially VDI gold images and kiosk-like systems that often miss browser refreshes. For LOW, clear these through the next standard image-update or software deployment wave.
- A WAF does not help; the vulnerable surface is the user's browser UI/Downloads path, not your server-side request handling.
- Perimeter scanning does not help; Chrome clients are not externally enumerable the way internet-facing appliances are.
- EDR-only thinking is insufficient; unless this is chained into payload execution, the bug can stay entirely in browser UX territory and never trip classic malware detections.
Crowdsourced verification payload.
Run this on the target endpoint or through your RMM/EDR live-response shell. Invoke it as python3 check_cve_2026_11243.py or point to a specific binary with python3 check_cve_2026_11243.py --chrome "C:\Program Files\Google\Chrome\Application\chrome.exe"; standard user rights are usually enough because it only reads the installed browser version and executes chrome --version.
#!/usr/bin/env python3
# check_cve_2026_11243.py
# Detects whether installed Google Chrome is below the fixed version for CVE-2026-11243.
# Outputs exactly one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 1 = vulnerable, 0 = patched, 2 = unknown/error
import argparse
import os
import platform
import re
import subprocess
import sys
from typing import Optional, List
FIXED = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[tuple]:
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def version_to_str(v: tuple) -> str:
return '.'.join(str(x) for x in v)
def candidate_paths() -> List[str]:
system = platform.system().lower()
paths = []
if system == 'windows':
env_paths = [
os.environ.get('ProgramFiles'),
os.environ.get('ProgramFiles(x86)'),
os.environ.get('LOCALAPPDATA'),
]
suffixes = [
r'Google\Chrome\Application\chrome.exe',
]
for base in env_paths:
if base:
for suffix in suffixes:
paths.append(os.path.join(base, suffix))
elif system == 'darwin':
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
])
else:
paths.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/opt/google/chrome/chrome',
'/snap/bin/chromium',
])
return paths
def get_version_from_binary(path: str) -> Optional[tuple]:
try:
cp = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
out = (cp.stdout or '') + ' ' + (cp.stderr or '')
return parse_version(out)
except Exception:
return None
def locate_version(explicit_path: Optional[str]) -> Optional[tuple]:
checked = []
if explicit_path:
checked.append(explicit_path)
checked.extend(candidate_paths())
seen = set()
for path in checked:
if not path or path in seen:
continue
seen.add(path)
if os.path.exists(path):
v = get_version_from_binary(path)
if v:
return v
# Fallback: rely on PATH
for cmd in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
try:
cp = subprocess.run([cmd, '--version'], capture_output=True, text=True, timeout=10)
out = (cp.stdout or '') + ' ' + (cp.stderr or '')
v = parse_version(out)
if v:
return v
except Exception:
pass
return None
def main() -> int:
parser = argparse.ArgumentParser(description='Check Google Chrome against fixed version for CVE-2026-11243')
parser.add_argument('--chrome', help='Path to Chrome binary/executable', default=None)
args = parser.parse_args()
version = locate_version(args.chrome)
if not version:
print('UNKNOWN')
return 2
if version < FIXED:
# Optional diagnostic is kept in comments to preserve exact output requirement.
# print(f'Installed version {version_to_str(version)} is below fixed {version_to_str(FIXED)}')
print('VULNERABLE')
return 1
else:
# print(f'Installed version {version_to_str(version)} meets/exceeds fixed {version_to_str(FIXED)}')
print('PATCHED')
return 0
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
149.0.7827.53, and roll them into your next routine browser update wave while prioritizing only high-risk user groups and stale image pools for faster cleanup.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.