This is a master key left inside the janitor’s closet, not a broken front door
CVE-2026-11115 is a use-after-free in the Chrome Updater on Windows that affects Chrome builds before 149.0.7827.53. The bug lives in the privileged update plumbing rather than the browser renderer, so the practical outcome is local privilege escalation to OS-level privileges when a low-privilege attacker can get the updater to process a malicious file on a vulnerable Windows host.
The supplied 7.3/HIGH baseline overshoots reality for enterprise prioritization. This is post-initial-access by definition: the attacker already needs a foothold on the endpoint, low-privileged code execution, and a path to feed the updater crafted input; there is no internet exposure, no KEV entry, very low EPSS, and I found no public PoC as of 2026-06-05. That keeps it important for hardening and cleanup of lagging Windows fleets, but not in the same league as remotely reachable Chrome bugs.
4 steps from start to impact.
Land code execution as a standard user
- Windows endpoint with vulnerable Chrome Updater
- Attacker already has local code execution or an interactive low-privilege session
- Chrome installed in a scope that deploys the updater on that host
- EDR commonly catches commodity first-stage payloads before an LPE chain is ever attempted
- Many enterprises already treat a local foothold as a separately contained incident
- This prerequisite alone narrows exposure from the whole fleet to already-compromised hosts
Feed crafted input into the privileged updater
updater.exe / Google Updater servicing path). Per the Chrome release and CVE record, the flaw is in Updater on Windows and results in OS-level privilege escalation when the crafted file reaches the vulnerable code path.- Attacker can place or reference a crafted file on disk
- Updater is present and vulnerable
- The vulnerable updater code path is reachable in the target install mode
- No public exploitation recipe was located for this CVE as of 2026-06-05
- Update-service behavior varies across system/user install scope and enterprise packaging
- Application control, tamper protection, and constrained write locations can make reliable file staging harder
updater.exe.Trigger memory corruption for privilege escalation
- Exploit reliability against the target build
- A working primitive from the crafted file to privileged code execution
- No hardening control blocks the final payload
- Modern Windows exploit mitigations and EDR memory protections often reduce reliability of local exploit chains
- Use-after-free bugs frequently need version-specific tuning
- Enterprise gold images may auto-update Chrome quickly, shrinking the vulnerable window
Use elevated rights for persistence or defense evasion
- Successful SYSTEM-level execution
- Security tooling not blocking post-exploitation activity
- Privileged post-exploitation tends to generate stronger telemetry than the initial bug trigger
- Lateral movement still depends on identity, segmentation, and admin path controls
The supporting signals.
| In-the-wild status | No public exploitation evidence found as of 2026-06-05; not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC located for CVE-2026-11115 in my review. The Chromium issue exists, but exploit details may remain restricted until patch uptake improves. |
| EPSS | 0.00008 (~0.008% probability in 30 days), which is consistent with a niche local-only bug rather than something internet-scale. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H — the big suppressors are AV:L, PR:L, and UI:R. Translation: attacker already has a user foothold and still needs a user-mediated file path. |
| Affected versions | Google Chrome on Windows prior to 149.0.7827.53. This is Windows-only per the CVE description. |
| Fixed version | Upgrade Windows endpoints to 149.0.7827.53 or later. The Chrome 149 stable release shipped on 2026-06-02; the CVE record was published on 2026-06-04. |
| Scanning / exposure reality | Shodan/Censys/FOFA are irrelevant here because this is not a remotely exposed service. Exposure is effectively bounded to Windows endpoints with vulnerable Chrome Updater installed. |
| Disclosure / publication | Chrome stable release published 2026-06-02; CVE record published 2026-06-04. |
| Reporter / source | Reported by Google in the Chrome 149 release notes; Chromium issue 501370283 is the referenced tracker. |
noisgate verdict.
The decisive downgrade driver is attacker position: this bug starts after the endpoint is already compromised by a low-privilege user, which dramatically shrinks the exposed population versus a remotely reachable Chrome flaw. The upside for attackers is real because it can yield SYSTEM-level privilege, but absent active exploitation, KEV status, or a public PoC, this is a containment and hygiene problem rather than an emergency patch sprint.
Why this verdict
- Downgrade for attacker position:
AV:L + PR:L + UI:Rmeans the attacker already has a foothold on the host and a user-mediated file path; this is not initial access and not internet-reachable - Further downgrade for reachable population: only Windows systems with a vulnerable Chrome Updater are in scope, so exposure is a subset of already-compromised endpoints rather than your whole browser estate
- Some score preserved for blast radius: if it lands, it can escalate to OS-level privileges, which materially improves persistence, credential theft, and defense evasion on that host
- No urgency amplifier present: not in KEV, no public exploit found, and EPSS 0.00008 all argue against treating this like an active browser zero-day
- Modern controls should break the chain early: EDR, application control, user-write restrictions, and browser auto-update all reduce the practical success rate before the updater bug matters
Why not higher?
If this were unauthenticated remote, actively exploited, or trivially weaponized with a public PoC, the score would climb fast because Chrome is everywhere. But the chain here begins with local attacker access and a malicious file, which compounds the friction and keeps the exposed population narrow.
Why not lower?
I am not pushing this to LOW because a working local privilege escalation to SYSTEM on a ubiquitous enterprise endpoint is still meaningful. Attackers do chain low-privilege footholds into LPE routinely, and Chrome’s updater runs in a privileged trust boundary that can turn a noisy compromise into a durable one.
What to do — in priority order.
- Harden application control — Enforce WDAC/AppLocker/Defender Application Control so untrusted binaries and scripts from user-writable locations cannot stage the local foothold or final payload. For a MEDIUM verdict there is no mitigation SLA; deploy in the normal hardening cycle if you are not already doing it.
- Constrain user-writable execution paths — Block or heavily monitor execution from
%TEMP%,%APPDATA%, downloads, and other user-controlled paths. This cuts the most common path to prerequisite local code execution and makes file-based LPE chains less reliable. - Monitor updater abuse — Create detections for abnormal launches of Chrome/Google updater binaries, especially unexpected child processes, temp-path ancestry, or SYSTEM processes spawned from updater activity. This is the best compensating visibility when you cannot patch every straggler immediately.
- Reduce standing local admin and repair drift — Even though the CVE only needs low privilege, cleaning up excess rights, stale software deployment patterns, and unmanaged user installs reduces the chance of exploitable updater configurations hanging around until the 365-day remediation window closes.
- A network firewall or proxy does not meaningfully help because the vulnerability is local-only and not exposed over a listening service
- A WAF is irrelevant; there is no HTTP attack surface in the exploit path
- Relying on MFA does not stop the bug itself; MFA may help prevent the initial foothold, but once code is already running locally it does not block updater memory corruption
Crowdsourced verification payload.
Run this on the target Windows endpoint or through your EDR/live-response shell. Invoke it as powershell.exe -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11115.ps1; standard user rights are usually enough to read file versions, but admin helps if you want complete coverage of machine-wide install paths.
# check-chrome-cve-2026-11115.ps1
# Detects whether Google Chrome on Windows is older than 149.0.7827.53
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
function Get-VersionObject {
param([string]$VersionString)
try { return [version]$VersionString } catch { return $null }
}
$fixed = Get-VersionObject '149.0.7827.53'
$paths = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$env:LocalAppData\Google\Chrome\Application\chrome.exe"
) | Select-Object -Unique
$found = @()
foreach ($p in $paths) {
if (Test-Path $p) {
$ver = (Get-Item $p).VersionInfo.ProductVersion
if (-not $ver) { $ver = (Get-Item $p).VersionInfo.FileVersion }
if ($ver) {
$found += [pscustomobject]@{ Path = $p; Version = $ver }
}
}
}
# Registry fallbacks
$regPaths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
)
foreach ($rp in $regPaths) {
$reg = Get-ItemProperty -Path $rp
if ($reg -and $reg.'(default)') {
$p = $reg.'(default)'
if ((Test-Path $p) -and -not ($found.Path -contains $p)) {
$ver = (Get-Item $p).VersionInfo.ProductVersion
if (-not $ver) { $ver = (Get-Item $p).VersionInfo.FileVersion }
if ($ver) {
$found += [pscustomobject]@{ Path = $p; Version = $ver }
}
}
}
}
if (-not $found -or $found.Count -eq 0) {
Write-Output 'UNKNOWN - Google Chrome executable not found in common locations'
exit 2
}
$vulnerable = $false
$unknown = $false
foreach ($item in $found) {
$v = Get-VersionObject $item.Version
if ($null -eq $v) {
Write-Output ("UNKNOWN - Could not parse version '{0}' at {1}" -f $item.Version, $item.Path)
$unknown = $true
continue
}
if ($v -lt $fixed) {
Write-Output ("VULNERABLE - {0} at {1}" -f $item.Version, $item.Path)
$vulnerable = $true
}
else {
Write-Output ("PATCHED - {0} at {1}" -f $item.Version, $item.Path)
}
}
if ($vulnerable) { exit 1 }
if ($unknown) { exit 2 }
exit 0
If you remember one thing.
Sources
- Chrome Releases: Stable Channel Update for Desktop (Chrome 149)
- Chromium issue 501370283
- CVE Record: CVE-2026-11115
- Vulnerability-Lookup entry for CVE-2026-11115
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS data and statistics
- Chromium Updater Functional Specification
- Canadian Centre for Cyber Security Chrome 149 advisory
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.