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

Out of bounds read and write in ANGLE in Google Chrome prior to 149

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

This is a booby-trapped webpage trying to turn Chrome’s graphics engine into a pry bar against its own cage

Per the supplied intel, this is an out-of-bounds read/write in ANGLE, Chrome’s graphics translation layer used by WebGL and related rendering paths. A remote attacker would need to get a user onto a crafted HTML page, then hit the vulnerable code path in Chrome builds before 149.0.7827.53; the fixed train visible in public release material is 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.

The vendor’s CRITICAL 9.6 framing overshoots operational reality for most enterprises. Yes, the technical impact is ugly because the claim is *potential sandbox escape*, but this is still a client-side, user-interaction, browser-path bug with no KEV listing, no public exploitation signal I could verify, and no meaningful internet-exposure surface like an edge appliance or public server; that combination pushes it down to a strong HIGH, not a pager-everyone CRITICAL.

"Serious drive-by browser bug, but no exploitation evidence and required user browsing keep it below CRITICAL."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on an exploit page

The attacker needs a browser session on a malicious or compromised website, phishing page, ad slot, or watering hole. The practical weapon is a custom HTML/JavaScript/WebGL landing page designed to drive execution into ANGLE-heavy rendering paths. This is a classic drive-by setup, but it still starts with user interaction.
Conditions required:
  • Victim uses vulnerable Chrome prior to 149.0.7827.53
  • Victim visits attacker-controlled or attacker-compromised content
  • Rendering path reaches ANGLE-relevant code
Where this breaks in practice:
  • Requires a live user browsing session; no unauthenticated internet service to hit directly
  • Enterprise filtering, Safe Browsing, mail protections, and ad blocking reduce delivery success
  • Some exploit chains are brittle across GPU/driver/platform combinations
Detection/coverage: Email/web gateways and browser isolation platforms can sometimes catch delivery. Vulnerability scanners mostly provide version-based detection only; there is no reliable network fingerprint for a client browser flaw.
STEP 02

Trigger ANGLE memory corruption

Once the page is rendered, the exploit attempts out-of-bounds read/write in ANGLE using crafted graphics input. In practice that means a highly version-sensitive exploit path, usually involving WebGL/GPU activity and careful heap shaping. The likely weaponized component is a browser exploit script plus shader or rendering primitives tailored to the target build.
Conditions required:
  • ANGLE code path reachable on the target system
  • Exploit tuned to victim Chrome build and platform behavior
  • Browser mitigations not enough to blunt the primitive
Where this breaks in practice:
  • Modern browser hardening, ASLR, allocator behavior, and process isolation make exploitation non-trivial
  • Graphics bugs often vary by OS, driver stack, and hardware acceleration state
  • Crash-only outcomes are common when exploit reliability is poor
Detection/coverage: Telemetry may show unusual GPU-process or renderer crashes, repeated browser faults, or exploit-like WebGL activity. Most EDRs will not label the root cause as this CVE without version/context enrichment.
STEP 03

Convert corruption into a sandbox boundary break

The supplied description says the bug can *potentially* perform a sandbox escape, which is the key difference between a routine browser crash and a real enterprise problem. If the attacker can cross from the compromised web content path into a more privileged browser or system context, they move from tab compromise toward endpoint compromise. That is the amplifier here, but it is still a *potential* outcome rather than verified in-the-wild tradecraft.
Conditions required:
  • Exploit yields more than a renderer/GPU crash
  • Sandbox boundary is actually crossed in the victim environment
  • Post-exploitation code runs before browser restart or user closes session
Where this breaks in practice:
  • Site Isolation and Chrome sandboxing are specifically designed to make this stage hard
  • Many memory-safety bugs never mature into reliable sandbox escapes
  • No verified public evidence yet that operators are using this CVE successfully at scale
Detection/coverage: Hunt for child processes, unusual module loads, token/IPC abuse, or browser-originated payload staging. Endpoint telemetry is better than network telemetry here.
STEP 04

Execute follow-on payload in user context

If the sandbox break works, the attacker’s next move is standard post-exploitation: credential theft, persistence, lateral movement staging, or dropping commodity loaders. The likely tools are the same post-browser tradecraft seen after successful client-side exploitation: PowerShell, LOLBins, signed loaders, or infostealers. At that point the browser bug is only the front door.
Conditions required:
  • Successful code execution outside the intended sandbox boundary
  • Endpoint controls fail to block the second-stage payload
  • User privileges are enough to make the compromise useful
Where this breaks in practice:
  • EDR, application control, and restricted user rights can still contain damage
  • A browser exploit against one workstation is not the same as instant domain-wide blast radius
  • Reboots, browser restarts, and ephemeral sessions can cut short unstable chains
Detection/coverage: EDR should be your main net here. Look for browser-spawned scripts, unsigned DLL loads, scheduled task creation, suspicious archive writes, or credential access behavior immediately after Chrome crashes or relaunches.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public active-exploitation statement verified, and not KEV-listed as of 2026-06-04.
Public PoC statusI did not locate a public PoC for this CVE. Chrome often keeps bug details restricted until the majority of users are patched, which suppresses early PoC visibility.
EPSSNo public FIRST EPSS hit was verifiable yet for this exact CVE at assessment time; treat EPSS as not yet populated / unknown, not as low risk.
KEV statusCISA Known Exploited Vulnerabilities catalog: not listed.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H means remote delivery with no auth, but user interaction is required. The important bit is S:C, which reflects a claimed security-boundary crossing rather than a same-process crash.
Affected versionsSupplied intel says Chrome prior to 149.0.7827.53. Public release notes show the fixed train as 149.0.7827.53 Linux and 149.0.7827.53/.54 Windows/macOS.
Fixed versionsPatch to 149.0.7827.53+; for Windows/macOS specifically the public rollout shows 149.0.7827.53/.54. Chromium-derived browsers should be checked on their own vendor cadence rather than assumed safe.
Exposure / scanning realityThere is no meaningful Shodan/Censys/FOFA internet-exposure lens here because Chrome is client software, not a listening service. Detection is endpoint inventory and version management, not internet scanning.
Disclosure date2026-06-04 per the supplied intel. Public 149 stable release material appeared across 2026-05-29 to 2026-06-02 depending on channel and publication.
Reporter / researcherNot publicly attributable from the sources I could verify; Chrome bug references appear to still be under normal disclosure restriction.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.2/10)

The decisive drag on severity is attacker position: this is a client-side exploit that requires a vulnerable user to browse attacker-controlled content, not an unauthenticated hit on an enterprise service. The main amplifier is the claimed sandbox-escape potential in a massively deployed browser, which keeps it firmly in HIGH despite the lack of verified exploitation evidence.

HIGH Exploit-path friction assessment
MEDIUM Metadata completeness for this exact CVE ID

Why this verdict

  • Downgrade from vendor 9.6: remote and dangerous, but still gated by UI:R and a browser session on malicious content rather than direct service exposure
  • Big population, limited reachability: Chrome is everywhere, but every exploit attempt still needs per-user delivery and a compatible client environment
  • No verified exploitation signal: no KEV listing and no public vendor statement of in-the-wild use materially reduce urgency versus true browser zero-days

Why not higher?

I am not calling this CRITICAL because the path is narrowed by required user browsing activity and the absence of confirmed exploitation. A browser bug that *might* escape the sandbox is serious, but without proof of active abuse it does not deserve the same bucket as an externally reachable, weaponized edge-device RCE.

Why not lower?

I am not dropping this to MEDIUM because the impact ceiling is still endpoint compromise from a drive-by page in a ubiquitous browser. If the sandbox-escape claim is accurate, one successful click can move the incident from 'tab crash' to 'workstation compromise', which is too consequential for MEDIUM.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update and relaunch — Use enterprise browser policy to force Chrome version compliance and relaunch prompts, then confirm fleet convergence to the fixed build. For a HIGH verdict, deploy this control within 30 days if any lagging population prevents immediate patch uptake.
  2. Disable or constrain WebGL/ANGLE on high-risk tiers — For privileged admin workstations, kiosk systems, and other sensitive tiers, consider temporarily restricting WebGL or hardware-accelerated graphics paths if your business apps tolerate it. This reduces reachability to the vulnerable component; for a HIGH verdict, apply within 30 days where patch latency exists.
  3. Route risky browsing through isolation — Push internet-facing browsing for high-risk users through browser isolation, disposable VDI, or similarly segmented environments so a client-side exploit has a smaller blast radius. Treat this as the fallback when you cannot guarantee patch compliance, and put it in place within 30 days.
  4. Alert on browser-child process abuse — Tune EDR detections for chrome spawning PowerShell, cmd, script hosts, unexpected installers, or suspicious archive writes immediately after crashes or relaunches. This will not prevent exploitation, but it gives you a decent chance to catch successful second-stage execution within 30 days.
What doesn't work
  • A WAF does not solve this; the attack is rendered in the client browser, often from legitimate HTTPS content or compromised sites.
  • Perimeter vulnerability scanners do not solve this; they cannot reliably probe a non-listening client browser and mostly fall back to version inventory.
  • MFA is irrelevant to initial exploitability; it may reduce follow-on account abuse, but it does not stop the browser memory corruption path.
06 · Verification

Crowdsourced verification payload.

Run this on the target host or via your software distribution / RMM agent. Invoke with python3 check_chrome_cve_2026_10881.py on macOS/Linux or py check_chrome_cve_2026_10881.py on Windows; no admin rights are required, but local filesystem access to Chrome install paths is needed.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_10881.py
# Detect local Google Chrome version and compare against fixed version 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED = (149, 0, 7827, 53)


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


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


def candidates_windows():
    paths = []
    for base in filter(None, [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]):
        paths.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
    return paths


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


def candidates_linux():
    cmds = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    found = [which(c) for c in cmds if which(c)]
    return [p for p in found if p]


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

    if 'windows' in system:
        for p in candidates_windows():
            if os.path.exists(p):
                out = run_cmd([p, '--version'])
                v = parse_version(out)
                if v:
                    return p, v, out
        return None, None, ''

    if 'darwin' in system:
        for p in candidates_macos():
            if os.path.exists(p):
                out = run_cmd([p, '--version'])
                v = parse_version(out)
                if v:
                    return p, v, out
        return None, None, ''

    # Linux / other Unix-like
    for p in candidates_linux():
        out = run_cmd([p, '--version'])
        v = parse_version(out)
        if v:
            return p, v, out
    return None, None, ''


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


def main():
    path, version, raw = get_version()

    if not version:
        print('UNKNOWN: Google Chrome version could not be determined on this host')
        sys.exit(2)

    if cmp_version(version, FIXED) < 0:
        print(f'VULNERABLE: detected Chrome {version[0]}.{version[1]}.{version[2]}.{version[3]} at {path}; fixed is {FIXED[0]}.{FIXED[1]}.{FIXED[2]}.{FIXED[3]} or later')
        sys.exit(1)

    print(f'PATCHED: detected Chrome {version[0]}.{version[1]}.{version[2]}.{version[3]} at {path}; fixed baseline is {FIXED[0]}.{FIXED[1]}.{FIXED[2]}.{FIXED[3]}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a HIGH browser bug with meaningful impact but real exploit-chain friction: first, pull an endpoint inventory for Chrome versions and isolate any business units that cannot confirm they are at 149.0.7827.53+; second, if patching is delayed anywhere, enforce relaunch/auto-update and apply any temporary WebGL or browsing-isolation restrictions for those lagging populations within the noisgate mitigation SLA of 30 days. Then finish the actual browser version rollout fleet-wide within the noisgate remediation SLA of 180 days—and realistically much sooner, because browsers are one of the few places where slow patch cadence is self-inflicted pain.

Sources

  1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases homepage
  3. Chrome Early Stable release process
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. Chromium Security - Core Principles
  7. Chromium Security - Site Isolation
  8. TechSpot Chrome 149 release notes aggregation
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.