← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11073 · CWE-416 · Disclosed 2026-06-04

Use after free in WebGL in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

Like peeking through a mail slot instead of kicking the door in

CVE-2026-11073 is a use-after-free bug in Chrome's WebGL path. On vulnerable desktop builds, a malicious page can trigger stale object reuse inside the renderer-side graphics stack and potentially leak process memory. Affected builds are Chrome versions before 149.0.7827.53 on Linux and before the fixed 149.0.7827.53/54 stable release on Windows/macOS; Windows/macOS Extended Stable also received a backport in 148.0.7778.254.

Google calling this *Medium* matches reality better than the usual panic around browser memory bugs. Yes, Chrome is everywhere and the bug is remotely triggerable through a webpage, but the chain still requires user interaction, the stated impact is confidentiality only, and modern Chrome defenses like sandboxing and Site Isolation materially reduce what a single renderer bug can steal without a second bug.

"Ubiquitous target, but this is still a user-driven renderer info leak, not an internet-reachable RCE fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on a crafted WebGL page

The attacker needs a victim to browse to hostile content that exercises WebGL. In practice this means phishing, malvertising, compromised ad inventory, or a previously trusted site serving attacker-controlled JavaScript. No authentication is required, but the victim has to render the page.
Conditions required:
  • Victim is using Chrome in an affected version range
  • WebGL is available and not blocked by policy
  • Attacker can get the victim to load a hostile page
Where this breaks in practice:
  • Requires user interaction, so this is not wormable and not a blind network spray
  • Many enterprises already reduce risky browsing with URL filtering, Safe Browsing, or browser isolation
  • High-value admins may browse from separate hardened workstations
Detection/coverage: Traditional vuln scanners only catch this by version inventory. Web proxy, secure web gateway, and browser telemetry may show the lure domain, but not the exploit itself.
STEP 02

Trigger the WebGL use-after-free in the renderer

A malicious script drives a vulnerable WebGL code path until an object is freed and then referenced again. The exploit primitive here is memory misuse in the browser process handling untrusted web content, not a server-side listener that can be probed from the internet.
Conditions required:
  • Exploit path matches the victim's platform/build
  • Browser reaches the specific vulnerable WebGL state
  • Mitigations do not make the bug non-reproducible
Where this breaks in practice:
  • Use-after-free exploitation is often brittle across builds, GPUs, drivers, and timing
  • Google's bug details are still restricted, which usually means no turnkey exploit recipe is public yet
  • Renderer crashes are more common than clean data exfiltration for immature browser exploits
Detection/coverage: Crash telemetry, browser hang reports, and EDR child events can catch failed attempts; network IDS is weak here because the payload is just web content over HTTPS.
STEP 03

Read process memory for useful secrets

If the attacker gets a stable read primitive, the likely outcome is disclosure of renderer-accessible memory: page contents, tokens, or other sensitive data resident in that process. The published impact is confidentiality, not integrity or availability, which is a major downgrade from a browser RCE.
Conditions required:
  • Exploit achieves memory disclosure rather than just a crash
  • Target data is resident in the compromised process
  • Attacker can return or exfiltrate the leaked bytes
Where this breaks in practice:
  • Site Isolation reduces cross-site data co-residency in many cases
  • Chrome sandboxing and process boundaries constrain blast radius
  • Secrets of real value may live outside the compromised renderer process
Detection/coverage: Difficult to detect directly. Focus on anomalous browser crashes, suspicious destination domains, and session/token misuse after suspicious browsing activity.
STEP 04

Monetize the leak or chain it with a second bug

On its own, this bug is best thought of as a foothold for information theft or as one half of a larger chain. Attackers would need separately useful disclosed data or another vulnerability to turn this into full system compromise.
Conditions required:
  • Leaked data has operational value
  • Attacker can reuse tokens/cookies or pair this bug with another exploit
Where this breaks in practice:
  • No public evidence of active exploitation or a public chain as of June 5, 2026
  • Session protections, re-auth prompts, and short-lived tokens reduce payoff
  • Without a second bug, this stops well short of endpoint takeover
Detection/coverage: Downstream detection is better than exploit detection: impossible travel, token reuse anomalies, and account/session analytics can expose abuse of stolen web artifacts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation located in public sources reviewed as of 2026-06-05. The CVE is not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC found in the reviewed sources. The vendor bug reference exists as Chromium issue 499365904, but details remain restricted, which usually slows opportunistic copycat use.
EPSS0.00032 from the user-supplied intel. That is extremely low; a verified percentile was not available from the primary sources reviewed.
KEV statusNot KEV-listed. No CISA due date applies because the CVE is absent from the catalog.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — translation: remotely delivered through web content, but still needs a user to browse and is rated for confidentiality impact only.
Affected versionsChrome before 149.0.7827.53 per the CVE description. Google's desktop rollout states fixed builds are 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS.
Fixed versions / backportsPrimary fix: Chrome 149 stable. Backport for slower channels: Windows/macOS Extended Stable 148.0.7778.254.
Scanning / exposure realityThis is a client-side browser bug, so edge-exposure telemetry is weak by design. GreyNoise and Censys are useful for internet-facing services, but they do not meaningfully enumerate endpoint browser build exposure for a WebGL renderer bug like this.
Disclosure timelineThere are two dates defenders should track: Google published the fixed stable desktop build on 2026-06-02, while downstream CVE metadata for this ID appears on 2026-06-04.
ReporterListed as reported by Google on 2026-04-03 in the Chrome stable-channel advisory.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.8/10)

The decisive factor is that this bug sits behind user-driven web navigation and yields information disclosure, not code execution. Chrome's process isolation also narrows what one renderer bug can reach, so the real-world blast radius is materially smaller than the ubiquity of the browser might suggest.

HIGH Affected-version and fixed-version ranges
MEDIUM Real-world exploitability without a public PoC or active-exploitation evidence
MEDIUM Impact staying limited to confidentiality in enterprise deployments

Why this verdict

  • UI:R cuts the vendor 6.5 down immediately — the attacker needs a victim to render hostile content, which implies phishing, malvertising, or a compromised site rather than direct unauthenticated reachability.
  • Confidentiality-only impact is a real ceiling — the published impact is memory disclosure, not arbitrary code execution, sandbox escape, or persistence on the host.
  • Chrome's isolation model adds practical friction — Site Isolation and sandboxing reduce cross-site/process loot and make single-bug chains less rewarding than the raw CWE-416 label suggests.

Why not higher?

This is not an unauthenticated edge service and not a one-shot system compromise. There is no KEV listing, no public exploitation evidence in the reviewed sources, and no public PoC lowering the skill barrier for broad abuse.

Why not lower?

Chrome is everywhere, and drive-by delivery via a webpage is still a very real attack vector. Memory disclosure in a browser can expose session material or page data, and these bugs are frequently valuable as chain components even when the standalone CVSS looks modest.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update compliance — Use Chrome Enterprise policy, MDM, or your software deployment stack to verify that endpoints are actually receiving stable or Extended Stable updates. Because this verdict is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but for a browser you should treat version drift as an operational defect and close it in your next normal browser wave, not at day 364.
  2. Disable WebGL on tightly controlled high-risk tiers — For privileged admin workstations, kiosks, or VDI pools where WebGL is not business-critical, temporarily disable it with policy to shrink exposure while stragglers are updated. On a MEDIUM finding there is no mitigation SLA — go straight to the 365-day remediation window; use this only where the business impact is low and the population is easy to target.
  3. Separate privileged browsing — Keep administrator sessions, cloud consoles, and identity-provider admin work in dedicated browser profiles or hardened workstations so a renderer-only data leak has less valuable material to steal. With a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control pays off across the whole browser bug class.
  4. Monitor for browser crash clusters — Aggregate Chrome crash telemetry and EDR/browser logs to spot sudden spikes tied to specific URLs, referrers, or ad networks. There is no mitigation SLA — go straight to the 365-day remediation window for this finding, but early detection helps you catch opportunistic exploitation attempts before they become a broader incident.
What doesn't work
  • Perimeter WAF/IPS tuning doesn't solve this because the exploit lands as normal client web content over the victim's browser session, often inside HTTPS.
  • External attack-surface scanning is mostly useless here because this is not an internet-facing server versioning problem; you need endpoint/browser inventory, not Censys or Shodan counts.
  • MFA alone does not stop token or session-material theft if the bug can leak renderer-resident secrets after login.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR remote shell, not from an auditor workstation. Invoke it with python3 check_chrome_cve_2026_11073.py on Linux/macOS or py check_chrome_cve_2026_11073.py on Windows; standard user rights are usually enough, though some locked-down Windows hosts may require permission to read registry keys under HKLM.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11073.py
# Defensive version check for CVE-2026-11073 (Chrome WebGL UAF)
# 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 typing import List, Optional, Tuple

Version = Tuple[int, int, int, int]


def parse_version(text: str) -> Optional[Version]:
    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: List[str]) -> str:
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        return (p.stdout or '') + (p.stderr or '')
    except Exception:
        return ''


def version_ge(a: Version, b: Version) -> bool:
    return a >= b


def is_patched(ver: Version, system_name: str) -> bool:
    # Stable fixed baseline for all desktop platforms
    stable_fix = (149, 0, 7827, 53)
    # Windows/macOS Extended Stable backport noted by Google
    ext_fix = (148, 0, 7778, 254)

    if system_name in ('Windows', 'Darwin'):
        if ver[0] == 148 and ver[1] == 0 and ver[2] == 7778:
            return version_ge(ver, ext_fix)
        return version_ge(ver, stable_fix)
    else:
        # Linux advisory lists stable fix only
        return version_ge(ver, stable_fix)


def detect_linux() -> List[Tuple[str, Version]]:
    found = []
    candidates = ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']
    for c in candidates:
        path = shutil.which(c)
        if not path:
            continue
        out = run_cmd([path, '--version'])
        ver = parse_version(out)
        if ver:
            found.append((path, ver))
    return found


def detect_macos() -> List[Tuple[str, Version]]:
    found = []
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        '/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary'
    ]
    for path in candidates:
        if not os.path.exists(path):
            continue
        out = run_cmd([path, '--version'])
        ver = parse_version(out)
        if ver:
            found.append((path, ver))
    return found


def detect_windows() -> List[Tuple[str, Version]]:
    found = []

    # Common executable paths
    envs = [
        os.environ.get('ProgramFiles'),
        os.environ.get('ProgramFiles(x86)'),
        os.environ.get('LocalAppData')
    ]
    suffixes = [
        r'Google\Chrome\Application\chrome.exe',
        r'Chromium\Application\chrome.exe'
    ]
    for base in envs:
        if not base:
            continue
        for suf in suffixes:
            path = os.path.join(base, *suf.split('\\'))
            if os.path.exists(path):
                out = run_cmd([path, '--version'])
                ver = parse_version(out)
                if ver:
                    found.append((path, ver))

    # Registry fallback: BLBeacon version key
    reg_keys = [
        r'HKLM\SOFTWARE\Google\Chrome\BLBeacon',
        r'HKLM\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
        r'HKCU\Software\Google\Chrome\BLBeacon'
    ]
    for key in reg_keys:
        out = run_cmd(['reg', 'query', key, '/v', 'version'])
        ver = parse_version(out)
        if ver:
            found.append((key, ver))

    # Deduplicate
    uniq = {}
    for src, ver in found:
        uniq[src] = ver
    return list(uniq.items())


def main() -> int:
    system_name = platform.system()
    detections: List[Tuple[str, Version]] = []

    if system_name == 'Linux':
        detections = detect_linux()
    elif system_name == 'Darwin':
        detections = detect_macos()
    elif system_name == 'Windows':
        detections = detect_windows()
    else:
        print(f'UNKNOWN: unsupported platform {system_name}')
        return 2

    if not detections:
        print('UNKNOWN: Chrome/Chromium version not found')
        return 2

    vulnerable = []
    patched = []
    for src, ver in detections:
        if is_patched(ver, system_name):
            patched.append((src, ver))
        else:
            vulnerable.append((src, ver))

    print('Detected versions:')
    for src, ver in detections:
        print(f'  {src}: {".".join(map(str, ver))}')

    if vulnerable:
        print('VULNERABLE')
        return 1

    if patched:
        print('PATCHED')
        return 0

    print('UNKNOWN')
    return 2


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

If you remember one thing.

TL;DR
Monday morning, pull a fleet-wide Chrome version report and identify endpoints still below the fixed builds: 149.0.7827.53 on Linux, 149.0.7827.53/54 on Windows/macOS, or 148.0.7778.254 for Windows/macOS Extended Stable. Because this lands MEDIUM and there is no KEV or public exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, roll it into your next normal browser maintenance wave and clean up stragglers well before the noisgate remediation SLA of ≤365 days.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (2026-06-02)
  2. Google Chrome Releases - Extended Stable Updates for Desktop (2026-06-03)
  3. Chromium issue 499365904
  4. Chromium Security - Site Isolation
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS
  7. GreyNoise Event Feeds documentation
  8. Censys Search
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.