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

Uninitialized Use in ANGLE in Google Chrome prior to 149

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

This is a peephole in the browser sandbox, not a front door into the enterprise

CVE-2026-11104 is an uninitialized-use bug in ANGLE affecting Google Chrome versions prior to 149.0.7827.53 on desktop release trains associated with that fix. In plain terms, once an attacker already has code execution inside Chrome's renderer process, a crafted HTML page can coax ANGLE into exposing uninitialized process memory and potentially reveal sensitive data from that renderer.

Google's MEDIUM/6.5 baseline is defensible in a vacuum, but it overstates operational urgency for enterprise patch queues. The decisive friction is the prerequisite: the attacker must *already have compromised the renderer process*, which means this is not an initial-access bug and not a standalone browser takeover; it is a post-compromise information leak that matters mostly as part of a larger exploit chain.

"Useful only as a chain helper: it needs a renderer compromise first and then leaks memory, not code execution"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a separate renderer compromise

The attacker first needs a different browser bug or exploit chain to gain execution inside Chrome's renderer process. Weaponized tooling here is a separate custom browser exploit, not this CVE itself. Without that first-stage primitive, CVE-2026-11104 does nothing.
Conditions required:
  • User visits attacker-controlled content
  • Attacker has a separate working renderer-compromise exploit
  • Target is running a vulnerable Chrome build
Where this breaks in practice:
  • This CVE is not an entry point
  • Modern Chrome hardening, site isolation, and rapid browser updates raise the bar for landing stage one
  • Exploit developers must spend a real exploit just to reach this bug
Detection/coverage: Most scanners will flag vulnerable versioning, but no scanner can prove exploitability without a separate renderer-compromise path. EDR/browser telemetry may only see the precursor crash or anomalous renderer behavior.
STEP 02

Trigger the ANGLE uninitialized read

With renderer control in place, the attacker serves or manipulates crafted HTML/graphics content that exercises the vulnerable ANGLE path. The practical 'tool' is a custom proof-of-concept or exploit harness embedded in web content. This step turns an already-compromised renderer into a memory disclosure primitive.
Conditions required:
  • Renderer compromise already achieved
  • ANGLE code path reachable on the target platform/build
  • Attacker can deliver crafted page content to the active browser session
Where this breaks in practice:
  • ANGLE behavior can vary by platform, GPU stack, driver path, and build
  • Uninitialized-use disclosures are often less deterministic than clean memory corruption primitives
  • Browser restarts and version churn break exploit reliability quickly
Detection/coverage: Version-based detection is straightforward. Runtime detection is weak unless you have crash telemetry, browser exploit protection telemetry, or deep sandbox/graphics instrumentation.
STEP 03

Extract useful process memory

The attacker attempts to read sensitive bytes from renderer memory, such as residual document data, tokens, or data useful for a follow-on bypass. The exploit value depends on what happens to be resident in memory at the moment; this is a data leak, not direct code execution or direct sandbox escape. The effective weapon here is memory harvesting logic inside the exploit chain.
Conditions required:
  • Leak returns stable and parseable memory contents
  • Valuable secrets are present in renderer memory
  • Attacker can exfiltrate or reuse disclosed data
Where this breaks in practice:
  • Leaked bytes may be noisy, partial, or low value
  • Renderer memory scope is narrower than full browser or OS compromise
  • Data usefulness is highly situational
Detection/coverage: Very limited direct detection. You are more likely to catch the precursor exploit, odd renderer crashes, or suspicious outbound traffic than the leak itself.
STEP 04

Chain the leak into something bigger

In the best attacker case, the disclosure helps stabilize another exploit, bypass mitigations, or recover sensitive context for lateral web abuse. That makes this CVE a chain-enabler rather than a one-bug catastrophe. The 'weaponized tool' is the broader multi-stage browser exploit chain.
Conditions required:
  • Attacker has another primitive that benefits from leaked memory
  • Leaked data materially improves exploit reliability or access
  • Target session contains high-value data
Where this breaks in practice:
  • Requires a second bug or meaningful post-leak objective
  • Not every renderer compromise needs this helper primitive
  • Blast radius usually remains within the browser session, not the enterprise fleet
Detection/coverage: Threat hunting should focus on the surrounding chain: browser crashes, suspicious child processes, anomalous network activity, and signs of browser sandbox bypass attempts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in reviewed sources, and the user-provided intel says KEV listed: No.
KEV statusNot in CISA KEV as of the reviewed catalog source; no emergency exploitation signal from KEV.
PoC availabilityNo public PoC or named researcher exploit repository surfaced in reviewed sources. The Chromium issue exists at issue 500501226 but is access-restricted.
EPSS0.00035 from the user-provided intel, which is *extremely low* on its face; I did not independently verify the percentile value from a live API response in this workflow.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N translates to web-deliverable content plus user interaction, with impact limited to confidentiality. That still overstates real enterprise urgency because the description adds a non-CVSS prerequisite: the renderer must already be compromised.
Affected versionsGoogle Chrome prior to 149.0.7827.53; the official Chrome release post ties the desktop early stable update to 149.0.7827.53/.54 depending on platform.
Fixed versionsGoogle patched in Chrome 149.0.7827.53 on the release line cited by the Chrome Releases post. For browser derivatives, do not assume upstream Chromium version parity means identical fix timing.
Exposure realityShodan/Censys/GreyNoise style internet census is not meaningful here because Chrome is endpoint client software, not an externally enumerable server surface. Your exposure question is fleet version inventory, not internet attack-surface count.
Disclosure datePublished 2026-06-04 in the CVE record mirrored by CIRCL.
Reporting / provenancePublic provenance is thin: the Chrome CNA CVE record references the Chrome release advisory and a Chromium issue, but the accessible sources reviewed do not expose a public reporter credit.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.9/10)

The single biggest severity killer is the attacker position requirement: this bug only matters after a renderer compromise already exists. That makes it a chain helper with narrow standalone value, and that is not where a 10,000-host patch program should spend scarce urgency.

HIGH Assessment that the prerequisite chain materially reduces real-world urgency
MEDIUM Assessment that there is no public exploitation or public PoC at time of review

Why this verdict

  • Requires prior renderer compromise: attacker position is not unauthenticated remote entry; it implies a separate exploit has already beaten Chrome's renderer boundary, which is major downward pressure on severity.
  • Client-side exposure is broad but reachable population for the vulnerable step is narrow: many enterprises run Chrome, but only a tiny subset of sessions will ever reach this bug because an earlier compromise stage must already exist.
  • Impact is confidentiality-only: this is a memory disclosure primitive, not direct sandbox escape, OS code execution, or persistence by itself.
  • Threat intel is cold: no KEV listing, no reviewed public exploitation evidence, and user-provided EPSS is extremely low.
  • Modern controls should stop earlier steps: browser updates, exploit mitigations, EDR, and web filtering are more likely to matter against the initial renderer exploit than against this leak primitive itself.

Why not higher?

If this were a one-click renderer RCE or a sandbox escape, the score would climb fast because Chrome is everywhere. But this CVE sits behind a prior compromise requirement, and that prerequisite compounds heavily in real deployments. It is a helper primitive, not the breach opener.

Why not lower?

It is not IGNORE because browser exploit chains are real, and information leaks can materially improve exploit reliability or expose session data. On a fleet this large, browsers are high-churn attack targets, so even low-priority chain components still deserve routine hygiene tracking.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update and relaunch compliance — Make sure Chrome's enterprise update controls are actually moving endpoints to 149.0.7827.53 or later and that users relaunch the browser so the fix is loaded. For a LOW verdict there is no mitigation SLA and no remediation SLA beyond backlog hygiene, so handle this in the next normal browser hygiene sweep rather than disrupting higher-risk work.
  2. Prioritize high-risk user tiers for version cleanup — Focus first on admins, developers, finance, and users who regularly browse untrusted content, because browser exploit chains hurt most where session value is highest. Even at LOW, these cohorts are where a chained information leak is most likely to matter.
  3. Monitor browser crash and exploit telemetry — Collect Chrome crash data, EDR browser exploit alerts, and suspicious renderer/process ancestry because direct detection of the leak is poor. This helps you catch the *preceding* renderer compromise step, which is the real choke point.
  4. Use isolation for risky browsing paths — Remote browser isolation or hardened VDI for internet-facing admin activity reduces the value of browser exploit chains by separating risky browsing from privileged sessions. Treat this as structural risk reduction, not an emergency mitigation for this specific CVE.
What doesn't work
  • A WAF does not help; this is client-side browser processing, not a server endpoint bug.
  • Perimeter vulnerability scanning will not measure exposure; Chrome is not internet-enumerable in the way a VPN or web server is.
  • MFA is good hygiene but does not prevent a compromised renderer from reading process memory already present in the browser.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your desktop management tooling with local user rights; admin is usually not required unless your EDR blocks registry/process inspection. Invoke it with python3 check_chrome_cve_2026_11104.py on macOS/Linux or py check_chrome_cve_2026_11104.py on Windows; it checks common Chrome install locations/registry keys and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11104.py
# Detects whether local Google Chrome appears vulnerable to CVE-2026-11104
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys

TARGET = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def parse_version(text):
    if not text:
        return None
    m = VERSION_RE.search(text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_version(a, b):
    if a == b:
        return 0
    return -1 if a < b else 1


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def check_windows_registry():
    try:
        import winreg
    except Exception:
        return None, None

    reg_paths = [
        (winreg.HKEY_CURRENT_USER, r'SOFTWARE\Google\Chrome\BLBeacon'),
        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
    ]

    for hive, path in reg_paths:
        try:
            key = winreg.OpenKey(hive, path)
            version, _ = winreg.QueryValueEx(key, 'version')
            parsed = parse_version(version)
            if parsed:
                return version, parsed
        except Exception:
            continue
    return None, None


def check_windows_files():
    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
    ]
    for exe in candidates:
        if exe and os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            parsed = parse_version(out)
            if parsed:
                return exe, parsed
    return None, None


def check_macos():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for exe in candidates:
        if os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            parsed = parse_version(out)
            if parsed:
                return exe, parsed
    return None, None


def check_linux():
    candidates = [
        'google-chrome',
        'google-chrome-stable',
        'chromium',
        'chromium-browser',
    ]
    for cmd in candidates:
        full = shutil.which(cmd)
        if full:
            out = run_cmd([full, '--version'])
            parsed = parse_version(out)
            if parsed:
                return full, parsed
    return None, None


def main():
    system = platform.system().lower()
    source = None
    version = None

    if 'windows' in system:
        source, version = check_windows_registry()
        if not version:
            source, version = check_windows_files()
    elif 'darwin' in system:
        source, version = check_macos()
    elif 'linux' in system:
        source, version = check_linux()
    else:
        print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
        sys.exit(2)

    if not version:
        print('UNKNOWN - could not determine local Chrome version')
        sys.exit(2)

    if cmp_version(version, TARGET) < 0:
        print('VULNERABLE - detected version {} via {}'.format('.'.join(map(str, version)), source))
        sys.exit(1)
    else:
        print('PATCHED - detected version {} via {}'.format('.'.join(map(str, version)), source))
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: verify which endpoints are still below 149.0.7827.53, make sure Chrome auto-update and relaunch enforcement are working, and fold stragglers into your normal desktop browser cleanup rather than preempting edge, identity, or server-side emergencies. For this LOW reassessment there is noisgate mitigation SLA: no SLA and noisgate remediation SLA: no SLA — treat as backlog hygiene, so the right move is routine version hygiene this month, not an out-of-band patch fire drill.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop
  2. Chromium issue 500501226
  3. CIRCL Vulnerability Lookup - CVE-2026-11104
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. SecurityWeek coverage of Chrome 149 fixes
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.