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

Use after free in ANGLE in Google Chrome prior to 149

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

This is a lockpick for the second door, not a front-door battering ram

CVE-2026-11065 is a use-after-free bug in Chrome's ANGLE graphics layer, fixed in Chrome 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. The supplied CVE text says the bug only matters after an attacker has already compromised the renderer process, which makes this a *sandbox-escape stage* in a browser exploit chain rather than a standalone initial-access bug.

The vendor-style 9.6/CRITICAL label does not match field reality. Google's own June 2, 2026 stable release post classifies CVE-2026-11065 as Medium, and that is the right anchor: the decisive friction is the prerequisite of a separate renderer exploit first, which sharply narrows reachable attackers, affected sessions, and practical exploit volume despite the scary worst-case impact once chained.

"This is a chained browser exploit stage, not a one-click internet-to-host break; the renderer-compromise prerequisite crushes urgency."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Gain renderer execution with a separate bug

The attacker first needs code execution or equivalent memory corruption inside Chrome's renderer process by exploiting some other bug such as V8, Blink, WebRTC, or a similar content-handling flaw. CVE-2026-11065 does not provide that entry point by itself; it only becomes useful after the renderer is already under attacker control.
Conditions required:
  • Victim visits attacker-controlled content or otherwise processes hostile web content
  • A separate renderer-compromise primitive exists and succeeds first
Where this breaks in practice:
  • This is already one successful exploit stage before CVE-2026-11065 even enters the picture
  • Modern browser mitigations, site isolation, and crash telemetry kill many chains before they become reliable
Detection/coverage: Standalone vuln scanners will not prove this stage. Detection is mostly via browser crash telemetry, exploit-prevention alerts, and hunting for abnormal Chrome renderer instability.
STEP 02

Drive ANGLE into the vulnerable lifetime bug

With renderer control, the attacker steers crafted graphics operations through ANGLE to hit the use-after-free condition. In practical terms, this is the exploit-development step that converts an existing renderer foothold into a possible sandbox-escape primitive.
Conditions required:
  • ANGLE code path reachable on the target build
  • Exploit can shape heap state reliably enough to reuse freed memory
Where this breaks in practice:
  • Graphics-path bugs are often crash-prone and hardware/driver dependent
  • GPU blacklisting, disabled acceleration, or differing platform behavior can break reliability across fleets
Detection/coverage: EDR and endpoint telemetry may catch repeated Chrome/GPU-process crashes, access violations in libGLESv2/ANGLE modules, or exploit-guard events; traditional network IDS has poor visibility.
STEP 03

Cross the sandbox boundary

If exploitation is stable, the attacker attempts to pivot from compromised renderer context into a broader browser or host context, which is the meaningful impact here. This is why downstream metadata calls it severe in theory, but the attack is still post-initial-compromise inside the browser chain.
Conditions required:
  • Successful memory-corruption control from the ANGLE bug
  • A viable path from renderer to a less-restricted process or host context
Where this breaks in practice:
  • Chrome sandboxing, CFG/CET/ASLR, and platform hardening raise the bar materially
  • Many exploit attempts die as renderer crashes without achieving a durable sandbox escape
Detection/coverage: Look for Chrome renderer crash loops followed by suspicious browser child-process behavior, unusual token/handle activity, or EDR alerts on browser exploit techniques.
STEP 04

Operationalize host impact

After escape, the attacker still needs to execute follow-on actions such as credential theft, persistence, or payload staging. The final blast radius depends on user rights and what post-exploitation controls exist on the endpoint.
Conditions required:
  • Successful sandbox escape
  • Useful user context and an endpoint not blocked by EDR/application control
Where this breaks in practice:
  • Standard-user desktops, EDR containment, and application control still limit payoff
  • This remains a client-side compromise path, not a wormable network-service event
Detection/coverage: EDR should have the best chance here: browser-origin child processes, suspicious LOLBIN use, token abuse, or payload drops from Chrome-owned paths.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current evidence of active exploitation in primary sources. Google did not flag this release as a zero-day, and CISA KEV does not list CVE-2026-11065 as of 2026-06-05.
PoC availabilityNo public weaponized PoC located in primary sources. The Chromium issue exists but details are restricted, which is normal until patch adoption improves.
EPSS0.00035 from the supplied intel block; *very low expected short-term exploitation probability*. Percentile was not supplied in the prompt.
KEV statusNot KEV-listed. That removes the strongest urgency amplifier for enterprise patch triage.
Vendor vs. Google severityThe supplied intel says CRITICAL 9.6 with AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, but Google's June 2, 2026 stable release post labels CVE-2026-11065 as Medium. For this CVE, Google's rating better reflects the real prerequisite chain.
Affected versionsGoogle states the fix shipped in Chrome 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac), so earlier desktop builds are affected.
Fixed versionsPatch floor: 149.0.7827.53 or newer. Treat any managed desktop browser below that floor as vulnerable.
Scanning / exposureNot Shodan/Censys-addressable in any useful way. This is a client-side browser flaw, not a listening network service, so external exposure counts are a poor prioritization signal.
Disclosure timelineThere is a date mismatch worth calling out: Google shipped the fix on 2026-06-02 in the stable channel post, while the supplied intel says disclosed 2026-06-04. That usually means downstream CVE publication lagged the vendor patch release.
ReporterGoogle's release post says Reported by Google on 2026-04-03.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.5/10)

The single biggest severity reducer is the renderer-compromise prerequisite. If an attacker already needs a separate successful browser exploit before this bug matters, then this CVE is a post-initial-access chain component, not a frontline enterprise patch emergency by itself.

HIGH Affected version floor and Google's own Medium classification
HIGH Attack-path friction from the required prior renderer compromise
MEDIUM Exact post-exploitation impact wording because the Chromium bug details are restricted

Why this verdict

  • Renderer compromise required: starting from the supplied 9.6 baseline, the biggest downward adjustment is that the attacker must already own the renderer first. That implies a prior exploit stage succeeded, which massively narrows who can actually use this bug.
  • Client-side and non-scannable: Chrome is everywhere, but this is not a remotely reachable service you can sweep from the internet. Reachability depends on user browsing plus exploit-chain quality, which cuts practical abuse volume.
  • No exploitation evidence: no KEV listing, no zero-day language from Google, and a very low supplied EPSS score all push urgency down further.
  • Google itself scored it Medium: when Google's release notes and downstream CVSS-style metadata disagree, the vendor's product-context severity is usually the better guide for browser chain bugs like this.

Why not higher?

It is not higher because this CVE is not a standalone initial-access event. A bug that requires prior renderer compromise is, by definition, a second-stage exploit component whose real-world population is smaller than a true unauthenticated remote code execution flaw.

Why not lower?

It is not lower because sandbox-escape primitives in Chrome still matter a lot when they *do* chain cleanly. Chrome is widely deployed, ANGLE sits on a security-sensitive graphics path, and a working exploit would materially raise attacker payoff from a renderer foothold.

05 · Compensating Control

What to do — in priority order.

  1. Keep Chrome auto-update unblocked — Make sure update policies, version pinning, and software-distribution rings are not freezing browsers below 149.0.7827.53. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the 365-day remediation window, but fixing broken update channels should happen in normal browser hygiene immediately because it reduces exposure to the whole Chrome bug bundle, not just this CVE.
  2. Restrict unnecessary WebGL/GPU access where feasible — On high-risk kiosks, VDI pools, and tightly managed admin workstations, consider temporarily reducing unneeded graphics exposure if business workflows allow it. This is a niche compensating control only; there is no noisgate mitigation SLA for MEDIUM, so use it selectively while patching inside the 365-day remediation window.
  3. Hunt for Chrome crash clusters — Pull browser and EDR telemetry for repeated renderer/GPU-process crashes, especially ANGLE- or libGLESv2-related faults, because exploit development against lifetime bugs is noisy before it is reliable. Do this in routine monitoring; again, there is no noisgate mitigation SLA for MEDIUM unless active exploitation emerges.
  4. Focus exceptions on frozen images — Audit VDI, kiosk, gold-image, and offline endpoints where Chrome auto-update is commonly disabled or delayed. Those populations are where a Medium browser CVE quietly turns into long-lived exposure over the 365-day remediation window.
What doesn't work
  • WAFs and perimeter IPS do not meaningfully help because this is a client-side browser exploit stage, not a server-side web attack surface.
  • External attack-surface scanners will not show you exposure in any useful sense; the problem is browser version state on endpoints.
  • MFA is good security hygiene but irrelevant to the exploit path described here.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/endpoint-management tooling. Invoke it with python3 check_chrome_cve_2026_11065.py on macOS/Linux or py check_chrome_cve_2026_11065.py on Windows; no admin rights are required unless your EDR blocks process inspection.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11065.py
# Detects whether local Google Chrome is below the fixed version for CVE-2026-11065.
# 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)


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 run_version(path):
    try:
        p = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=5)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_version(out)
    except Exception:
        return None


def candidates():
    system = platform.system()
    paths = []
    if system == 'Windows':
        for envvar in ('PROGRAMFILES', 'PROGRAMFILES(X86)', 'LOCALAPPDATA'):
            base = os.environ.get(envvar)
            if base:
                paths.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
    elif system == 'Darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ])
    else:
        for name in ('google-chrome', 'google-chrome-stable', 'chrome'):
            found = shutil.which(name)
            if found:
                paths.append(found)
        paths.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/opt/google/chrome/chrome',
        ])

    seen = []
    unique = []
    for p in paths:
        if p not in seen:
            seen.append(p)
            unique.append(p)
    return unique


def main():
    found_any = False
    for path in candidates():
        if not os.path.exists(path) and not shutil.which(path):
            continue
        ver = run_version(path)
        if ver is None:
            continue
        found_any = True
        print(f'FOUND: {path}')
        print('VERSION: %d.%d.%d.%d' % ver)
        print('FIXED_AT: %d.%d.%d.%d' % FIXED)
        if ver >= FIXED:
            print('PATCHED')
            sys.exit(0)
        else:
            print('VULNERABLE')
            sys.exit(1)

    if not found_any:
        print('UNKNOWN')
        print('Google Chrome not found or version could not be determined.')
        sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning, do not treat CVE-2026-11065 like an emergency standalone RCE; treat it like a browser-chain component and focus on endpoints where Chrome updates are pinned, broken, or image-based. For this MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA, but in practice you should sweep managed fleets for versions below 149.0.7827.53, fix channel/update-policy drift, and close the laggard population through normal browser maintenance rather than burning an out-of-band patch cycle.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases - 2026 archive
  3. Chromium issue 499093536
  4. Chromium Security Page
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. Chrome Enterprise - Manage Chrome updates (Windows)
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.