← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11123 · 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 smudged carbon copy in the browser's graphics stack, not a master key

CVE-2026-11123 is an *uninitialized use* bug in ANGLE, Chrome's graphics translation layer, affecting Google Chrome versions before 149.0.7827.53. A malicious page can drive the vulnerable code path and cause the browser to expose stale process memory to the attacker, meaning the practical impact is information disclosure rather than code execution. The affected product status published by Chrome marks Chrome < 149.0.7827.53 as vulnerable, with the fix landing in the 149.0.7827.53 release train.

Google labels the bug's *Chromium security severity* as Medium, and that lines up with reality. The attacker gets web reach, which matters because Chrome is everywhere, but the payload here is a memory leak with user interaction, not a sandbox escape, not renderer RCE, and not OS compromise. For enterprise prioritization, this is a browser hygiene patch, not an all-hands emergency.

"Reachable through the web, but it leaks bytes—not control—and the real-world attack path still depends on a user visit."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a crafted HTML/WebGL page

The attacker needs the target to load a malicious page that exercises ANGLE through browser-rendered graphics content. In practice this means phishing, malvertising, or compromising a site the user already visits; there is no server-side exposure to scan from the internet.
Conditions required:
  • Target is running Chrome earlier than 149.0.7827.53
  • User visits attacker-controlled or attacker-influenced web content
  • ANGLE-capable graphics path is available on the endpoint
Where this breaks in practice:
  • Requires user interaction rather than unauthenticated service reachability
  • Enterprise DNS filtering, browser isolation, SWG, or ad-blocking reduce delivery success
  • Some enterprise fleets suppress risky GPU paths with browser policy or VDI rendering differences
Detection/coverage: Network scanners will miss this; detection is mostly version-based in EDR, MDM, or software inventory.
STEP 02

Trigger the ANGLE uninitialized-use condition

A custom HTML/graphics sequence drives the vulnerable ANGLE code path and reads back uninitialized memory from the affected process. No public weaponized repository was located during this assessment; assume a bespoke PoC rather than mass exploitation kit support.
Conditions required:
  • Precise page logic hits the buggy ANGLE path
  • Browser process state yields readable leftover bytes
Where this breaks in practice:
  • Uninitialized-memory leaks are often noisy and inconsistent across hardware, drivers, and platform builds
  • Leak quality is usually bounded by whatever stale bytes happen to be present at the moment of access
Detection/coverage: Behavioral coverage is weak unless the attempt crashes; browser crash telemetry and GPU-process anomalies may provide indirect signal.
STEP 03

Harvest useful data from leaked process memory

The attacker still has to parse the returned bytes into something operationally useful: tokens, fragments of rendered content, or other sensitive remnants. That is materially weaker than direct arbitrary read primitives because the disclosure is opportunistic and typically partial.
Conditions required:
  • Leaked bytes contain sensitive data at the time of exploitation
  • Attacker can exfiltrate and interpret the disclosed memory
Where this breaks in practice:
  • Impact is confidentiality-only; no integrity or availability control is granted
  • The blast radius is limited to what is resident in the affected browser process at that moment
Detection/coverage: DLP and browser egress controls may catch obvious exfiltration, but most detections will not attribute it specifically to this CVE.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence located in the sources reviewed; the CVE is not KEV-listed.
Public PoC availabilityNo public GitHub/Exploit-DB PoC found during this assessment; likely currently a researcher/vendor-only bug path.
EPSS0.00035 from the user-provided intel block; percentile not independently confirmed from an accessible primary query during this assessment.
KEV statusNo; absent from the CISA Known Exploited Vulnerabilities Catalog as assessed.
Vendor severity signalChrome CNA record marks this as Chromium security severity: Medium; there is no vendor/authority CVSS score published for this CVE.
Affected versionsGoogle Chrome < 149.0.7827.53 per the published CVE record mirrored by Vulnerability-Lookup.
Fixed version149.0.7827.53; early stable desktop rollout references 149.0.7827.53/.54 for Windows and Mac, and the CVE record references the June 2026 stable desktop advisory.
CVSS vector interpretationAssessed, not published: closest real-world shape is AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N — web-reachable, user-assisted, confidentiality-only.
Scanning / exposure dataNot internet-scannable in any meaningful way; Shodan/Censys/FOFA-style exposure counts are largely irrelevant because this is a client-side browser bug, not a listening service.
Disclosure / reporterPublished 2026-06-04 by the Chrome CNA; Chromium issue reference is 501505198.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.6/10)

The decisive downward pressure is that this bug is a user-driven browser memory disclosure, not a no-click server flaw and not a control-taking primitive. It is broadly reachable because Chrome is ubiquitous, but the actual impact stays in the partial-confidentiality lane and there is no evidence here of mass exploitation or easy weaponization.

MEDIUM Overall severity assessment
HIGH Affected version and patch version identification
MEDIUM Exploitability assumptions in real enterprise fleets

Why this verdict

  • User interaction required: the attacker needs a user to render a crafted page, which is materially weaker than an unauthenticated remote service bug.
  • Impact is confidentiality-only: this is a memory leak from ANGLE, not sandbox escape, not arbitrary code execution, and not host compromise.
  • Population is huge but exposure is client-side: Chrome's footprint keeps this relevant, yet it is not a directly exposed edge service that can be mass-scanned and indiscriminately hammered.
  • Threat telemetry is cold: no KEV listing, very low EPSS from the supplied intel, and no public PoC located reduce immediate attacker pressure.

Why not higher?

To justify HIGH, I would want either stronger impact or stronger attacker proof: active exploitation, a clean public exploit path, or a pivot from leak to sandbox escape. None of that is present in the published record for this CVE. The current story is a browser memory disclosure with user interaction and partial payoff.

Why not lower?

I am not pushing this to LOW because Chrome is a massively deployed attack surface and a web-delivered bug can still be exercised at scale through phishing or malvertising. Even partial browser-process disclosure can expose data you care about, especially for users handling sensitive web apps.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Make sure desktop management actually converges endpoints onto 149.0.7827.53+. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but for a browser fleet you should still validate update drift quickly rather than let stragglers age out.
  2. Reduce untrusted web exposure — Push high-risk users through secure web gateway filtering, browser isolation, or stricter ad/tracker blocking where available. These controls reduce the chance users ever render the malicious page; for MEDIUM, there is no noisgate mitigation SLA, so use this as risk reduction where patch latency is unavoidable.
  3. Inventory laggards aggressively — Query EDR/MDM/software inventory for Chrome versions below 149.0.7827.53 and treat unmanaged endpoints as exceptions. For this severity bucket, the deadline driver is the ≤365-day remediation window, not an emergency interim block.
  4. Harden browser egress for sensitive groups — For admins, finance, and developers, tighten outbound web categories and scrutinize access to newly seen domains. It won't fix the bug, but it lowers the odds of the user ever hitting the exploit page while you complete remediation inside the allowed window.
What doesn't work
  • A WAF does not help; the vulnerable component is the client browser, not your web application edge.
  • Network perimeter scans do not prove safety; this CVE is not a listening service exposure.
  • MFA is good hygiene but irrelevant to the exploit path itself; it does not stop the browser from rendering a malicious page.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your remote execution tooling (python3 chrome_cve_check.py on macOS/Linux, py chrome_cve_check.py on Windows). It needs no admin privileges if Chrome is installed in standard user/system locations; it returns VULNERABLE, PATCHED, or UNKNOWN and exits 0, 1, or 2 respectively.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check local Google Chrome / Chromium version against CVE-2026-11123 fixed version
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

FIXED = (149, 0, 7827, 53)


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


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


def windows_candidates():
    local = os.environ.get('LOCALAPPDATA', '')
    program_files = os.environ.get('ProgramFiles', '')
    program_files_x86 = os.environ.get('ProgramFiles(x86)', '')
    return [
        Path(program_files) / 'Google/Chrome/Application/chrome.exe',
        Path(program_files_x86) / 'Google/Chrome/Application/chrome.exe',
        Path(local) / 'Google/Chrome/Application/chrome.exe',
        Path(program_files) / 'Chromium/Application/chrome.exe',
        Path(program_files_x86) / 'Chromium/Application/chrome.exe',
        Path(local) / 'Chromium/Application/chrome.exe',
    ]


def mac_candidates():
    return [
        Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        Path('/Applications/Chromium.app/Contents/MacOS/Chromium'),
        Path.home() / 'Applications/Chromium.app/Contents/MacOS/Chromium',
    ]


def linux_candidates():
    names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    found = []
    for name in names:
        p = shutil.which(name)
        if p:
            found.append(Path(p))
    found.extend([
        Path('/opt/google/chrome/chrome'),
        Path('/usr/bin/google-chrome'),
        Path('/usr/bin/google-chrome-stable'),
        Path('/usr/bin/chromium'),
        Path('/usr/bin/chromium-browser'),
    ])
    return found


def get_version_from_binary(path):
    if not path.exists():
        return None
    out = run_cmd([str(path), '--version'])
    ver = parse_version(out)
    if ver:
        return ver, str(path), out.strip()
    return None


def main():
    system = platform.system().lower()
    candidates = []

    if 'windows' in system:
        candidates = windows_candidates()
    elif 'darwin' in system:
        candidates = mac_candidates()
    else:
        candidates = linux_candidates()

    seen = set()
    results = []
    for c in candidates:
        c = Path(c)
        key = str(c)
        if key in seen:
            continue
        seen.add(key)
        info = get_version_from_binary(c)
        if info:
            results.append(info)

    if not results:
        print('UNKNOWN - Chrome/Chromium binary not found or version unreadable')
        sys.exit(2)

    # choose highest discovered version
    results.sort(key=lambda x: x[0], reverse=True)
    ver, path, raw = results[0]
    ver_str = '.'.join(str(x) for x in ver)
    fixed_str = '.'.join(str(x) for x in FIXED)

    if ver < FIXED:
        print(f'VULNERABLE - detected {ver_str} at {path}; fixed version is {fixed_str}')
        sys.exit(1)
    else:
        print(f'PATCHED - detected {ver_str} at {path}; fixed version is {fixed_str}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like a Chrome zero-day fire drill. Pull an inventory of all endpoints still on Chrome < 149.0.7827.53, confirm that auto-update and desktop management are actually moving them forward, and fold the stragglers into your normal browser patch ring. For a MEDIUM verdict there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window; there is also noisgate remediation SLA of ≤365 days, though in practice most enterprises should clear browser laggards far sooner than that as part of routine endpoint hygiene.

Sources

  1. Chrome CNA record mirror for CVE-2026-11123
  2. Chromium issue 501505198
  3. Chrome stable desktop advisory referenced by the CVE record
  4. Chrome early stable desktop update 149.0.7827.53/.54
  5. Chrome beta desktop update 149.0.7827.53
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS data documentation
  8. FIRST EPSS API endpoint pattern for per-CVE lookups
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.