← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11137 · 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 a moving car, not a stolen ignition key

CVE-2026-11137 is an *uninitialized use* bug in Chrome's ANGLE graphics layer that affects Google Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. A malicious site can trigger the flaw through crafted web content and potentially disclose data from process memory, which is an information leak rather than direct code execution.

Google's MEDIUM label is basically fair. The attack starts remotely and Chrome is ubiquitous, but the real-world chain still requires *user interaction* and the technical impact is limited to confidentiality leakage from browser process memory; there is no public evidence here of sandbox escape, arbitrary code execution, or in-the-wild exploitation.

"Wide browser exposure keeps this relevant, but the chain ends at user-driven info leak, not code execution."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure a user to attacker-controlled web content

The attacker needs the victim to render a crafted page that exercises ANGLE code paths, realistically via a website, ad slot, or embedded third-party content. The practical weapon here is just custom HTML/JavaScript/WebGL content; no special implant is required at this stage.
Conditions required:
  • Target is running a vulnerable Chrome build prior to 149.0.7827.53 (149.0.7827.54 on Win/Mac is also fixed)
  • Victim visits or renders attacker-controlled content
  • ANGLE-relevant rendering path is reachable in that browsing session
Where this breaks in practice:
  • Requires user interaction (UI:R), which immediately narrows abuse versus wormable browser-server bugs
  • Enterprise URL filtering, ad blocking, safe browsing, email security, and browser isolation reduce how often crafted content is reached
  • Chrome auto-update shrinks dwell time on managed fleets faster than typical server-side CVEs
Detection/coverage: Traditional vuln scanners see version state well; they do *not* see exploit attempts on a webpage. Detection is mostly through browser telemetry, web proxy logs, safe browsing hits, or EDR child signals around suspicious browsing sessions.
STEP 02

Trigger uninitialized memory use in ANGLE

Once the page is rendered, attacker-controlled input steers the ANGLE component into reading uninitialized state. This is a memory-safety flaw, but the published impact for this CVE is information disclosure, not memory corruption leading to code exec.
Conditions required:
  • The specific buggy ANGLE path is exercised on the victim platform
  • Chrome process has memory contents worth leaking at the moment of access
Where this breaks in practice:
  • Graphics-path bugs can be platform- and driver-sensitive, which hurts reliability across a heterogeneous enterprise fleet
  • Browser hardening and sandboxing mean a renderer bug does not automatically become system compromise
Detection/coverage: Crash telemetry may catch unstable attempts, but a clean information leak may leave little signature. Public bug details are still restricted, which limits defender YARA-style reproduction-based detections.
STEP 03

Recover sensitive process memory

If exploitation is reliable, the attacker can potentially read stale or uninitialized browser-process memory exposed through the flawed path. That may include page data, tokens, or other transient material present in the vulnerable process at exploit time.
Conditions required:
  • Leaked memory region contains useful data
  • Attacker can parse and stabilize the leaked bytes
Where this breaks in practice:
  • Information leaks are inherently noisier and less deterministic than a straight RCE primitive
  • The value of the leak depends heavily on what happened to be in memory during that session
Detection/coverage: No network scanner will tell you this happened. Browser exploit frameworks may chain such leaks, but there is no reviewed public PoC for this specific CVE at this time.
STEP 04

Exfiltrate the recovered data

Any useful memory recovered must still be serialized and sent back to attacker infrastructure using normal browser networking. This makes the end result data theft from the browser context, not host takeover by itself.
Conditions required:
  • Attacker controls a callback endpoint
  • The browser session can make outbound requests
Where this breaks in practice:
  • DLP, proxy inspection, browser isolation, and egress controls can catch or block obvious exfil paths
  • Without a second vulnerability, blast radius usually stays within the browser/session scope
Detection/coverage: Look for odd outbound requests from browser processes to attacker-controlled domains after suspicious browsing activity. Detection quality is environment-dependent and usually indirect.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed in-the-wild exploitation found in the reviewed sources, and Google did not annotate this issue as exploited. As of 2026-06-06, it is not present in CISA KEV.
PoC availabilityNo public PoC or Metasploit module was located in the reviewed primary references. The Chromium issue is still access-restricted, which usually means repro details are intentionally withheld until patch uptake improves.
EPSSUser-supplied EPSS is 0.00035, which is extremely low in absolute probability terms. FIRST documents EPSS semantics, but the percentile for this CVE was not independently verified in the reviewed sources.
KEV statusNot KEV-listed as of 2026-06-06. That matters because CISA KEV is the strongest public signal that exploitation has crossed from theoretical to operational.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N means remote, low-complexity trigger, no privileges, but user interaction is required and impact is confidentiality-only with no integrity or availability component.
Affected versionsChrome before 149.0.7827.53 is affected on Linux; Windows and macOS builds before 149.0.7827.53/54 are covered by the Chrome stable advisory cadence.
Fixed versionsFixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS per Google's stable release notes. *Inference:* distro-packaged Chromium may ship the fix as a downstream backport on a different package version, so track distro advisories separately.
Scanning / exposure dataShodan/Censys/GreyNoise-style internet exposure is not the right lens here because this is a client-side browser bug, not a listening service with a bannable footprint. Exposure is driven by endpoint version inventory and browsing activity, not open ports.
Disclosure timelineDisclosed on 2026-06-04 in NVD after Google published the Chrome 149 stable update on 2026-06-02.
ReporterReported by Google on 2026-04-11 in the Chrome stable advisory rollup, not by an external researcher receiving a bounty.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.6/10)

The decisive factor is that this bug is a *user-driven confidentiality leak* in a browser component, not an externally reachable service-side compromise or a published code-execution chain. Chrome's ubiquity keeps the issue relevant, but the lack of exploitation evidence and the need for the victim to render attacker-controlled content prevent this from climbing into HIGH.

HIGH No current evidence of KEV listing or public in-the-wild exploitation
MEDIUM Real-world impact staying at information disclosure rather than usable offensive chaining
HIGH Affected/fixed version boundaries from vendor release notes

Why this verdict

  • Start at vendor 6.5: Google already put this in MEDIUM, which is a reasonable baseline for a remote browser info-leak in a massively deployed product.
  • User interaction pulls down: UI:R means the attacker needs a victim to load malicious content; that is materially weaker than drive-by-free server exploitation or zero-click messaging paths.
  • Impact is confidentiality-only: the published vector has C:H/I:N/A:N, so this is not a direct integrity or availability event and not a published RCE or sandbox escape.
  • No exploit pressure signal: no KEV listing, no reviewed public PoC, and a very low user-supplied EPSS materially reduce near-term operational urgency.
  • But exposure is broad: Chrome is everywhere, externally influenced by normal browsing, and the vulnerable component is in a routine rendering path, which keeps this out of LOW.

Why not higher?

To justify HIGH, you would want at least one of these amplifiers: active exploitation, a public reliable PoC, zero-click reachability, or impact that crosses into code execution or sandbox escape. None of those are present in the reviewed record. This is a browser memory disclosure bug with user interaction and no current evidence of operational weaponization.

Why not lower?

LOW would underrate the fact that Chrome is one of the widest client-side attack surfaces in the enterprise and this bug is remotely triggerable through ordinary web content. Even without code execution, a confidentiality leak from browser process memory can expose session material or sensitive page data, so it still deserves normal patch-cycle attention.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure managed Chrome channels cannot lag behind the fixed 149.0.7827.53/54 builds. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still verify update policy and stale endpoints now because version drift is the only clean exposure metric.
  2. Block unmanaged Chrome versions — Use EDR, MDM, or NAC policy to identify endpoints running vulnerable Chrome versions and push them into a corrective workflow. There is no separate mitigation clock here, so use this as hygiene control while completing remediation within the MEDIUM 365-day window.
  3. Prefer browser isolation for risky browsing tiers — Apply remote browser isolation or hardened browsing profiles to high-risk user groups such as finance, executives, and external-content-heavy roles. This does not replace patching, but it lowers exploit reliability and helps until the fleet is uniformly remediated within the 365-day window.
  4. Monitor browser-version exceptions — Build an exception report for hosts pinned to legacy Chrome versions, disabled auto-update, kiosk modes, VDI gold images, or software-distribution failures. Those long-tail systems are where medium browser flaws quietly persist.
What doesn't work
  • A perimeter firewall does not solve this; the trigger arrives through normal user web browsing over allowed outbound paths.
  • Network vuln scanning will not reliably prove exploitability because this is a client-side rendering issue, not a remotely bannered service.
  • MFA is good security hygiene, but it does not stop memory disclosure in the browser process once a victim renders malicious content.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet remote-execution tool. Invoke it with python3 check_cve_2026_11137.py on macOS/Linux or py check_cve_2026_11137.py on Windows; it needs only standard user privileges and will print VULNERABLE, PATCHED, or UNKNOWN based on the locally installed Google Chrome version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11137.py
# Detects whether installed Google Chrome is vulnerable to CVE-2026-11137.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from typing import Optional, Tuple

PATCHED = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        if p.returncode == 0:
            return (p.stdout or p.stderr).strip()
    except Exception:
        pass
    return None


def windows_candidates():
    return [
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]


def mac_candidates():
    return [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]


def linux_candidates():
    return ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']


def get_version() -> Optional[Tuple[int, int, int, int]]:
    system = platform.system().lower()

    if system == 'windows':
        for path in windows_candidates():
            if os.path.exists(path):
                out = run_cmd([path, '--version'])
                if out:
                    v = parse_version(out)
                    if v:
                        return v
        # Fallback to registry query via PowerShell if binary path is nonstandard
        ps = [
            'powershell', '-NoProfile', '-Command',
            r"$paths=@('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($p in $paths){ try { $x=(Get-ItemProperty $p).'(default)'; if($x){ & $x --version; exit 0 } } catch {} }; exit 1"
        ]
        out = run_cmd(ps)
        if out:
            return parse_version(out)

    elif system == 'darwin':
        for path in mac_candidates():
            if os.path.exists(path):
                out = run_cmd([path, '--version'])
                if out:
                    v = parse_version(out)
                    if v:
                        return v

    else:
        for cmd in linux_candidates():
            out = run_cmd([cmd, '--version'])
            if out:
                v = parse_version(out)
                if v:
                    return v

    return None


def main():
    version = get_version()
    if not version:
        print('UNKNOWN: Google Chrome version could not be determined on this host')
        sys.exit(2)

    version_str = '.'.join(str(x) for x in version)
    if version < PATCHED:
        print(f'VULNERABLE: installed Chrome version {version_str} is older than 149.0.7827.53')
        sys.exit(1)
    else:
        print(f'PATCHED: installed Chrome version {version_str} is at or above 149.0.7827.53')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a normal browser-fleet hygiene item, not a fire drill: validate that enterprise Chrome auto-update is working, identify endpoints still below 149.0.7827.53/.54, and clear long-tail exceptions in your standard browser patch cycle. Because this is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; finish the actual Chrome update within the noisgate remediation SLA of 365 days, though in practice most mature fleets should close this far sooner through routine browser servicing.

Sources

  1. NVD CVE-2026-11137
  2. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  3. Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
  4. Chromium issue 501647943
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. Canadian Centre for Cyber Security advisory AV26-544
  8. Chromium severity guidelines
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.