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

Out of bounds read in ANGLE in Google Chrome prior to 149

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

This is a crack in the vault wall, but only after the attacker is already inside the bank

CVE-2026-11004 is an out-of-bounds read in Chrome's ANGLE graphics layer, fixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and Mac. In plain terms, malformed graphics-facing input can make Chrome read memory it should not, which typically means information disclosure or a crash rather than clean, first-shot code execution.

Reality is lower drama than a generic 'browser RCE' label would imply. Google published this specific record as Medium in the June 2, 2026 stable release notes, and the practical friction is decisive: the attacker has to first land a separate renderer compromise, so this bug is mainly useful as a second-stage chain helper rather than an initial access primitive.

"ASSESSED AT MEDIUM: this is a chain component that needs prior renderer compromise, not a standalone browser fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a renderer foothold first

The attacker needs a separate browser bug to gain code execution or equivalent control inside the renderer process. The realistic weaponized tool here is a crafted malicious site plus a separate renderer exploit chain; CVE-2026-11004 is not that first-stage bug. Without this foothold, the ANGLE read bug is not reachable in the way that matters.
Conditions required:
  • Target browses attacker-controlled content
  • Attacker has a distinct renderer compromise primitive
  • Chrome version is older than the fixed build
Where this breaks in practice:
  • Requires a prior browser exploit, which already narrows the attacker population to capable operators
  • Modern browser hardening, site isolation, and exploit mitigations make first-stage renderer compromise non-trivial
  • Exploit chain reliability drops sharply when two bugs must line up
Detection/coverage: Version scanners can identify vulnerable Chrome builds, but they cannot validate the presence of a usable first-stage renderer exploit.
STEP 02

Drive execution into ANGLE

From the compromised renderer, the attacker steers rendering or graphics code paths into ANGLE using hostile page content. The likely weaponized mechanism is crafted HTML/WebGL content that exercises the vulnerable memory-read path. This is a local-in-browser transition, not a network service exploit.
Conditions required:
  • GPU/ANGLE path is reachable on the target platform
  • Renderer can trigger the vulnerable code path
  • Browser is using affected ANGLE code
Where this breaks in practice:
  • ANGLE behavior varies by OS, GPU, driver, and backend
  • Some enterprise images reduce risky graphics paths via policy, VDI, or hardware acceleration controls
  • Cross-platform browser bugs often lose reliability across heterogeneous fleets
Detection/coverage: No meaningful perimeter signature. Telemetry is mainly crash data, renderer anomalies, and browser exploit behavior seen by EDR or browser security tooling.
STEP 03

Read unintended memory

The out-of-bounds read lets the attacker pull data from memory regions adjacent to the intended buffer. In practice that can expose process memory, object layout details, or values useful for exploit stabilization. The weaponized use is usually info-leak support for a larger exploit chain, not direct business impact by itself.
Conditions required:
  • The malformed input reliably triggers the read
  • Returned memory is attacker-usable
  • Mitigations do not turn the bug into a harmless crash
Where this breaks in practice:
  • Read bugs often yield noisy crashes instead of useful disclosure
  • Leaked data may be low-value or inconsistent between runs
  • Memory safety hardening can reduce reliability or observability
Detection/coverage: Exploit detection is weak; defenders usually see browser crashes, exploit-prevention alerts, or post-exploitation behaviors rather than a clean CVE-specific indicator.
STEP 04

Use the leak to improve a larger chain

If the read is stable, the attacker can use disclosed memory to bypass ASLR-like uncertainty, locate objects, or support a sandbox escape or credential/data theft attempt via another bug. The weaponized tool at this stage is a bespoke multi-bug browser chain. That is exactly why this CVE matters, but also why it should not be scored like a one-click standalone remote compromise.
Conditions required:
  • Attacker already has exploit-development maturity
  • A second-stage privilege or sandbox bypass primitive exists
  • Leaked memory materially improves chain reliability
Where this breaks in practice:
  • Requires multi-bug chaining and high operator skill
  • Enterprise EDR/browser protections may catch the chain before useful impact
  • No public in-the-wild evidence found as of 2026-06-05
Detection/coverage: Best coverage is behavioral: browser child-process abuse, suspicious process spawning, memory-corruption prevention alerts, and abnormal browser crash spikes.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found as of 2026-06-05; not listed in CISA KEV.
PoC availabilityNo public PoC or GitHub exploit repo was found in current source checks. The Chromium issue exists at issues.chromium.org/issues/494823889 but is access-restricted.
EPSSUser-provided EPSS is 0.00035. That is extremely low threat signal and consistent with a chain-only browser bug rather than mass exploitation.
KEV statusNo in CISA's Known Exploited Vulnerabilities Catalog as checked on 2026-06-05.
Vendor severity / scoringGoogle's Chrome stable release notes list CVE-2026-11004 as Medium severity, but no vendor CVSS score/vector was published.
Affected versionsChrome versions before 149.0.7827.53 are affected; the stable rollout notes show 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/Mac.
Fixed versionsUpgrade to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/Mac.
Scanning / exposure realityThis is an endpoint browser issue, not an internet-facing service. Shodan/Censys/FOFA-style exposure counts are not operationally useful; asset inventory and endpoint telemetry matter more.
Disclosure / reportingDisclosed on 2026-06-04. Chrome release notes say it was reported by 86ac1f1587b71893ed2ad792cd7dde32 on 2026-03-22.
Comparable casesSimilar ANGLE memory issues have ranged from Medium chain helpers to High/Critical when they supported direct escape or write primitives; compare CVE-2023-1534 and CVE-2026-10889. This record landed in Chrome's Medium bucket.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

The deciding factor is the attacker position requirement: this bug becomes valuable only after the attacker already has renderer compromise, which makes it a second-stage chain component instead of a standalone remote compromise path. Broad Chrome deployment matters, but the reachable population collapses once you require a prior browser foothold and a usable multi-bug chain.

HIGH Affected version cutoff and vendor severity
MEDIUM Real-world exploitability without a public technical root-cause writeup
HIGH No current exploitation signal from KEV / public-source review

Why this verdict

  • Baseline starts at Medium: Google's June 2, 2026 Chrome stable advisory publishes CVE-2026-11004 as a Medium issue and provides no CVSS score, so there is no numeric baseline to inherit.
  • Renderer compromise is the big downgrade pressure: requiring a prior renderer foothold implies the attacker already burned or bought a separate browser exploit. That is post-initial-access inside the browser security model, not broad one-click compromise across your fleet.
  • Reachable population is narrower than Chrome's install base suggests: virtually every enterprise has Chrome, but only a tiny slice of real attacks will have both a renderer exploit and a reliable ANGLE follow-on path on the right OS/GPU/driver mix.
  • Impact is read-only memory corruption: out-of-bounds read bugs are usually better at leaking memory or stabilizing another exploit than delivering direct, reliable code execution by themselves.
  • Threat telemetry is quiet: user-provided EPSS is very low (0.00035), there is no KEV entry, and no public PoC or campaign evidence was found as of 2026-06-05.

Why not higher?

This is not a clean unauthenticated remote compromise by itself. The need for prior renderer compromise is compounding friction, and there is no current evidence of active exploitation or a public exploit chain that turns this bug into a dependable enterprise-scale intrusion path.

Why not lower?

It still lives in a massively deployed internet-connected client and touches graphics parsing logic, which attackers routinely mine for exploit chains. Once a renderer foothold exists, even a read primitive can materially improve chain reliability or leak data that weakens sandbox isolation.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update compliance — Use your endpoint management stack to verify Chrome is moving to 149.0.7827.53+ and to close devices that have stalled update agents. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browsers should be folded into the next routine desktop patch wave, not left to drift for months.
  2. Block unsafe Chrome launch flags — Hunt for and prohibit --no-sandbox, --disable-gpu-sandbox, unmanaged portable Chromium builds, and developer-channel browsers. This reduces the value of second-stage browser bugs while your standard remediation cycle catches up.
  3. Prioritize hardened browsing for high-risk users — Apply browser isolation, VDI, or stricter Chrome Enterprise policy to admins, developers, executives, and users targeted by phishing. This is the right compensating control when the bug is mainly useful as part of a larger exploit chain rather than as a direct initial-access vector.
What doesn't work
  • A WAF or perimeter IDS does not meaningfully help; exploitation happens inside the local browser's rendering and graphics path, not against a server you can front with HTTP filtering.
  • MFA is unrelated to the vulnerability mechanics and does nothing to stop renderer-to-ANGLE memory corruption.
  • Internet exposure scans will not answer the real question because this is an endpoint version-management problem, not a remotely enumerable listening service.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/script runner. Invoke it as python3 chrome_cve_check.py or point it at a specific binary with python3 chrome_cve_check.py --path "/usr/bin/google-chrome"; no administrator privileges are required unless your environment restricts access to Chrome install paths or the Windows registry.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check for Chrome versions vulnerable to CVE-2026-11004
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

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

TARGET = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def ver_to_str(v):
    return '.'.join(str(x) for x in v)


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


def get_windows_version_from_registry():
    reg_paths = [
        r'HKLM\Software\Google\Chrome\BLBeacon',
        r'HKCU\Software\Google\Chrome\BLBeacon',
        r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
    ]
    for reg_path in reg_paths:
        out = run_cmd(['reg', 'query', reg_path, '/v', 'version'])
        v = parse_version(out)
        if v:
            return v, f'registry:{reg_path}'
    return None, None


def get_version_from_binary(path):
    out = run_cmd([path, '--version'])
    v = parse_version(out)
    if v:
        return v, path
    return None, None


def candidate_paths(user_path=None):
    paths = []
    if user_path:
        paths.append(user_path)

    for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
        p = shutil.which(name)
        if p:
            paths.append(p)

    system = platform.system().lower()
    if system == 'darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ])
    elif system == 'windows':
        local = os.environ.get('LOCALAPPDATA', '')
        program_files = os.environ.get('ProgramFiles', '')
        program_files_x86 = os.environ.get('ProgramFiles(x86)', '')
        paths.extend([
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ])
    else:
        paths.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/opt/google/chrome/chrome',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
        ])

    seen = set()
    deduped = []
    for p in paths:
        if p and p not in seen:
            seen.add(p)
            deduped.append(p)
    return deduped


def main():
    parser = argparse.ArgumentParser(description='Detect vulnerable Chrome versions for CVE-2026-11004')
    parser.add_argument('--path', help='Explicit path to Chrome binary')
    args = parser.parse_args()

    system = platform.system().lower()

    for p in candidate_paths(args.path):
        if os.path.exists(p):
            v, source = get_version_from_binary(p)
            if v:
                if v < TARGET:
                    print(f'VULNERABLE - detected Chrome version {ver_to_str(v)} from {source}; fixed version is {ver_to_str(TARGET)} or newer')
                    sys.exit(1)
                else:
                    print(f'PATCHED - detected Chrome version {ver_to_str(v)} from {source}; meets or exceeds fixed version {ver_to_str(TARGET)}')
                    sys.exit(0)

    if system == 'windows':
        v, source = get_windows_version_from_registry()
        if v:
            if v < TARGET:
                print(f'VULNERABLE - detected Chrome version {ver_to_str(v)} from {source}; fixed version is {ver_to_str(TARGET)} or newer')
                sys.exit(1)
            else:
                print(f'PATCHED - detected Chrome version {ver_to_str(v)} from {source}; meets or exceeds fixed version {ver_to_str(TARGET)}')
                sys.exit(0)

    print('UNKNOWN - could not determine an installed Chrome version; provide --path to the browser binary or verify installation method')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: treat this as fleet hygiene, not an incident-response emergency. Confirm Chrome auto-update health, identify endpoints still below 149.0.7827.53, and roll the fix through your normal browser maintenance ring; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window. If you need a concrete operational target, close stragglers in your next routine desktop/browser wave and ensure full patch completion within the noisgate remediation SLA of 365 days.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Chrome Releases - Early Stable Update for Desktop
  3. Chromium issue tracker entry for CVE-2026-11004
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data and statistics
  6. NVD - CVE-2023-1534 analogous ANGLE out-of-bounds read
  7. Chrome Releases - Stable Channel Update for Desktop (2023-03-21, CVE-2023-1534)
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.