← Back to Feed CACHED · 2026-09-30 01:57:25 · CACHE_KEY CVE-2026-11103
CVE-2026-11103 · CWE-269 · Disclosed 2026-06-04

Google Chrome Windows Installer DLL Hijacking Privilege Escalation

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Installer-only EoP needs local file drop and manual run — enterprise auto-update bypasses entirely"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attain local file-write access

The attacker must be able to drop a malicious file (typically a DLL like 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.
Conditions required:
  • Local access to the target machine OR ability to deliver a file to the user's Downloads folder
Where this breaks in practice:
  • 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
Detection/coverage: EDR agents (CrowdStrike, Defender for Endpoint, SentinelOne) flag suspicious DLL writes to user-writable directories. AMSI scanning catches known-malicious payloads at write time.
STEP 02

Victim manually runs Chrome standalone installer

The user must download and execute 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Application control policies (AppLocker, WDAC) can block unsigned DLL loading. Process monitoring detects setup.exe loading DLLs from unexpected paths.
STEP 03

DLL hijack grants SYSTEM-level code execution

When the installer loads the planted DLL in its elevated context (post-UAC), the attacker's payload executes with the installer's privilege level — typically SYSTEM or high-integrity administrator. The attacker now has full OS-level control of the single workstation where the installer was run.
Conditions required:
  • Steps 1 and 2 completed successfully
  • Planted DLL exports the expected function signatures
Where this breaks in practice:
  • 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
Detection/coverage: Sysmon Event ID 7 (DLL Load) with ImageLoaded path outside System32/SysWOW64. EDR behavioral detection for DLL side-loading from %USERPROFILE%\Downloads.
STEP 04

Post-exploitation on single host

With SYSTEM access on the compromised workstation, the attacker can dump credentials, install persistence, disable security tooling, or pivot laterally using standard post-exploitation techniques. However, none of this is unique to this CVE — it's generic local EoP post-exploitation. The blast radius is one workstation, not fleet-scale.
Conditions required:
  • Successful SYSTEM-level code execution from step 3
Where this breaks in practice:
  • 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
Detection/coverage: EDR behavioral detections for credential access, persistence installation, and lateral movement. Windows Event ID 4688 (process creation) with parent process as Chrome installer.
03 · Compensating Control

1
MEDIUM 4.0→LOW 2.0
SEVERITY REDUCED
Enforce application control (WDAC/AppLocker) to block unsigned DLL loading from user-writable directories — Windows Defender Application Control or AppLocker rules that restrict DLL loading to signed binaries from trusted paths (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.
2
MEDIUM 4.0→IGNORE 0.0
SEVERITY REDUCED
Deploy Chrome via managed distribution (SCCM, Intune, GPO MSI) and block standalone installer execution — If Chrome is deployed and updated exclusively through enterprise management tools, the standalone installer code path is never exercised, eliminating the attack surface entirely. Create a Software Restriction Policy or AppLocker rule blocking execution of ChromeSetup.exe and ChromeStandaloneSetup.exe from user directories. No mitigation SLA applies — implement within your standard 365-day remediation window.
3
MEDIUM 4.0→IGNORE 0.0
SEVERITY REDUCED
Update Chrome to ≥149.0.7827.53 fleet-wide — The definitive fix. Verify via Chrome Browser Cloud Management or your EDR's software inventory that all endpoints report Chrome ≥149.0.7827.53. Per the noisgate remediation SLA for MEDIUM, complete within 365 days. Given that Chrome auto-updates, most of your fleet is likely already patched — focus verification on endpoints with stale update channels or disabled GoogleUpdate.exe.
4
MEDIUM 4.0→MEDIUM 3.5
Enable Sysmon or EDR DLL-load monitoring for Chrome installer processes — Configure Sysmon Event ID 7 or equivalent EDR telemetry to alert on DLL loads by Chrome installer processes (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.
What doesn't work
  • 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.exe should 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone 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 availabilityA 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 score0.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 statusNot listed. No CISA deadline. No federal mandate to patch on an accelerated timeline.
CVSS vector analysisCVSS: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 severityMedium — 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 versionsAll Google Chrome for Windows versions prior to 149.0.7827.53. Linux and macOS are not affected — this is Windows-only, installer-specific.
Fixed versionsChrome 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 timelineReserved and published June 4, 2026. Last NVD update July 23, 2026. Chromium bug tracker: issues.chromium.org/500483038.
Reporting researcherNot publicly attributed in the Chrome release notes or Chromium bug tracker (bug is likely access-restricted). No bounty amount disclosed.

Sources.

  1. OpenCVE — CVE-2026-11103 Detail
  2. CyberStrike — CVE-2026-11103 Analysis
  3. Chrome 149 Stable Channel Release Notes
  4. Chromium Bug Tracker — Issue 500483038
  5. SecurityWeek — Chrome 149 Patches 429 Vulnerabilities
  6. KSEC Forum — Exploit for Improper Privilege Management in Google Chrome
  7. Seclists — Chrome Installer DLL Hijacking History (2015)
  8. NVD — CVE-2026-11103
05 · The Call

Final Verdict
↓ DOWNGRADED to MEDIUM (4.0/10)

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.exe in 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.exe auto-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.

06 · Verification

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

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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