← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11115 · CWE-416 · Disclosed 2026-06-04

Use after free in Updater in Google Chrome on Windows prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Useful for chaining after endpoint compromise, but this is not a fleet-wide fire drill: local-only, low-EPSS, no KEV, no public PoC."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code execution as a standard user

The attacker first needs a foothold on the Windows endpoint as a normal user. In practice that means phishing, a trojanized installer, a malicious document, or abuse of an already-compromised user session; this CVE does not provide initial access.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Vuln scanners can inventory Chrome versioning well; they generally cannot prove exploitability from version alone because exploitability depends on local attacker execution context and updater presence.
STEP 02

Feed crafted input into the privileged updater

The exploit path requires a malicious file to be consumed by the Windows updater component (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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Look for suspicious child process creation or unusual file activity around Chrome/Google updater binaries, especially execution from temp paths and abnormal invocations of updater.exe.
STEP 03

Trigger memory corruption for privilege escalation

Once the crafted input is processed, the use-after-free can let the attacker redirect control flow in the updater’s privileged context and cross from user-level access to SYSTEM/admin-equivalent OS privileges. This is the part that makes the bug operationally meaningful despite its local-only nature.
Conditions required:
  • Exploit reliability against the target build
  • A working primitive from the crafted file to privileged code execution
  • No hardening control blocks the final payload
Where this breaks in practice:
  • 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
Detection/coverage: Behavioral telemetry is better than signatures here: focus on updater spawning unexpected binaries, token elevation, service abuse, or SYSTEM-level child processes with user-writable ancestry.
STEP 04

Use elevated rights for persistence or defense evasion

After elevation, the attacker can disable protections, dump credentials, plant persistence, or stage lateral movement tooling. That makes the blast radius per compromised endpoint high even though the reachable population is small.
Conditions required:
  • Successful SYSTEM-level execution
  • Security tooling not blocking post-exploitation activity
Where this breaks in practice:
  • Privileged post-exploitation tends to generate stronger telemetry than the initial bug trigger
  • Lateral movement still depends on identity, segmentation, and admin path controls
Detection/coverage: EDR should alert on privilege escalation followed by LSASS access, service creation, scheduled task abuse, registry run-key persistence, or security product tampering.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found as of 2026-06-05; not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC located for CVE-2026-11115 in my review. The Chromium issue exists, but exploit details may remain restricted until patch uptake improves.
EPSS0.00008 (~0.008% probability in 30 days), which is consistent with a niche local-only bug rather than something internet-scale.
KEV statusNot KEV-listed; no CISA due date applies.
CVSS vectorCVSS: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 versionsGoogle Chrome on Windows prior to 149.0.7827.53. This is Windows-only per the CVE description.
Fixed versionUpgrade 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 realityShodan/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 / publicationChrome stable release published 2026-06-02; CVE record published 2026-06-04.
Reporter / sourceReported by Google in the Chrome 149 release notes; Chromium issue 501370283 is the referenced tracker.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.4/10)

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.

HIGH Windows-only local-privilege-escalation characterization
MEDIUM Exploitability in real enterprise updater configurations
MEDIUM No-public-PoC / no-in-the-wild assessment as of 2026-06-05

Why this verdict

  • Downgrade for attacker position: AV:L + PR:L + UI:R means 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: query your Windows fleet for Chrome < 149.0.7827.53, focus on unmanaged endpoints and systems with stale updater components, and close the gap through normal endpoint patching rather than incident-mode disruption. For a MEDIUM verdict there is noisgate mitigation SLAno mitigation SLA — go straight to the 365-day remediation window — and the noisgate remediation SLA is ≤ 365 days; in practice, Chrome should land much sooner because auto-update and standard workstation patch cycles should sweep this up without a special emergency campaign.

Sources

  1. Chrome Releases: Stable Channel Update for Desktop (Chrome 149)
  2. Chromium issue 501370283
  3. CVE Record: CVE-2026-11115
  4. Vulnerability-Lookup entry for CVE-2026-11115
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS data and statistics
  7. Chromium Updater Functional Specification
  8. Canadian Centre for Cyber Security Chrome 149 advisory
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.