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

Out of bounds memory access in ANGLE in Google Chrome prior to 149

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

This is a cracked windshield in a moving car, not a missing front axle

CVE-2026-11191 is an out-of-bounds memory access bug in ANGLE, Chrome's graphics translation layer, reachable by getting a user to render attacker-controlled web content. The authoritative affected range is Google Chrome before 149.0.7827.53 on Linux and Windows, and before 149.0.7827.54 on Mac, based on Google's June 2, 2026 stable release and the earlier May 29, 2026 early-stable push.

The vendor baseline of 8.8/HIGH overstates enterprise urgency. In practice this is a client-side, user-driven, single-bug browser memory issue with no KEV listing, no confirmed in-the-wild exploitation, no public PoC, and an important vendor-side tell: Google itself labeled the bug's Chromium security severity as Medium. The big downward pressure is that a lone browser renderer/GPU bug usually needs a second-stage primitive or sandbox escape to become an estate-wide emergency.

"Wide client footprint, but this looks like a sandboxed browser bug with no exploitation signal and no public weaponization"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on malicious content

The attacker needs a user to browse to a crafted HTML page or embedded content that exercises ANGLE-rendered graphics paths. In real operations that usually means phishing, malvertising, SEO-poisoned landing pages, or compromise of a legitimate site rather than direct network reachability.
Conditions required:
  • Victim is running Chrome below 149.0.7827.53/54
  • Victim visits attacker-controlled or attacker-influenced web content
  • Relevant graphics path is reachable in that browser session
Where this breaks in practice:
  • Requires user interaction
  • Email/web filtering and safe browsing controls can break delivery
  • Not an unauthenticated hit-against-a-server condition
Detection/coverage: Coverage is mostly indirect: URL filtering, phishing telemetry, browser isolation logs, and web proxy traces. Vulnerability scanners can usually only do version-based detection.
STEP 02

Trigger ANGLE memory misuse

A malicious page would use WebGL, canvas, shaders, or related graphics inputs to drive ANGLE into the out-of-bounds access condition. No public exploit chain is available at time of writing, so this remains a theoretical-to-likely crash/info-leak primitive rather than a broadly reusable offensive package.
Conditions required:
  • ANGLE code path must be exercised
  • Attacker can shape inputs enough to hit the vulnerable condition
Where this breaks in practice:
  • Bug details remain restricted in Google's tracker
  • No public PoC lowers copycat risk
  • Exploit reliability across GPU drivers and OS variants is usually messy
Detection/coverage: EDR may see renderer/GPU-process crashes, exception telemetry, or anomalous child-process failures, but signature-quality detection is weak without exploit artifacts.
STEP 03

Turn memory corruption into useful control

Out-of-bounds access is the entry primitive, not the final business impact. The attacker still has to convert it into a stable read/write, code execution, or meaningful data exposure inside the compromised browser process.
Conditions required:
  • Primitive is strong enough for control rather than only crash
  • Target-specific exploit reliability is achieved
Where this breaks in practice:
  • Many browser memory bugs die as crashes
  • Modern mitigations and partitioning reduce exploit reliability
  • The CNA wording says 'potentially' perform out-of-bounds access, which is weaker than confirmed RCE language
Detection/coverage: Crash spikes, unusual browser termination codes, and exploit-protection events are the main signals. Traditional network IDS has little content-level visibility here.
STEP 04

Escape browser containment for real host impact

To reach full workstation compromise, the attacker generally needs to get beyond the browser sandbox or chain a second vulnerability. Without that, the blast radius is usually limited to browser-process context, session material, or a crash/denial outcome.
Conditions required:
  • Successful post-corruption execution in a constrained browser process
  • A sandbox bypass, broker abuse, or second bug if host-level compromise is desired
Where this breaks in practice:
  • This CVE by itself is not described as a sandbox escape
  • Browser process isolation is a major real-world severity brake
  • No evidence of an active exploit chain paired with this bug
Detection/coverage: EDR, exploit protection, and browser sandbox telemetry are the tools most likely to catch the escape stage. Version-only scanners cannot validate exploitability beyond exposure.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found. Not in CISA KEV, and Google did not flag it as exploited in the release notes.
Proof-of-concept availabilityNo public PoC located. Google's issue is still referenced but details may remain restricted until most users are patched, which meaningfully slows copycat weaponization.
EPSSLow signal. Prompt supplied 0.00068; CIRCL's June 5, 2026 mirror shows 0.00035 / 10.8th percentile, so either way this sits in the *very low* exploit-likelihood bucket.
KEV statusNot KEV-listed as of June 2026. That removes the strongest urgency override.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = remotely triggerable through web content, but user interaction is required and the vector assumes full CIA impact that is not proven by the published bug details.
Vendor/CNA characterizationImportant nuance: the CVE text says '(Chromium security severity: Medium)' even though NVD/CISA ADP score it 8.8 High. For browser bugs, I trust the product team's component-level severity signal more than the generic CVSS math.
Affected versionsChrome <149.0.7827.53 broadly, with Google's desktop stable note calling out 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/Mac.
Fixed versionsFixed in 149.0.7827.53 for Linux/Windows and 149.0.7827.54 for Mac. There is no distro-style backport story here; this is a browser-channel update.
Scanning/exposure realityThis is a client-side browser flaw, so Shodan/Censys/FOFA-style internet exposure counts are basically *not applicable*. Your exposure is your managed endpoint population, not a public-facing service footprint.
Disclosure and reporterPublished 2026-06-04 in the CVE record; Google's stable desktop advisory shipped 2026-06-02 and lists the bug as reported by Google on 2026-04-16 under issue 503392431.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

The decisive brake is containment: this is a user-driven browser memory bug with no evidence that the single CVE escapes Chrome's sandbox or reliably delivers host compromise on its own. Wide deployment keeps it relevant, but absent exploitation evidence or a proven exploit chain, it does not justify a HIGH-priority incident response posture.

HIGH Exposure identification by version
MEDIUM Severity downgrade based on likely need for a second-stage escape

Why this verdict

  • Vendor 8.8 starts too high for reality because CVSS gives full CIA credit, while the published record only confirms out-of-bounds access in a browser component and Google's own Chromium severity says *Medium*.
  • Requires user interaction: the attacker cannot just hit an internet-facing service; they must get a victim to render malicious web content, which means phishing, malvertising, or site compromise first.
  • Sandbox/process isolation is the main downward adjustment: to turn a browser-process memory bug into full endpoint compromise, the attacker usually needs a second bug or escape stage that is not part of this CVE.
  • No exploitation signal: no KEV listing, no public campaign reporting, no exploit kit chatter surfaced, and no public PoC materially reduce short-term operational risk.
  • Population is huge but blast radius per trigger is local: yes, Chrome is everywhere, but exploitation is one-user-at-a-time, not one-packet-to-10,000-hosts.

Why not higher?

There is no evidence this CVE alone provides a clean path to host takeover, domain impact, or wormable propagation. The combination of required user interaction, absent public weaponization, and likely sandbox containment keeps this out of HIGH territory.

Why not lower?

It is still a remotely reachable browser memory-safety flaw in a ubiquitous enterprise application. If a user visits hostile content on an unpatched build, the bug is reachable, and memory bugs in browser graphics code are never noise-level backlog items.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure enterprise policy forces Chrome to update and relaunch so vulnerable builds age out quickly. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice you should let normal browser update controls do the work now rather than waiting for an annual cleanup cycle.
  2. Prefer browser isolation for high-risk users — Put admins, finance, executives, and help-desk staff behind remote/browser isolation for unknown sites and email-delivered links. There is no mitigation SLA for MEDIUM here, so use this as a targeted exposure reducer until patched versions are universal inside the remediation window.
  3. Harden risky web content paths — Use secure web gateway policy, Safe Browsing, attachment detonation, and ad/tracker filtering to cut down delivery of hostile pages that would need to trigger the bug. This matters because the first real friction point is getting a user onto attacker-controlled content.
  4. Watch for browser crash anomalies — Trend Chrome renderer/GPU-process crashes and exploit-protection events in EDR/SIEM, especially after suspicious link clicks or on high-risk user groups. This will not prove exploitation, but it can surface attempted trigger activity while patch compliance catches up.
What doesn't work
  • A WAF does not help because the vulnerable asset is the client browser, not your server.
  • Perimeter port scanning reduction is irrelevant; there is no exposed listener to close.
  • Generic network IDS signatures are weak here because the exploit would be embedded in normal-looking web content and browser rendering behavior.
  • Disabling Chrome entirely is not a realistic control for most enterprises and just shifts users to another browser with its own patch burden.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR execution framework. Invoke it as python3 chrome_cve_2026_11191_check.py on macOS/Linux or py chrome_cve_2026_11191_check.py on Windows; standard user rights are usually enough because it only reads local version metadata.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11191 Chrome version check
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

TARGET = (149, 0, 7827, 53)
MAC_TARGET = (149, 0, 7827, 54)


def norm(v):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', v or '')
    return tuple(int(x) for x in m.groups()) if m else None


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


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        if p.returncode == 0:
            return p.stdout.strip() or p.stderr.strip()
    except Exception:
        pass
    return None


def candidates_windows():
    local = os.environ.get('LOCALAPPDATA', '')
    pf = os.environ.get('ProgramFiles', '')
    pfx86 = os.environ.get('ProgramFiles(x86)', '')
    return [
        os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(local, 'Chromium', 'Application', 'chrome.exe'),
        os.path.join(pf, 'Chromium', 'Application', 'chrome.exe'),
        os.path.join(pfx86, 'Chromium', 'Application', 'chrome.exe'),
    ]


def candidates_macos():
    return [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium'),
    ]


def candidates_linux():
    paths = []
    for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
        p = which(name)
        if p:
            paths.append(p)
    paths += [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
        '/snap/bin/chromium',
    ]
    return paths


def get_version_from_binary(path):
    if not path or not os.path.exists(path):
        return None
    out = run_cmd([path, '--version'])
    if out:
        return norm(out)
    return None


def get_version_windows_ps(path):
    if not path or not os.path.exists(path):
        return None
    ps = which('powershell') or which('pwsh')
    if not ps:
        return None
    cmd = [ps, '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"]
    out = run_cmd(cmd)
    return norm(out) if out else None


def find_installed_version():
    sysname = platform.system()

    if sysname == 'Windows':
        for p in candidates_windows():
            v = get_version_windows_ps(p) or get_version_from_binary(p)
            if v:
                return ('Windows', p, v)

    elif sysname == 'Darwin':
        for p in candidates_macos():
            v = get_version_from_binary(p)
            if v:
                return ('Darwin', p, v)

    else:
        for p in candidates_linux():
            v = get_version_from_binary(p)
            if v:
                return ('Linux', p, v)

    return (sysname, None, None)


def main():
    sysname, path, version = find_installed_version()
    if not version:
        print('UNKNOWN')
        print(f'platform={sysname} reason=chrome_not_found_or_version_unreadable')
        sys.exit(2)

    fixed = MAC_TARGET if sysname == 'Darwin' else TARGET
    status = 'PATCHED' if cmp_ver(version, fixed) >= 0 else 'VULNERABLE'

    print(status)
    print(f'platform={sysname} path={path} version={".".join(map(str, version))} fixed={".".join(map(str, fixed))}')

    if status == 'PATCHED':
        sys.exit(0)
    else:
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning, pull a version inventory for all managed Chrome/Chromium endpoints and verify that anything still below 149.0.7827.53 (or 149.0.7827.54 on Mac) is scheduled into your normal browser update flow, not your emergency bridge. For this MEDIUM reassessment there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤365 days, though in a sane endpoint program this should converge far sooner through enforced auto-update and relaunch policy.

Sources

  1. Google Chrome Stable Channel Update for Desktop
  2. Google Chrome Early Stable Update for Desktop
  3. Chromium Issue 503392431
  4. CIRCL Vulnerability Lookup for CVE-2026-11191
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. NVD entry for CVE-2026-11191
  8. GitHub Advisory GHSA-r79w-gpv4-pww2
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.