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.
4 steps from start to impact.
Land the user on an exploit page
- Victim uses vulnerable Chrome prior to 149.0.7827.53
- Victim visits attacker-controlled or attacker-compromised content
- Rendering path reaches ANGLE-relevant code
- 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
Trigger ANGLE memory corruption
- 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
- 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
Convert corruption into a sandbox boundary break
- 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
- 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
Execute follow-on payload in user context
- 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
- 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
The supporting signals.
| In-the-wild status | No public active-exploitation statement verified, and not KEV-listed as of 2026-06-04. |
|---|---|
| Public PoC status | I 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. |
| EPSS | No 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 status | CISA Known Exploited Vulnerabilities catalog: not listed. |
| CVSS vector meaning | CVSS: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 versions | Supplied 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 versions | Patch 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 reality | There 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 date | 2026-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 / researcher | Not publicly attributable from the sources I could verify; Chrome bug references appear to still be under normal disclosure restriction. |
noisgate verdict.
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.
Why this verdict
- Downgrade from vendor 9.6: remote and dangerous, but still gated by
UI:Rand 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.
What to do — in priority order.
- 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.
- 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.
- 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.
- Alert on browser-child process abuse — Tune EDR detections for
chromespawning 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.
- 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.
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.
#!/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()
If you remember one thing.
Sources
- Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases homepage
- Chrome Early Stable release process
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- Chromium Security - Core Principles
- Chromium Security - Site Isolation
- TechSpot Chrome 149 release notes aggregation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.