← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11090 · 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 leaky window in a moving car, not a smashed front door

CVE-2026-11090 is an *uninitialized use* bug in Chrome's ANGLE graphics layer, the component that translates browser graphics calls to platform GPU APIs. The affected range is Google Chrome versions *before* 149.0.7827.53; Google's June 2, 2026 stable release shipped 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. The stated impact is cross-origin data leakage from a crafted HTML page, not code execution.

Google's *Medium / 6.5* label is broadly fair, but a little generous for enterprise patch triage. The exploit chain needs a user to render attacker-controlled content in a vulnerable Chrome build, then successfully exercise the ANGLE path to leak useful data; that is meaningful for targeted theft, but it is not wormable, not a server-side foothold, and there is no current KEV listing, public exploit evidence, or scary EPSS signal pushing this into urgent territory.

"Real bug, real browser reach, but no exploit evidence and too much user-side friction for panic patching."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker content

The attacker needs a user to visit a malicious page, malvertisement, or embedded hostile frame. The practical weapon here is just a crafted HTML page that drives browser rendering behavior; no credentials or local code execution are required at this stage.
Conditions required:
  • Target uses Google Chrome below 149.0.7827.53
  • User browses to attacker-controlled or attacker-influenced content
  • Enterprise controls do not block the lure or destination
Where this breaks in practice:
  • This is *UI:R* by definition; no click, no bug
  • Modern email/web filtering cuts down mass delivery
  • Attackers still need a believable lure or compromised trusted site
Detection/coverage: Web proxies, DNS logs, and secure web gateways can often see the delivery event, but they will not identify this CVE specifically.
STEP 02

Exercise the vulnerable ANGLE path

The crafted page must drive graphics execution through ANGLE, Chrome's translation layer for WebGL and related rendering paths. In effect, the attacker is trying to coerce the browser into touching uninitialized state during GPU-adjacent rendering operations.
Conditions required:
  • ANGLE is in use on the target platform
  • The vulnerable code path is reachable from the rendered content
  • The host GPU/driver/browser combination behaves as expected for the bug
Where this breaks in practice:
  • Client-side graphics bugs are notoriously environment-sensitive
  • Hardware acceleration settings, backend choice, and driver variation can break reliability
  • Some enterprise VDI/kiosk builds materially differ from consumer desktops
Detection/coverage: Traditional vuln scanners have poor coverage here; browser version inventory is good, exploit-attempt telemetry is weak unless you capture renderer crash/GPU error signals.
STEP 03

Leak cross-origin or process data

If the vulnerable path is hit successfully, the attacker can read data that should not be exposed to the malicious origin. The described impact is confidentiality loss: cross-origin data leakage or exposure of sensitive process memory, not integrity takeover or code execution.
Conditions required:
  • Useful victim data is present in browser memory or reachable rendering state
  • Same-origin protections are bypassed by the bug's memory disclosure behavior
  • The leaked bytes are stable enough to be parsed into something valuable
Where this breaks in practice:
  • Memory disclosure does not guarantee clean, high-value data every run
  • Many leaks are noisy and require repeated attempts or careful grooming
  • Blast radius is usually bounded to the browser session, not the whole host
Detection/coverage: There is little signature-based coverage; browser crash telemetry, anomalous page behavior, and suspicious outbound follow-on traffic are the realistic hunting angles.
STEP 04

Monetize the theft

The attacker exfiltrates any recovered tokens, page content, or sensitive fragments to their collection endpoint. In a real campaign, the operational value is targeted account/session theft or intelligence gathering, not immediate host takeover.
Conditions required:
  • The leak yields something actionable
  • Outbound network egress from the browser is allowed
  • The victim is authenticated to something worth stealing
Where this breaks in practice:
  • Many enterprises rely on SSO, device binding, and conditional access that reduce token reuse value
  • Useful data may be sparse unless the user is already logged into sensitive apps
  • Exfil traffic can still stand out in proxy logs for targeted users
Detection/coverage: Proxy/SWG logs, CASB, and identity telemetry are more useful here than endpoint exploit signatures.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found, and not listed in CISA KEV as of 2026-06-06.
Public PoCNo public proof-of-concept located. The Chromium issue exists at issues.chromium.org, but details are still effectively gated/restricted.
EPSSUser-supplied EPSS = 0.00035. That is a very low predicted exploitation probability; the percentile was not independently verified from FIRST during this assessment.
KEV statusNot KEV-listed. For prioritization, that removes the strongest urgency amplifier.
CVSS meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N means remote delivery with user interaction required, confidentiality impact only, and no direct integrity or availability loss.
Affected versionsGoogle Chrome before 149.0.7827.53. Google's June 2, 2026 stable announcement shipped 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS.
Fixed versionsPatch level is 149.0.7827.53 or later; Windows/macOS may report 149.0.7827.54 from the same stable rollout.
Exposure realityInternet-wide scanner data like Shodan/Censys/FOFA is not applicable because this is a client-side browser bug, not a listening service. The population is still huge because Chrome held about 71.56% desktop browser share worldwide in StatCounter's April 2026 dataset.
Disclosure timelineChrome 149 stable shipped on 2026-06-02; the CVE record was disclosed on 2026-06-04. The Chrome release notes show the underlying bug was reported by Google on 2026-04-07.
Reporter / issueThe Chrome release notes attribute this bug to Google and map it to Chromium issue 500161302.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.4/10)

The decisive factor is compounding attacker friction: this is a client-side, user-driven data leak that must survive browser, GPU, and rendering-path variability before it returns anything useful. Chrome's ubiquity keeps it relevant, but the absence of KEV, public exploitation, or an integrity/availability impact keeps it out of the emergency lane.

HIGH Assessment that this is **not** an urgent, emergency patch item
MEDIUM Assessment of practical exploit reliability across mixed GPU/driver fleets

Why this verdict

  • User interaction drags the score down: the attacker needs a victim to render hostile web content, which implies phishing, malvertising, or a compromised trusted site rather than straight unauthenticated remote reach.
  • This is client-side and non-scannable: there is no exposed service to sweep at internet scale, so population reach depends on successful content delivery and user browsing behavior, not raw network exposure.
  • ANGLE/GPU path variability adds real friction: browser graphics bugs often depend on backend, driver, acceleration, and platform specifics, which hurts reliability in real enterprise fleets.
  • No exploit pressure today: no KEV, no public in-the-wild reporting, no public PoC found, and the supplied EPSS is extremely low.
  • Why it does not fall further: Chrome is everywhere, and a cross-origin data leak in a browser can still matter for SSO-heavy environments where users hold valuable live sessions.

Why not higher?

This is not code execution, not sandbox escape, and not a server-side exposure you can hit blindly from the internet. The chain requires user interaction and then a somewhat finicky client-side rendering condition to turn a bug into useful data theft, which is a meaningful downgrade from the vendor baseline.

Why not lower?

Cross-origin leakage inside the dominant enterprise browser is still a legitimate security issue, especially for high-value users with active SaaS sessions. Even without RCE, confidentiality loss in a browser can translate into real business impact if an attacker can steal tokens, page contents, or sensitive application data.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure managed endpoints are actually receiving and applying Chrome stable updates, then verify they move to 149.0.7827.53+. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browsers should not sit that long in lagging channels.
  2. Harden risky user cohorts — For admins, finance, executives, and researchers, apply stricter web isolation or remote browser isolation where available. This reduces the chance that a malicious page can exercise the vulnerable client path while you complete remediation within the 365-day window.
  3. Restrict untrusted browsing paths — Use secure web gateway policy to reduce exposure to newly registered domains, ad-tech noise, and uncategorized destinations. This does not fix the bug, but it reduces the odds of step 1 in the chain while you remediate.
  4. Watch browser laggards — Inventory endpoints still below 149.0.7827.53 and tie them to owners, channels, and update failures. The real operational risk here is not exploit hype; it is unmanaged browser drift across thousands of hosts.
What doesn't work
  • A WAF does not help because the vulnerable component is the client's browser, not your server-side app stack.
  • Perimeter port scanning does not help because there is no listening network service to enumerate for this CVE.
  • Generic network segmentation does not neutralize a user browsing to hostile content on the open internet.
  • Relying on AV signatures alone is weak here; there may be no dropped file or stable exploit artifact to match.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet management agent. Invoke it as python3 check_chrome_cve_2026_11090.py on Linux/macOS or py check_chrome_cve_2026_11090.py on Windows; no administrator rights are normally required because it only reads local executable paths and queries the browser version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check local Google Chrome version for CVE-2026-11090 exposure
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

PATCHED_MIN = (149, 0, 7827, 53)


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_candidates():
    system = platform.system().lower()
    candidates = []

    if system == 'windows':
        env = os.environ
        for base in [env.get('PROGRAMFILES'), env.get('PROGRAMFILES(X86)'), env.get('LOCALAPPDATA')]:
            if not base:
                continue
            candidates.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
        where = shutil.which('chrome') or shutil.which('chrome.exe')
        if where:
            candidates.append(where)

    elif system == 'darwin':
        candidates.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ])
        where = shutil.which('google-chrome') or shutil.which('chrome')
        if where:
            candidates.append(where)

    else:
        candidates.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/snap/bin/chromium',
        ])
        for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
            where = shutil.which(name)
            if where:
                candidates.append(where)

    # Deduplicate while preserving order
    seen = set()
    deduped = []
    for c in candidates:
        if c and c not in seen:
            deduped.append(c)
            seen.add(c)
    return deduped


def get_version(binary):
    try:
        result = subprocess.run([binary, '--version'], capture_output=True, text=True, timeout=10)
        output = (result.stdout or '') + ' ' + (result.stderr or '')
        return parse_version(output)
    except Exception:
        return None


def main():
    candidates = get_candidates()
    found = []

    for c in candidates:
        if os.path.exists(c) or shutil.which(c):
            v = get_version(c)
            if v:
                found.append((c, v))

    if not found:
        print('UNKNOWN - Google Chrome executable not found or version unreadable')
        sys.exit(2)

    # Use the highest discovered version in case multiple channels are installed
    best_path, best_version = sorted(found, key=lambda x: x[1], reverse=True)[0]

    if best_version >= PATCHED_MIN:
        print(f'PATCHED - {best_path} version {version_to_str(best_version)} >= {version_to_str(PATCHED_MIN)}')
        sys.exit(0)
    else:
        print(f'VULNERABLE - {best_path} version {version_to_str(best_version)} < {version_to_str(PATCHED_MIN)}')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning: treat this as standard browser patching, not incident-mode patching. Identify Chrome endpoints still below 149.0.7827.53, validate auto-update health, and push laggards through your normal endpoint update process; for a MEDIUM verdict there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window, and noisgate remediation SLA: patch within 365 days. If you have high-risk user groups, tighten browsing controls and isolation sooner, but this CVE does not justify emergency change windows absent new exploitation evidence.

Sources

  1. Google Chrome stable channel update for desktop (Chrome 149)
  2. Chromium issue 500161302
  3. Chromium Security overview
  4. ANGLE project documentation
  5. CISA Known Exploited Vulnerabilities catalog
  6. FIRST EPSS API documentation
  7. FIRST EPSS data and report documentation
  8. StatCounter desktop browser market share
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.