← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11109 · 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 the browser wall, not a kicked-in front door

CVE-2026-11109 is an *uninitialized use* bug in Chrome's ANGLE graphics layer. In practice, a malicious site can drive the browser into a state where memory that should have been safely initialized is not, and the result is *cross-origin data leakage* from a crafted HTML page. The affected range is Chrome versions *before* 149.0.7827.53 on desktop; Google's June 2026 stable release is the fix point.

Google's MEDIUM 6.5 rating is basically fair, and if anything slightly generous for enterprise patch triage. The amplifier is that Chrome is everywhere and browsing untrusted HTML is normal business behavior; the brakes are that this is *not* RCE, *not* a sandbox escape, needs user interaction, and there is no KEV listing or strong exploitation telemetry pushing it into urgent territory.

"Patch it through normal browser hygiene, not as an emergency: broad exposure, but no code exec and no exploitation signal"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker HTML

The attacker delivers a malicious page through phishing, malvertising, compromised ad inventory, or a booby-trapped legitimate site. No authentication is needed, but the victim must browse to the page in a vulnerable Chrome build.
Conditions required:
  • Victim uses Chrome earlier than 149.0.7827.53
  • Victim loads attacker-controlled or attacker-influenced HTML
Where this breaks in practice:
  • Requires user interaction rather than unauthenticated server-side reachability
  • Enterprise DNS/web filtering and safe browsing controls reduce initial land rate
Detection/coverage: Gateway, DNS, and secure web gateway controls can sometimes see the delivery path; vuln scanners only confirm browser version, not exploit delivery.
STEP 02

Exercise ANGLE state handling

The page weaponizes browser graphics behavior via WebGL/ANGLE-adjacent rendering paths. Patch-linked source indicates the fix disables rasterizer discard during robust resource initialization, which strongly suggests the vulnerable condition involved resource clearing being skipped under specific graphics state.
Conditions required:
  • ANGLE-backed rendering path is reachable on the target platform
  • The crafted page can drive the required graphics state transitions
Where this breaks in practice:
  • Browser graphics behavior is hardware/driver/backend sensitive
  • Exploit reliability is likely lower than a straight parser bug because state and backend matter
Detection/coverage: Exploit content is hard to signature reliably; browser crash telemetry, GPU-process anomalies, and render-path debugging may help in lab validation but not broad detection.
STEP 03

Read uninitialized data across origin boundaries

Once the bad state is reached, the attacker can potentially observe data that should not be exposed to the current origin. The impact described by the CVE is confidentiality-only: *cross-origin data leakage*, not code execution or privilege elevation.
Conditions required:
  • Target browser still has useful sensitive data resident in the affected path
  • The exploit can shape returned content into attacker-readable output
Where this breaks in practice:
  • Leaked bytes are often less deterministic than clean logic-bug exfiltration
  • Impact depends on what sensitive material is actually present in memory or buffers at the moment
Detection/coverage: There is no strong network IOC for the memory disclosure itself; browser telemetry and anomaly hunting are more realistic than perimeter signatures.
STEP 04

Exfiltrate session-linked business data

If the leak yields cross-origin content tied to active SaaS sessions, the attacker can exfiltrate it over normal HTTPS from the page itself. That can matter for SSO-heavy enterprises because the browser is the trust boundary for many cloud workflows.
Conditions required:
  • Victim is concurrently authenticated to valuable web apps
  • Leaked material is business-useful rather than random residue
Where this breaks in practice:
  • No integrity or availability impact is claimed
  • The blast radius is usually the single browser profile/session, not whole-host takeover
Detection/coverage: CASB, DLP, and browser telemetry may catch unusual outbound flows or suspicious page behavior, but commodity endpoint tools will not reliably label this as CVE-specific exploitation.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed public in-the-wild exploitation found in the sources reviewed; *not* in CISA KEV.
Proof-of-concept availabilityNo public GitHub PoC or exploit repo found for CVE-2026-11109 in the sources reviewed. The Chromium bug is issue 500524833, but access remains restricted.
EPSS0.00035 from the user-supplied intel block — effectively *very low* predicted near-term exploitation pressure.
KEV statusNo per the user-supplied intel and consistent with the current KEV catalog.
CVSS vector and meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = internet-deliverable via a web page, no privileges, but *user interaction required* and *confidentiality-only* impact.
Affected versionsGoogle/Chrome CNA data shows Chrome desktop versions *before* 149.0.7827.53 are affected.
Fixed versionsUpgrade to Chrome 149.0.7827.53 or later on Linux; Google's release post indicates 149.0.7827.53/.54 for Windows and Mac in the initial rollout.
Disclosure datePublished 2026-06-04 in Chrome/CVE data.
Researcher / reporting partyThe public CVE record attributes the issue to Chrome as CNA; no external researcher credit was visible in the sources reviewed.
Scanning / exposure realityThis is a *client-side browser bug*, so Shodan/Censys-style internet exposure counts are mostly irrelevant. Your exposure is your managed Chrome fleet size, not a count of public services.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (6.0/10)

The decisive limiter is that this is a *user-driven browser information leak*, not a server-side bug or a browser-to-OS takeover. Chrome's ubiquity keeps it above LOW, but the lack of code execution, lack of exploitation evidence, and session-local blast radius keep it out of HIGH.

MEDIUM Severity reassessment versus vendor baseline
HIGH Patch applicability for Chrome versions earlier than `149.0.7827.53`
MEDIUM Practical attack-chain friction due to graphics/backend sensitivity

Why this verdict

  • Downgrade for impact shape: the published impact is *confidentiality only*; there is no stated code execution, sandbox escape, integrity loss, or availability loss.
  • Downward pressure from attacker workflow: the first prerequisite is *user interaction* on a crafted page. That implies phishing, malvertising, or site compromise rather than direct unauthenticated reachability to a service.
  • Downward pressure from exploit reliability: the ANGLE/graphics path and the linked fix suggest backend/state-dependent behavior, which is usually less clean to weaponize than a deterministic parser bug.
  • Not lower because exposure population is huge: Chrome is ubiquitous in enterprise, and visiting arbitrary web content is normal. Even with UI:R, the reachable population is broad once a lure lands.
  • Not higher because external evidence is weak: no KEV listing, no public PoC found, and the supplied EPSS is very low.

Why not higher?

There is no evidence here of host compromise, sandbox escape, or remote code execution. If this were paired with active exploitation evidence, a reliable public PoC, or demonstrated credential/session theft at scale, the score would move up fast.

Why not lower?

A browser-origin leak is still meaningful because the browser is where your workforce lives: email, SSO, HR, finance, ticketing, and admin panels all sit behind it. The fact that a normal web page can trigger the vulnerable path means this is not mere lab trivia.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update and relaunch — Use enterprise policy or your software delivery stack to make sure Chrome actually advances past 149.0.7827.53 and users restart into the new build. For a MEDIUM verdict there is *no mitigation SLA* under noisgate, so this is primarily an operational control to accelerate remediation rather than a separate emergency measure.
  2. Turn on browser version telemetry — Collect browser version data from managed endpoints so you can identify stragglers by OU, business unit, or VDI pool. This matters because client-side browser risk is about fleet coverage, not perimeter exposure.
  3. Reduce exposure to untrusted web content — Use secure web gateway, DNS filtering, and Safe Browsing-aligned controls to cut off initial lure traffic and malicious landing pages. This does not fix the bug, but it lowers the chance the crafted HTML ever executes while the patch rollout completes.
  4. Constrain risky browser features where business-tolerable — For high-risk populations such as admins, finance, and researchers, consider temporary hardening of graphics-heavy or untrusted browsing scenarios if your environment can tolerate it. This is a targeted risk-reduction move, not a substitute for upgrading the browser.
What doesn't work
  • A WAF does not help; there is no vulnerable server endpoint to shield.
  • MFA helps reduce downstream account abuse, but it does not stop a page from leaking already-rendered or session-adjacent browser data.
  • Traditional perimeter scanning will not tell you much; the exposure is endpoint browser version drift, not an internet-facing service banner.
06 · Verification

Crowdsourced verification payload.

Run this on the *target endpoint* or through your endpoint management agent. Invoke it with python3 check_chrome_cve_2026_11109.py on macOS/Linux or py check_chrome_cve_2026_11109.py on Windows; standard user rights are usually enough, though some Windows registry paths may be easier with local read access.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11109.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / could not determine

import os
import platform
import re
import subprocess
import sys

THRESHOLD = (149, 0, 7827, 53)


def parse_version(text):
    if not text:
        return None
    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)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_windows_version():
    candidates = [
        ["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
        ["powershell", "-NoProfile", "-Command", r"(Get-ItemProperty 'HKLM:\Software\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
        ["powershell", "-NoProfile", "-Command", r"(Get-ItemProperty 'HKLM:\Software\WOW6432Node\Google\Chrome\BLBeacon' -ErrorAction SilentlyContinue).version"],
        [r"C:\Program Files\Google\Chrome\Application\chrome.exe", "--version"],
        [r"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe", "--version"],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver, out
    return None, ''


def get_macos_version():
    candidates = [
        ["/Applications/Google Chrome.app/Contents/MacOS/Google Chrome", "--version"],
        ["/Applications/Google Chrome.app/Contents/Info.plist"],
        ["defaults", "read", "/Applications/Google Chrome.app/Contents/Info", "CFBundleShortVersionString"],
        ["mdls", "-name", "kMDItemVersion", "/Applications/Google Chrome.app"],
    ]
    for cmd in candidates:
        if len(cmd) == 1 and cmd[0].endswith('.plist'):
            continue
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver, out
    return None, ''


def get_linux_version():
    candidates = [
        ["google-chrome", "--version"],
        ["google-chrome-stable", "--version"],
        ["chromium-browser", "--version"],
        ["chromium", "--version"],
        ["/opt/google/chrome/chrome", "--version"],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver, out
    return None, ''


def compare_versions(a, b):
    return (a > b) - (a < b)


def main():
    system = platform.system().lower()

    if 'windows' in system:
        ver, source = get_windows_version()
    elif 'darwin' in system:
        ver, source = get_macos_version()
    elif 'linux' in system:
        ver, source = get_linux_version()
    else:
        print('UNKNOWN: unsupported OS {}'.format(platform.system()))
        sys.exit(2)

    if not ver:
        print('UNKNOWN: could not determine installed Chrome/Chromium version')
        sys.exit(2)

    ver_str = '.'.join(str(x) for x in ver)
    if compare_versions(ver, THRESHOLD) < 0:
        print('VULNERABLE: detected version {} which is earlier than {}'.format(ver_str, '.'.join(map(str, THRESHOLD))))
        sys.exit(1)
    else:
        print('PATCHED: detected version {} which is at or later than {}'.format(ver_str, '.'.join(map(str, THRESHOLD))))
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as *fleet hygiene with teeth*, not a fire drill. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for the actual patch, but because this is an evergreen browser used by everyone, you should validate auto-update coverage immediately, identify endpoints still below 149.0.7827.53, and close the gap in your next normal browser wave rather than letting stragglers sit for quarters; your noisgate remediation SLA is <= 365 days, and there is no separate mitigation deadline unless new exploitation evidence appears.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop
  2. Chromium issue tracker - issue 500524833
  3. ANGLE commit linked to bug 500524833
  4. Vulnerability-Lookup search results including CVE-2026-11109
  5. CISA Known Exploited Vulnerabilities Catalog
  6. Chrome Enterprise - Report OS and Google Chrome Version Information
  7. Chrome Enterprise - User Security Signals Reporting
  8. Shodan Internet Exposure Dashboard
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.