← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11138 · 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 peep hole in the browser glass, not a door kicked off its hinges

CVE-2026-11138 is an *uninitialized-use* bug in ANGLE, Chrome's graphics translation layer used by WebGL/GPU rendering. In Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows/macOS, a malicious site can drive the vulnerable rendering path with crafted HTML and leak cross-origin data that should stay isolated by the browser.

Google's MEDIUM / 6.5 baseline is basically fair. The upside for attackers is broad deployment and zero-auth reach through the web; the downside is heavy real-world friction: user interaction is required, the exploit path depends on ANGLE/GPU behavior, impact is confidentiality-only, and there is no public exploitation or KEV signal. That keeps this in the patch-it bucket, not the drop-everything bucket.

"Real browser bug, but it needs a user visit, a working ANGLE path, and gives data leak—not code exec or a foothold."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled HTML

The attacker needs the user to load a malicious page in a vulnerable Chrome build. This is classic browser-bug delivery: phishing, malvertising, compromised sites, or an embedded link in chat/email are enough because the browser itself is the target surface.
Conditions required:
  • Victim runs Chrome older than 149.0.7827.53
  • Victim browses to attacker-controlled content
  • Normal web access is allowed
Where this breaks in practice:
  • Requires UI:R; there is no drive-by network service to hit directly
  • Enterprise email/web filtering can cut initial reach
  • Chrome auto-update shrinks dwell time on managed fleets
Detection/coverage: Secure web gateways, browser isolation, and URL detonation products may catch the delivery page, but vuln scanners only see version state; they do not validate exploitability.
STEP 02

Exercise the ANGLE rendering path

The crafted page must push Chrome into the affected ANGLE code path, likely through GPU-accelerated rendering or WebGL-adjacent operations. This is where the bug stops being a generic web flaw and becomes a rendering-stack issue tied to browser build, platform, driver behavior, and feature state.
Conditions required:
  • ANGLE is in use on the endpoint
  • Relevant GPU/rendering features are enabled
  • The page successfully triggers the vulnerable code path
Where this breaks in practice:
  • GPU disablement, software rendering fallback, or policy restrictions on WebGL can break the chain
  • Platform variance makes browser graphics bugs brittle across a mixed fleet
  • Exploit reliability is lower than a pure DOM or JavaScript logic bug
Detection/coverage: EDR rarely sees this as a clean signature unless the exploit crashes the renderer/GPU process; browser telemetry and crash reporting are more useful than network IDS here.
STEP 03

Leak cross-origin data past browser isolation

If the uninitialized-use is triggered cleanly, the attacker can recover data associated with another origin that should be segregated by Chrome's same-origin protections. In practical terms, that means exposure of authenticated web content or sensitive page state, not arbitrary OS-level code execution.
Conditions required:
  • Victim has interesting data in browser context worth stealing
  • The bug yields readable data rather than just a crash
  • Browser isolation defenses are bypassed by the flaw as described
Where this breaks in practice:
  • Impact is confidentiality-only; no integrity or availability win is described
  • Leak usefulness depends on what the victim has open or accessible in-session
  • Site Isolation and related browser hardening reduce generic cross-origin abuse, so the bug must be exploited precisely
Detection/coverage: Version-based scanners can flag exposure. Detection of actual data exfil from the browser is weak unless supported by proxy logs, DLP, or browser telemetry.
STEP 04

Exfiltrate data over normal web traffic

Once the malicious page obtains data, it can send it back using standard HTTPS requests under normal browser behavior. That makes post-exploit traffic look like ordinary web egress unless you have destination filtering or browser-aware DLP controls.
Conditions required:
  • The page can make outbound web requests
  • Exfiltrated data is small enough to move through ordinary HTTP(S)
Where this breaks in practice:
  • Proxy inspection, CASB, DLP, and browser isolation can reduce or observe exfiltration
  • The attacker still walks away with stolen web data, not durable endpoint control
Detection/coverage: Network controls may see odd callback domains, but there is no unique wire signature for this CVE.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the sources reviewed; CISA ADP enrichment marks exploitation as none.
KEV statusNot listed in the CISA KEV catalog as reviewed.
PoC availabilityNo public PoC located in the sources reviewed. The Chromium issue exists, but bug details may remain restricted until patch uptake improves.
EPSS0.00035 (~0.035% probability in 30 days, per user-supplied intel); that is *very low* and matches the lack of exploitation chatter.
CVSS and what it meansCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remote via the web, no auth required, but user interaction is mandatory and impact is data exposure only.
Affected versionsGoogle Chrome prior to 149.0.7827.53; Google release notes show desktop fixes landing as 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS.
Fixed versionsPatch floor: 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/macOS). *Downstream Chromium distro backports were not enumerated in the primary sources reviewed.*
Exposure / scan signalNot meaningfully internet-scannable. This is a client-side browser bug, so Shodan/Censys/FOFA/GreyNoise-style exposure counts are low-value for prioritization; fleet inventory and browser version telemetry matter more.
Disclosure timelineReserved 2026-06-04, published 2026-06-04, updated 2026-06-06 in the official CVE record; Chrome stable desktop release posted 2026-06-02.
Reporter / sourceChrome's public release notes list Google as the reporter for the underlying issue 501650354, reported on 2026-04-11.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.4/10)

The decisive limiter is attack-path friction: the bug is reachable only after a victim loads attacker HTML and the exploit successfully hits a specific ANGLE/GPU rendering path. That is materially different from a remotely reachable server flaw or a browser RCE, so a medium-severity prioritization is the right operational call.

HIGH Affected version floor and vendor metadata
MEDIUM Operational exploitability assessment without public technical root-cause details

Why this verdict

  • Baseline holds: Google's 6.5 / MEDIUM score already reflects the biggest truth here—remote web delivery with confidentiality impact, but not code execution.
  • UI:R is real friction: the attacker needs a victim to browse attacker content. That implies phishing, malvertising, or site compromise, and modern email/web controls should stop a chunk of attempts before the bug matters.
  • ANGLE path narrows reach: this is not a generic DOM bug. It depends on the vulnerable rendering stack being exercised, which is downward pressure in mixed enterprise fleets with different OS, driver, and browser feature states.
  • Blast radius is session-bound: the attacker steals browser-visible data, not endpoint control. The impact can be serious for a logged-in SaaS user, but it does not inherently hand over persistence or lateral movement.
  • Threat intel is quiet: no KEV listing, no public exploitation evidence, and no public PoC found. EPSS is extremely low, which argues against inflating this above medium.

Why not higher?

There is no evidence of active exploitation, no known public exploit, and no indication of code execution or sandbox escape. The chain also requires user interaction and a browser-graphics path that is inherently less universal and less reliable than a straight web logic flaw.

Why not lower?

This still crosses an important line: a malicious website may leak cross-origin data from one of the most widely deployed enterprise applications on the planet—the browser. If exploited against users logged into sensitive SaaS apps, the business impact can be real even without malware or local code execution.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Use your enterprise browser management stack to enforce Chrome version convergence and identify laggards. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but in practice Chrome is low-friction to update, so you should let the normal managed update channel clear this quickly.
  2. Apply browser isolation for high-risk users — Put executives, finance, admins, and help desk staff behind remote browser isolation or equivalent controls where you already have it. There is no mitigation SLA for a medium verdict, so treat this as a targeted risk reduction measure rather than a fleet-wide emergency control.
  3. Restrict WebGL or hardware acceleration where business-tolerable — If you operate kiosk, VDI, or tightly managed admin workstations that do not need rich graphics, consider policy-based reduction of GPU/WebGL exposure to add friction against ANGLE bugs. For this MEDIUM verdict, use it selectively while remediating inside the 365-day window.
  4. Harden web delivery paths — Tighten URL filtering, ad blocking, sandbox detonation, and email link rewriting to reduce the chance users ever hit hostile HTML. This matters because the most reliable control is stopping step one of the chain.
What doesn't work
  • Traditional perimeter vulnerability scanning doesn't help much; this is a client-side browser flaw, not an internet-facing service.
  • MFA does not stop exploitation of the browser bug itself; it may limit downstream account abuse, but it does not prevent cross-origin leakage from a live browser session.
  • Network segmentation is mostly irrelevant; the attacker comes through normal user web browsing, not east-west reachability.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software inventory tooling on a representative host. Invoke it with python3 check_chrome_cve_2026_11138.py or python check_chrome_cve_2026_11138.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; it needs only normal user privileges and outputs VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11138.py
# Detects whether local Google Chrome is below the fixed version for CVE-2026-11138.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED = (149, 0, 7827, 53)

COMMON_PATHS = {
    'Windows': [
        r'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
        os.path.expandvars(r'%LOCALAPPDATA%\\Google\\Chrome\\Application\\chrome.exe'),
    ],
    'Darwin': [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ],
    'Linux': [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/opt/google/chrome/google-chrome',
    ],
}


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


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


def get_version_from_binary(path):
    try:
        out = subprocess.check_output([path, '--version'], stderr=subprocess.STDOUT, timeout=10)
        txt = out.decode(errors='ignore').strip()
        return parse_version(txt), txt
    except Exception:
        return None, ''


def candidate_paths(user_path=None):
    seen = set()
    if user_path:
        yield user_path
        seen.add(user_path)

    chrome_in_path = shutil.which('google-chrome') or shutil.which('google-chrome-stable') or shutil.which('chrome')
    if chrome_in_path and chrome_in_path not in seen:
        yield chrome_in_path
        seen.add(chrome_in_path)

    sysname = platform.system()
    for p in COMMON_PATHS.get(sysname, []):
        if p and p not in seen:
            yield p
            seen.add(p)


def main():
    user_path = None
    if len(sys.argv) >= 3 and sys.argv[1] == '--path':
        user_path = sys.argv[2]
    elif len(sys.argv) == 2 and sys.argv[1] not in ('-h', '--help'):
        user_path = sys.argv[1]
    elif len(sys.argv) >= 2 and sys.argv[1] in ('-h', '--help'):
        print('Usage: python check_chrome_cve_2026_11138.py [--path /path/to/chrome]')
        sys.exit(2)

    tested = []
    for path in candidate_paths(user_path):
        if not os.path.exists(path):
            continue
        ver, raw = get_version_from_binary(path)
        tested.append(path)
        if ver is None:
            continue
        if ver < FIXED:
            print(f'VULNERABLE: Chrome {version_to_str(ver)} at {path} is below fixed version {version_to_str(FIXED)} for CVE-2026-11138')
            sys.exit(1)
        else:
            print(f'PATCHED: Chrome {version_to_str(ver)} at {path} meets or exceeds fixed version {version_to_str(FIXED)} for CVE-2026-11138')
            sys.exit(0)

    tested_msg = ', '.join(tested) if tested else 'no candidate binaries found'
    print(f'UNKNOWN: Unable to determine Chrome version ({tested_msg})')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: confirm your Chrome fleet is converging to 149.0.7827.53+ (Linux) or 149.0.7827.53/.54+ (Windows/macOS), and use browser version telemetry to isolate laggards. For a MEDIUM noisgate verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but because this is a browser bug with broad endpoint presence, let managed auto-update clear it in the current maintenance cycle and make sure all exceptions are remediated within the noisgate remediation SLA of 365 days.

Sources

  1. Chrome stable desktop release 149
  2. Chrome early stable desktop release 149.0.7827.53/.54
  3. Official CVE JSON record (cvelistV5)
  4. Chromium issue 501650354
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS data and stats
  7. Chrome Security Page
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.