Leaving a loaded gun in the Downloads folder and hoping someone picks it up
CVE-2026-11103 is an improper privilege management flaw (CWE-269/CWE-266) in the Google Chrome standalone installer (ChromeSetup.exe / ChromeStandaloneSetup.exe) on Windows, affecting all versions prior to 149.0.7827.53. An attacker who can place a malicious file — most likely a crafted DLL — in the same directory from which the installer runs (typically the user's Downloads folder) can hijack the installer's elevated execution context and achieve OS-level privilege escalation. This is a well-known vulnerability class for Windows executable installers that dates back to at least 2015 in Chrome's history (see CVE-2024-7977, CVE-2023-2939 for prior instances of the same pattern).
Google's own Chromium security team rated this Medium severity, which is notably lower than the NVD-assigned CVSS 7.8 HIGH. Google's assessment is closer to reality. The CVSS vector marks PR:N (Privileges Required: None), but this is misleading — the attacker must already be able to write arbitrary files to a directory the victim will run an installer from, which implies existing local access or a separate file-drop vector (e.g., a drive-by download). More critically, the vulnerability only triggers when a user manually runs the standalone installer, not during Chrome's built-in auto-update cycle (GoogleUpdate.exe). In any enterprise using SCCM, Intune, GPO, or Chrome Browser Cloud Management for deployment, this code path is simply never exercised.
4 steps from start to impact.
Attain local file-write access
CryptBase.dll, RichEd20.dll, or similar) into a directory the victim will execute the Chrome installer from. The most common target is the user's Downloads folder. This requires either prior local access to the workstation, a social engineering vector that delivers the DLL alongside the installer, or a separate browser vulnerability that writes files to disk.- Local access to the target machine OR ability to deliver a file to the user's Downloads folder
- Requires a *separate* initial access vector — phishing, drive-by download, or existing foothold
- Modern browsers prompt before downloading executable/DLL files
- Windows SmartScreen and Mark-of-the-Web (MOTW) apply to downloaded files
Victim manually runs Chrome standalone installer
ChromeSetup.exe or ChromeStandaloneSetup.exe from the same directory where the malicious file was planted. The installer, which requests UAC elevation, loads the attacker's DLL from the current working directory before loading the legitimate system DLL. This is the critical user-interaction gate — Chrome's built-in auto-update mechanism (GoogleUpdate.exe) does not use this installer code path.- User must manually download and run the standalone Chrome installer
- UAC prompt must be accepted by the user
- Malicious file must be co-located in the installer's directory
- Enterprise Chrome deployments use managed distribution (SCCM/Intune/GPO), not standalone installer downloads
- Chrome auto-updates via
GoogleUpdate.exe— users rarely re-download the installer - UAC prompt provides a friction checkpoint
- IT policies may block users from running unsigned executables from Downloads
setup.exe loading DLLs from unexpected paths.DLL hijack grants SYSTEM-level code execution
- Steps 1 and 2 completed successfully
- Planted DLL exports the expected function signatures
- Code integrity policies (WDAC) block unsigned DLLs from loading
- EDR detects anomalous DLL side-loading from user-writable paths in real time
- Attack is confined to a single host — no lateral movement inherent to the bug
ImageLoaded path outside System32/SysWOW64. EDR behavioral detection for DLL side-loading from %USERPROFILE%\Downloads.Post-exploitation on single host
- Successful SYSTEM-level code execution from step 3
- Credential Guard blocks LSASS credential dumping on modern Windows 10/11
- EDR detects post-exploitation tooling (Mimikatz, Cobalt Strike, etc.)
- Network segmentation limits lateral movement from workstations
System32, Program Files) will break the DLL hijack chain at step 3. This is the single most effective compensating control. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window for the actual patch.ChromeSetup.exe and ChromeStandaloneSetup.exe from user directories. No mitigation SLA applies — implement within your standard 365-day remediation window.GoogleUpdate.exe.ChromeSetup.exe, setup.exe) from non-standard paths (anything outside System32, SysWOW64, or Chrome's program directory). This provides detection-in-depth even if the other controls fail.- Network-level controls (firewalls, IDS/IPS, WAF): This is a local privilege escalation — there is no network traffic to inspect or block. Network segmentation does not prevent the initial exploit, though it limits post-exploitation lateral movement.
- Chrome browser extensions or policies: The vulnerability is in the *installer binary*, not in the running browser. Chrome enterprise policies, Safe Browsing, and extension controls have no effect on the installer's DLL loading behavior.
- Patching Chrome via auto-update alone without verification: While
GoogleUpdate.exeshould update Chrome automatically, the *installer binary* that a user might download from google.com is always the latest version at download time. The risk is from old installers cached in Downloads folders — auto-update doesn't clean those up.
The supporting signals.
| In-the-wild exploitation | None observed. Not listed in CISA KEV. No GreyNoise or Shadowserver scanning activity reported. No campaigns attributed to this CVE. This is a local-only vulnerability with no network attack surface, so mass scanning is not applicable. |
|---|---|
| Proof-of-concept availability | A PoC reference exists on the KSEC Community Forum, but no widely available weaponized exploit code was found on GitHub, ExploitDB, or in Metasploit/nuclei templates. pocindex.io returns no indexed PoCs for this CVE. The DLL hijacking technique itself is trivial to reproduce — the challenge is getting the file placed and the installer run, not writing the exploit. |
| EPSS score | 0.0008 (0.08%) — effectively 0th percentile. FIRST's model considers exploitation extremely unlikely. This is consistent with the local-only, user-interaction-required attack surface. |
| KEV status | Not listed. No CISA deadline. No federal mandate to patch on an accelerated timeline. |
| CVSS vector analysis | CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — Local attack vector, low complexity, no privileges required, user interaction required, unchanged scope. The PR:N is technically correct (no *Chrome-specific* privileges needed) but practically misleading: the attacker needs file-write access to the victim's directory. Scope Unchanged means the blast radius is confined to the single host. |
| Chromium severity | Medium — Google's own security team rates this lower than the NVD CVSS score. Google has historically rated installer bugs at Medium severity because they require local access, user interaction, and only affect the manual installation path. |
| Affected versions | All Google Chrome for Windows versions prior to 149.0.7827.53. Linux and macOS are not affected — this is Windows-only, installer-specific. |
| Fixed versions | Chrome 149.0.7827.53 (Stable channel, released June 4, 2026). Debian issued DSA-6325-1 for Chromium packaging. Enterprise admins using Chrome Browser Cloud Management or SCCM should verify fleet is at ≥149.0.7827.53. |
| Disclosure timeline | Reserved and published June 4, 2026. Last NVD update July 23, 2026. Chromium bug tracker: issues.chromium.org/500483038. |
| Reporting researcher | Not publicly attributed in the Chrome release notes or Chromium bug tracker (bug is likely access-restricted). No bounty amount disclosed. |
Sources.
- OpenCVE — CVE-2026-11103 Detail
- CyberStrike — CVE-2026-11103 Analysis
- Chrome 149 Stable Channel Release Notes
- Chromium Bug Tracker — Issue 500483038
- SecurityWeek — Chrome 149 Patches 429 Vulnerabilities
- KSEC Forum — Exploit for Improper Privilege Management in Google Chrome
- Seclists — Chrome Installer DLL Hijacking History (2015)
- NVD — CVE-2026-11103
Why this verdict
- Local-only, interaction-dependent chain: The CVSS vector requires local file-write access *and* the victim to manually run the standalone installer. Both prerequisites compound to dramatically narrow the reachable population. In a 10,000-host fleet, the number of machines where a user manually downloads and runs
ChromeSetup.exein any given quarter is vanishingly small. - Enterprise deployment bypasses the vulnerable path: Organizations using SCCM, Intune, GPO, or Chrome Browser Cloud Management deploy Chrome via MSI or ADMX — the standalone installer code path is never exercised. Chrome's built-in
GoogleUpdate.exeauto-updater also does not use this path. This removes ~90%+ of enterprise endpoints from the attack surface. - Google rates it Medium themselves: Chromium's own security team, which has deep context on the installer's architecture and exposure, assigned Medium severity. They have done this consistently for installer DLL-hijacking bugs (CVE-2024-7977, CVE-2023-2939). The NVD CVSS 7.8 overweights the theoretical impact without accounting for the real-world exposure constraints.
- EPSS confirms minimal risk: At 0.08%, FIRST's exploitation prediction model — which incorporates exploit availability, attacker interest, and attack surface characteristics — places this in the bottom tier of exploitability.
- Role multiplier: Chrome is installed on nearly every Windows endpoint, but the *installer binary* is not a persistent component and does not occupy a high-value role. (a) Workstations: the canonical target, but users rarely run the standalone installer in managed environments. (b) Servers: Chrome is not typically installed on servers; even if it were, server admins use managed deployment. (c) High-value roles (DCs, hypervisors, CI/CD, identity): Chrome installer is not a component of any high-value role infrastructure. The blast radius is confined to a single workstation (Scope: Unchanged). No domain-takeover, fleet-compromise, or supply-chain pivot path exists from this bug alone. No high-value role floor applies.
- Prior access requirement is a severity tax: The attacker must already be able to write files to the target's filesystem. This means the attacker either has local access (making EoP an incremental gain, not initial access) or has a separate file-delivery vector (social engineering + download). Each prerequisite is a compounding downward pressure.
Why not higher?
The vulnerability does achieve full SYSTEM-level code execution on a single host, which is meaningful impact. However, every step of the chain requires conditions that are absent in standard enterprise Chrome deployments: manual installer execution from a user-writable directory, attacker-placed DLL in the same path, and UAC acceptance. The scope is unchanged (single host), no high-value infrastructure role is implicated, and neither Google nor EPSS data supports a HIGH rating. There is no lateral movement or domain-level impact inherent to the flaw.
Why not lower?
The underlying primitive — SYSTEM-level code execution via a low-complexity DLL hijack — is real and proven. The technique class (installer DLL planting) is well-understood and trivial to execute *if* the preconditions are met. A LOW rating would understate the impact for the minority of environments where users do download Chrome manually (BYOD, unmanaged endpoints, small offices without centralized deployment). The PoC reference, while not weaponized, confirms the bug is reproducible.
Crowdsourced verification payload.
Run on each Windows target host where Chrome is installed. Execute as any user (no admin required). Example: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-11103.ps1
# Check-CVE-2026-11103.ps1
# Checks if Google Chrome on Windows is patched against CVE-2026-11103
# (Installer privilege escalation via malicious file)
# Fixed in: 149.0.7827.53
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
$fixedVersion = [version]'149.0.7827.53'
$chromeFound = $false
# Check common Chrome installation paths
$paths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
"$env:LocalAppData\Google\Chrome\Application\chrome.exe"
)
foreach ($p in $paths) {
if (Test-Path $p) {
$chromeFound = $true
$ver = [version](Get-ItemProperty $p).VersionInfo.FileVersion
if ($ver -ge $fixedVersion) {
Write-Host "PATCHED - Chrome $ver is installed (fixed in $fixedVersion)" -ForegroundColor Green
exit 0
} else {
Write-Host "VULNERABLE - Chrome $ver is below fixed version $fixedVersion" -ForegroundColor Red
# Bonus: check for stale installers in Downloads
$downloads = Join-Path $env:USERPROFILE 'Downloads'
$staleInstallers = Get-ChildItem -Path $downloads -Filter 'Chrome*Setup*.exe' -ErrorAction SilentlyContinue
if ($staleInstallers) {
Write-Host "WARNING - Stale Chrome installer(s) found in Downloads:" -ForegroundColor Yellow
$staleInstallers | ForEach-Object { Write-Host " $_" -ForegroundColor Yellow }
}
exit 1
}
}
}
if (-not $chromeFound) {
# Try registry
$regPaths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome'
)
foreach ($rp in $regPaths) {
$reg = Get-ItemProperty -Path $rp -ErrorAction SilentlyContinue
if ($reg -and $reg.Version) {
$ver = [version]$reg.Version
if ($ver -ge $fixedVersion) {
Write-Host "PATCHED - Chrome $ver found in registry (fixed in $fixedVersion)" -ForegroundColor Green
exit 0
} else {
Write-Host "VULNERABLE - Chrome $ver found in registry, below $fixedVersion" -ForegroundColor Red
exit 1
}
}
}
}
Write-Host "UNKNOWN - Google Chrome not detected on this system" -ForegroundColor Gray
exit 2