CVE-2026-11115 · Google Chrome Updater Use-After-Free Local Privilege Escalation on…

01 · The Real Story

The janitor's master key is left in a drawer, but you need a badge to enter the building and someone to open the drawer for you

CVE-2026-11115 is a use-after-free in the Chrome Updater component (updater.exe) on Windows, present in all Chrome versions prior to 149.0.7827.53. The Updater runs as NT AUTHORITY\SYSTEM to write into Program Files and modify registry hives during browser updates. A local attacker with low-privilege access can place a crafted file that the updater processes, triggering a dangling pointer dereference (CWE-416 / CWE-825) that hijacks execution flow, yielding SYSTEM-level code execution on the host. The fix shipped June 4, 2026 in Chrome 149.0.7827.53 for Windows.

The NVD CVSS score of 7.3 HIGH overstates the operational risk. Google's own Chromium security team rated this Medium internally — and they are right. The vector AV:L/AC:L/PR:L/UI:R/S:U tells you this is a post-compromise amplifier: the attacker must already have local code execution *and* needs user interaction to trigger the vulnerable code path. There is no public proof-of-concept, no exploitation in the wild, EPSS sits at the 0th percentile (0.08%), and CISA has not added it to KEV. The CVSS mechanical score is technically correct but fails to weight the compounding friction of local access plus user interaction plus zero weaponization — the conditions that actually determine whether a CVE matters on your Monday morning.

"Chrome Updater LPE is real but requires local footing and user interaction — no PoC, no ITW exploitation."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain local code execution on a Windows endpoint

The attacker must first achieve code execution as a standard (non-admin) user on a Windows host running a vulnerable version of Chrome. This could be via phishing, a compromised application, a watering-hole download, or any initial-access technique. The point is: this CVE *starts* post-compromise — it is not itself an entry point.

Conditions required:

Local code execution on the target Windows host
Standard user account (PR:L)
Chrome < 149.0.7827.53 installed

Where this breaks in practice:

Requires an independent initial-access chain — phishing, RDP credential reuse, or similar
EDR on the endpoint should flag initial access activity
Chrome auto-updates aggressively; many endpoints will already be patched

Detection/coverage: EDR telemetry for new process creation under user context; email gateway for phishing payloads

STEP 02

Stage malicious file in Updater-processed location

The attacker crafts a malicious file — likely a manipulated update payload, DLL, or symlink — and places it in a directory or path that the Chrome Updater will process during its next cycle. The exact file placement depends on the specifics of the dangling pointer: the freed object's vtable or callback pointer is overwritten by data from the attacker-controlled file. No public PoC exists, so the exact staging technique is not documented.

Conditions required:

Write access to a directory processed by the Chrome Updater
Knowledge of the freed object layout and heap state (requires reverse engineering)

Where this breaks in practice:

No public PoC or weaponized exploit — attacker must reverse-engineer the bug from the patch diff
Chrome Updater directory permissions may limit write access depending on enterprise hardening
Application whitelisting / SRP policies can block placement of unsigned files in Updater paths

Detection/coverage: File integrity monitoring on %ProgramFiles(x86)%\Google\Update\ and %LocalAppData%\Google\GoogleUpdate\; Sysmon Event ID 11 (FileCreate)

STEP 03

Trigger updater execution with user interaction

The CVSS vector specifies UI:R — the user or a user-driven process must trigger the Chrome Updater to process the staged file. This could involve opening Chrome (which checks for updates), clicking an update prompt, or the scheduled task firing while the user is logged in. The attacker cannot trigger this step silently without additional capabilities.

Conditions required:

Active user session on the target host
User triggers Chrome update check or Chrome auto-update fires during session

Where this breaks in practice:

User interaction requirement adds timing uncertainty and extends dwell time
In locked-down environments, scheduled task permissions for the updater may be restricted
SOC may detect anomalous updater behavior if process monitoring is in place

Detection/coverage: Process monitoring for GoogleUpdate.exe / updater.exe spawning unusual child processes; Sysmon Event ID 1 with parent process updater.exe

STEP 04

Use-after-free triggers SYSTEM code execution

When the updater processes the staged file, the freed memory is reallocated with attacker-controlled data. The dangling pointer is dereferenced, redirecting execution to attacker-controlled code running as NT AUTHORITY\SYSTEM. The attacker now has full host-level privilege escalation — they can dump credentials, install persistence, disable security tooling, or pivot laterally.

Conditions required:

Heap layout must be groomed correctly for reliable exploitation
Updater processes the malicious file without crashing

Where this breaks in practice:

Use-after-free exploitation on modern Windows requires bypassing CFG (Control Flow Guard) and ASLR
Chrome is compiled with hardened allocators (PartitionAlloc) that make UAF exploitation harder in general, though the Updater component's allocator specifics are less documented
Crash = detection opportunity; unreliable exploits generate telemetry

Detection/coverage: EDR behavioral detection for SYSTEM-level process spawned by updater.exe; Windows Event Log 4688 for privilege escalation; crash dumps in Windows Error Reporting

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Verify Chrome auto-update has already patched to ≥ 149.0.7827.53 — Chrome's aggressive auto-update means most managed endpoints should already be patched — this bug was fixed nearly 4 months ago (June 4, 2026). Run your SCCM/Intune/JAMF/BigFix query to confirm coverage. Any endpoint still below 149.0.7827.53 after 4 months indicates a broken update pipeline, not a patching decision. No mitigation SLA applies for MEDIUM — go straight to the 365-day noisgate remediation SLA and confirm your fleet is clean.

MEDIUM 5.5→LOW 2.5

SEVERITY REDUCED

Restrict write access to Chrome Updater directories via NTFS ACLs — Lock down %ProgramFiles(x86)%\Google\Update\ and %LocalAppData%\Google\GoogleUpdate\ so standard users cannot write files into paths the updater processes. This breaks step 2 of the attack path (file staging) without affecting Chrome's normal update functionality, since the updater itself runs as SYSTEM and writes to these paths from signed Google sources. Deploy via Group Policy Preferences or your endpoint management tool within the 365-day remediation window.

MEDIUM 5.5→MEDIUM 4.5

Enable process-level monitoring for updater child processes — Configure EDR or Sysmon to alert on GoogleUpdate.exe or updater.exe spawning unexpected child processes (anything other than chrome.exe or setup.exe). This provides detection coverage for step 4 of the attack path. The rule is low-noise because the updater's normal child process tree is predictable and narrow.

MEDIUM 5.5→LOW 2.0

SEVERITY REDUCED

Deploy application control / WDAC to block unsigned code in Updater paths — Windows Defender Application Control (WDAC) or AppLocker can enforce code integrity on the Chrome Updater directory, ensuring only Google-signed binaries execute. This directly prevents the UAF exploitation payload from running even if the memory corruption succeeds. Deploy as part of your standard application control rollout within the 365-day window.

What doesn't work

Network segmentation / firewall rules — this is a local-only vulnerability with no network component. Firewall rules and network segmentation have zero effect on the attack path.
Web proxy / URL filtering — the attack does not involve fetching a malicious URL. The malicious file is placed locally by an attacker who already has code execution.
Chrome browser policies (extension blocklists, Safe Browsing) — these control browser behavior, not the Updater component. The Updater is a separate process with its own execution context and is not governed by Chrome browser policies.
Disabling Chrome auto-update — this *increases* risk by preventing the patch from being applied. Do not disable auto-update as a mitigation.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	None observed. Not listed in CISA KEV. No campaigns or threat actor usage documented. Google confirmed no ITW exploitation at time of Chrome 149 release.
Proof-of-Concept Availability	No public PoC found. Checked pocindex.io (404/no entry), GitHub (no repos named CVE-2026-11115), ExploitDB, SecureWithUmer/CVE-2026-PoCs collection, and nuclei templates — all negative. The Chromium issue #501370283 is access-restricted.
EPSS Score	0.00079 (0.08%) — 0th percentile. FIRST's model assigns near-zero probability of exploitation in the next 30 days.
KEV Status	Not listed. As of 2026-09-30, CVE-2026-11115 is not in CISA's Known Exploited Vulnerabilities catalog.
CVSS Vector Interpretation	`CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H` — Local vector with user interaction requirement. Scope:Unchanged means impact is confined to the vulnerable component's host. The UI:R metric is the critical limiter: exploitation cannot be fully automated.
Chromium Internal Severity	Medium — Google's own security team rated this Medium, not High. This is a meaningful signal: the CNA (Chrome) assessed the real-world risk as lower than the NVD CVSS suggests.
Affected Versions	Google Chrome on Windows < 149.0.7827.53. All prior versions on the Windows platform are affected. macOS and Linux are not affected — the bug is Windows-specific in the Updater component.
Fixed Version	Chrome 149.0.7827.53 (Stable channel, released 2026-06-04). Chrome auto-update should have pushed this to most managed endpoints within 1-2 weeks of release.
Scanning / Exposure Data	Not applicable for GreyNoise/Shodan/Censys — this is a local-only vulnerability (AV:L). No network-facing exposure surface exists. Enterprise exposure = number of Windows endpoints running Chrome < 149.0.7827.53.
Reporting Researcher	Not publicly attributed. The Chrome release notes and CVE record do not credit a named researcher. The Chromium bug tracker issue is restricted. Likely reported via Chrome VRP (Vulnerability Reward Program).

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Local-only, post-compromise position: AV:L means the attacker must already have code execution on the Windows host. This CVE is a chain link, not an entry point. Every defender-hour spent on this is an hour not spent on the remote code execution that gets the attacker onto the box in the first place.
User interaction required: UI:R adds a timing and reliability barrier. The attacker cannot silently trigger the updater — they must wait for a user-driven event or the scheduled update task during an active session. This compounds with the local-access requirement to make reliable exploitation significantly harder.
Zero weaponization: No public PoC exists anywhere — not on pocindex.io, GitHub, ExploitDB, or nuclei. EPSS is 0.08% (0th percentile). Developing a reliable UAF exploit against Chrome's hardened build (CFG, ASLR, PartitionAlloc-adjacent allocator) is non-trivial work that no one has publicly done.
CNA disagrees with NVD: Google's Chromium security team — the people who wrote the code and reviewed the bug — rated this Medium. When the CNA downgrades their own bug relative to the mechanical CVSS, that is a strong signal about real exploitability.
Role multiplier: Chrome is installed on ~90%+ of enterprise Windows endpoints, spanning workstations (low-value), application servers (typical), and admin workstations (high-value). On an admin workstation, user → SYSTEM enables credential dumping and lateral movement — but this is the generic value of *any* LPE, not unique to this CVE. Chrome is not a canonically high-value-role component (it is not a DC, IdP, hypervisor, PAM, backup system, or network edge). The blast radius is host-level, not domain/fleet/supply-chain. The HIGH floor does not apply because the outcome is bounded to the exploited host — domain compromise requires additional, independent chain steps that are not part of this CVE.

Why not higher?

The vendor NVD score of 7.3 HIGH would be appropriate if this bug had a public PoC, any ITW exploitation, or if the Updater component were remotely reachable. None of those conditions hold. The CNA (Google) internally rates this Medium, EPSS is near-zero, and the attack requires both prior local access and user interaction — two compounding prerequisites that dramatically narrow the exploitable population at any given time. Chrome is not a canonically high-value-role component, so the HIGH floor rule does not apply.

Why not lower?

Chrome is the most widely deployed browser on Windows — any LPE in its SYSTEM-privileged updater has enormous *potential* reach if a PoC emerges. The updater's SYSTEM execution context means successful exploitation grants the highest local privilege, which is a genuine prize for post-compromise operators building credential-harvesting or persistence chains. The bug is mechanically real (UAF with C:H/I:H/A:H impact), and a motivated attacker with reverse-engineering capability could weaponize it from the patch diff. These factors keep it above LOW.

06 · Verification

Crowdsourced verification payload.

Run on each target Windows host (or push via your RMM/endpoint management tool). Requires no special privileges — reads the Chrome version from the registry. Example: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-11115.ps1

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

#Requires -Version 3.0
<#
.SYNOPSIS
  Check if the local Chrome installation is vulnerable to CVE-2026-11115
  (Use-after-free in Updater, Windows only, fixed in 149.0.7827.53)
.OUTPUTS
  VULNERABLE | PATCHED | UNKNOWN
#>

$ErrorActionPreference = 'SilentlyContinue'
$fixedVersion = [Version]'149.0.7827.53'
$regPaths = @(
    'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
    'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
    'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
)

$chromeVersion = $null
foreach ($rp in $regPaths) {
    $val = (Get-ItemProperty -Path $rp -Name 'version' -ErrorAction SilentlyContinue).version
    if ($val) {
        try {
            $parsed = [Version]$val
            if (-not $chromeVersion -or $parsed -gt $chromeVersion) {
                $chromeVersion = $parsed
            }
        } catch { }
    }
}

# Fallback: check chrome.exe file version
if (-not $chromeVersion) {
    $chromePaths = @(
        "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
        "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
        "$env:LocalAppData\Google\Chrome\Application\chrome.exe"
    )
    foreach ($cp in $chromePaths) {
        if (Test-Path $cp) {
            try {
                $fi = (Get-Item $cp).VersionInfo.ProductVersion
                $chromeVersion = [Version]$fi
                break
            } catch { }
        }
    }
}

if (-not $chromeVersion) {
    Write-Output 'UNKNOWN - Chrome not detected on this host'
    exit 2
}

Write-Output "Detected Chrome version: $chromeVersion"
Write-Output "Fixed version:           $fixedVersion"

if ($chromeVersion -lt $fixedVersion) {
    Write-Output 'VULNERABLE - Chrome is below 149.0.7827.53 (CVE-2026-11115)'
    exit 1
} else {
    Write-Output 'PATCHED - Chrome is at or above 149.0.7827.53'
    exit 0
}