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

Integer overflow 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 inner door, not a battering ram for the front gate

CVE-2026-11088 is an integer overflow in Chrome's ANGLE graphics layer, affecting Chrome builds before 149.0.7827.53. Based on the supplied description, the bug is only reachable after an attacker has already compromised the renderer process, which makes this a classic post-renderer browser exploit primitive rather than a stand-alone web-to-host compromise.

Google's CRITICAL 9.6 label is fair only if you grade the *full potential impact in a perfect exploit chain*. For enterprise patching, that overstates the real-world priority because the hardest part of the intrusion is not this bug; it's the prerequisite renderer compromise. No KEV listing, a very low EPSS 0.00035, and no public exploitation evidence push this down from emergency to disciplined browser hygiene.

"This is a second-stage Chrome chain bug, not a clean one-shot internet RCE."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a renderer foothold first

The attacker needs a separate bug or exploit path to gain code execution or equivalent control inside Chrome's renderer sandbox. In practice that usually means chaining a different browser vulnerability through a crafted page, ad-tech placement, or a malicious content delivery path. Weaponized tooling here is a custom renderer exploit chain, not CVE-2026-11088 by itself.
Conditions required:
  • Target runs vulnerable Chrome prior to 149.0.7827.53
  • User reaches attacker-controlled web content
  • Attacker has a separate renderer compromise primitive
Where this breaks in practice:
  • This CVE is useless without a first bug
  • Safe Browsing, exploit mitigations, site isolation, and renderer hardening may kill the initial stage
  • The required pre-compromise sharply narrows the exploitable population
Detection/coverage: Version-based scanners can flag vulnerable Chrome builds, but they cannot tell whether an attacker has a working renderer-stage exploit to pair with this CVE.
STEP 02

Trigger the ANGLE integer overflow

With renderer control, the attacker drives crafted graphics operations into ANGLE to hit the integer overflow and create memory corruption conditions. The likely weaponized mechanism is a malicious shader / WebGL-style graphics workload delivered from the compromised renderer into the GPU-facing stack.
Conditions required:
  • Renderer process can issue the relevant graphics calls
  • Affected ANGLE code path is reachable on the target platform
Where this breaks in practice:
  • Exploit reliability can vary by GPU, driver, OS build, and Chrome sandbox behavior
  • Graphics-path bugs often need platform-specific grooming for stable corruption
Detection/coverage: EDR and NDR generally have weak visibility into renderer-to-ANGLE exploit internals; telemetry is usually crash-based rather than exploit-signature-based.
STEP 03

Convert corruption into sandbox escape

The practical attacker goal is not a renderer crash; it is a controlled cross-boundary outcome such as a sandbox escape or privilege gain into a more trusted browser or GPU-adjacent context. This stage normally requires careful heap shaping and a target-specific exploit, often with a bespoke browser exploit framework rather than commodity malware.
Conditions required:
  • The overflow is exploitable, not just crashable
  • Attacker can steer the bug toward a security boundary crossing
Where this breaks in practice:
  • Modern browser exploit mitigations make stable post-corruption control expensive
  • A crash without boundary escape is operationally noisy and low value
Detection/coverage: Browser crash telemetry, unusual child-process terminations, and sudden Chrome relaunches may show up, but exploit-vs-crash attribution is poor.
STEP 04

Monetize the escape

After a successful escape, the attacker still needs a follow-on objective: credential theft, session hijack, or host-level persistence. The exploit chain usually hands them a better foothold, not instant domain compromise. Tooling here becomes the operator's standard post-exploitation kit.
Conditions required:
  • Successful sandbox escape or equivalent boundary break
  • Valuable user session or host context available
Where this breaks in practice:
  • EDR, browser isolation, and least-privilege endpoints can still contain blast radius
  • Many enterprise users browse as standard users with limited local privilege
Detection/coverage: This is where defenders finally get decent visibility: EDR process telemetry, token abuse, persistence attempts, and suspicious credential access.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo known active exploitation evidence in the materials reviewed, and not listed in CISA KEV.
PoC availabilityNo public PoC found in the reviewed web results. That does not mean exploitability is low; it means the bug currently looks non-commoditized.
EPSS0.00035 from the supplied intel, which is extremely low modeled near-term exploitation probability.
KEV statusNot KEV-listed. That matters because KEV is the clearest public signal that operators are already cashing in.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H maps to a worst-case chain outcome, but it does not price in the explicit renderer-compromise prerequisite well enough for enterprise prioritization.
Affected versionsChrome before 149.0.7827.53 per supplied intel; public release reporting shows 149.0.7827.53/.54 as the fixed desktop train.
Fixed versionsTreat 149.0.7827.53 or later as the minimum safe baseline, with Windows/macOS rollout commonly shown as 149.0.7827.53/.54. No meaningful distro backport nuance here because packaged Chrome tracks Google's own versioning.
Exposure realityThis is a client-side browser bug. Shodan/Censys/FOFA are mostly irrelevant because the exposure is your endpoint fleet lag, not an internet-facing service banner.
DisclosureSupplied disclosure date: 2026-06-04.
Researcher / reportingNo named external reporter was confirmed in the sources reviewed. Like many Chrome bulk-fix releases, this may have been Google-internal discovery or routine hardening work.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The decisive downgrade factor is the attacker position requirement: this bug only matters after the attacker has already won a renderer foothold. That turns a vendor-scored internet-facing critical into a second-stage exploit component with a much smaller exposed population and no current exploitation signal.

HIGH Downgrade from vendor CRITICAL due to explicit renderer-compromise prerequisite
MEDIUM Assessment that real-world exploit demand remains low absent KEV/PoC activity
LOW Exact exploit reliability across GPU/driver combinations

Why this verdict

  • Big downgrade for attacker position: the attacker must already control the renderer process, which implies a prior compromise stage and makes this a chain component, not initial access.
  • Population narrowing: every prerequisite compounds downward pressure — user browsing, vulnerable build, correct graphics path, and a separate renderer exploit all have to line up.
  • Low demand signal: no KEV, no public exploitation evidence, and EPSS 0.00035 say operators are not broadly prioritizing this bug right now.

Why not higher?

If this were a one-click, stand-alone web-to-host bug, the vendor's critical framing would be much closer to reality. But the supplied description bakes in a massive prerequisite: the attacker must first compromise the renderer, which is exactly the kind of friction that should crush patch priority when you're triaging a 10,000-host fleet.

Why not lower?

It is still a browser memory-safety flaw in a security-boundary-adjacent component with potentially serious chain value. On high-risk users, browsers are common initial-access battlegrounds, and second-stage sandbox escapes deserve more respect than generic backlog noise.

05 · Compensating Control

What to do — in priority order.

  1. Enforce auto-update and relaunch — Make sure Chrome update policy is not blocked and force relaunch prompts or restart deadlines so the fixed build is actually loaded into memory. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still clean up laggards early because stale clients accumulate chain risk.
  2. Prioritize high-risk user rings — Patch admins, developers, finance, executives, and users who regularly handle untrusted web content first. Even without a noisgate mitigation deadline, these populations are the most likely to face targeted exploit chaining, so move them to the fixed Chrome train well before the broader 365-day remediation ceiling.
  3. Keep browser exploit mitigations intact — Do not weaken site isolation, sandboxing, Safe Browsing, or OS exploit protections in pursuit of compatibility unless you have a documented exception. These controls specifically raise the cost of the renderer-first precondition that makes this CVE materially less urgent.
  4. Restrict advanced web graphics where justified — For highly sensitive cohorts or kiosk workloads, consider policy-based reduction of WebGL/WebGPU exposure if business use allows it. This is not required for the whole fleet, but it is a practical temporary hardening move while you drain old browser versions.
What doesn't work
  • Perimeter scanning doesn't help because this is endpoint browser exposure, not a server socket problem.
  • Signature-only AV is weak here because modern browser exploitation is memory-corruption-driven and often custom-built.
  • Network IDS is not a reliable control; the trigger can be ordinary-looking web content over HTTPS and the meaningful exploit logic lives inside the client.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/MDM agent. Invoke it with python3 check_chrome_cve_2026_11088.py on macOS/Linux or py check_chrome_cve_2026_11088.py on Windows; no admin rights are required if the Chrome binary is in a standard install path, but wider filesystem access improves coverage.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11088.py
# Determine whether locally installed Google Chrome is below 149.0.7827.53.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

THRESHOLD = (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 compare_versions(a, b):
    return (a > b) - (a < b)


def try_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return p.returncode, out.strip()
    except Exception:
        return None, ''


def check_windows():
    candidates = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]
    for c in candidates:
        if c and os.path.exists(c):
            rc, out = try_cmd([
                'powershell', '-NoProfile', '-Command',
                f"(Get-Item '{c}').VersionInfo.ProductVersion"
            ])
            ver = parse_version(out)
            if ver:
                return c, ver
    return None, None


def check_macos():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for c in candidates:
        if os.path.exists(c):
            rc, out = try_cmd([c, '--version'])
            ver = parse_version(out)
            if ver:
                return c, ver
    return None, None


def check_linux():
    cmds = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
    ]
    for cmd in cmds:
        rc, out = try_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ' '.join(cmd[:-1]), ver

    candidates = [
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/snap/bin/chromium',
        '/usr/bin/chromium-browser',
        '/usr/bin/chromium',
    ]
    for c in candidates:
        if os.path.exists(c):
            rc, out = try_cmd([c, '--version'])
            ver = parse_version(out)
            if ver:
                return c, ver
    return None, None


def main():
    system = platform.system().lower()
    path = None
    ver = None

    if 'windows' in system:
        path, ver = check_windows()
    elif 'darwin' in system:
        path, ver = check_macos()
    elif 'linux' in system:
        path, ver = check_linux()
    else:
        print('UNKNOWN: unsupported OS')
        sys.exit(2)

    if not ver:
        print('UNKNOWN: Chrome/Chromium not found or version unreadable')
        sys.exit(2)

    status = 'PATCHED' if compare_versions(ver, THRESHOLD) >= 0 else 'VULNERABLE'
    print(f'{status}: version={".".join(map(str, ver))} path={path} threshold={".".join(map(str, THRESHOLD))}')
    sys.exit(0 if status == 'PATCHED' else 1)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a browser-version cleanup item, not a paging event. Put Chrome versions older than 149.0.7827.53 into your next normal browser wave, verify auto-update/relaunch enforcement, and front-load high-risk user groups; under the noisgate mitigation SLA there is no mitigation SLA — go straight to the 365-day remediation window, and under the noisgate remediation SLA the vendor patch should be fully deployed within 365 days. Because this is a post-renderer chain bug with no KEV listing or active exploitation signal, the right move is disciplined fleet hygiene, not emergency disruption.

Sources

  1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases homepage
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS overview
  5. FIRST EPSS API documentation
  6. SecurityWeek coverage of Chrome 149 security fixes
  7. PCWorld coverage of Chrome 149 security fixes
  8. CVE.org analogous Chrome post-renderer CVE pattern
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.