This is a second lock failing after the burglar is already inside the lobby
CVE-2026-10929 is a heap buffer overflow in ANGLE, Chrome's graphics translation layer used to service WebGL/OpenGL ES work. In practice, this sits on the path between a compromised renderer and the less-restricted GPU/browser side of Chrome on Android. The user-supplied intel says affected versions are Google Chrome on Android prior to 149.0.7827.53; Google's June 2, 2026 Android stable release was 149.0.7827.59, and Google states Android carries the same security fixes as the corresponding desktop 149.0.7827.53/54 release unless otherwise noted.
Google's HIGH 8.3 label is technically fair in isolation because memory corruption in a graphics boundary is exactly the kind of bug that can become sandbox escape material. But for enterprise patch prioritization, the real-world story is narrower: this bug does not give an unauthenticated remote attacker code execution by itself; it assumes the attacker has already compromised the renderer. That turns this from front-door browser RCE into a post-compromise chain component, which is why the vendor score overstates the immediate fleet-wide urgency.
4 steps from start to impact.
Deliver a renderer foothold
V8/Blink/WebAssembly memory corruption, or another browser bug that lands code execution inside the sandboxed renderer after the user visits a malicious page. CVE-2026-10929 is not that first-stage bug.- User visits attacker-controlled content in Chrome on Android
- Attacker has a separate working renderer-compromise primitive
- This prerequisite already assumes a successful prior exploit stage
- Modern Safe Browsing, site isolation, and exploit mitigations reduce reliable first-stage delivery
- No public exploit chain for this CVE was found in the consulted source set
Abuse WebGL/ANGLE command flow
WebGL / GLES operations that are serialized through Chrome's command buffer toward ANGLE. Chromium's design docs show the renderer cannot call 3D APIs directly; it must hand work to the GPU path, which is exactly where this bug class becomes interesting.- Renderer code execution or arbitrary control over renderer-side graphics calls
- Target page can access graphics functionality used by ANGLE
- Exploit reliability depends on target GPU/driver/backend behavior
- ANGLE bugs can be finicky across device models and Android builds
- Attack complexity is already rated high in the supplied CVSS
Trigger heap corruption in ANGLE
ANGLE, causing an overflow. The security value of that primitive is not the crash itself; it is the chance to corrupt memory on the other side of the renderer boundary and pivot execution into a less-restricted context.- Vulnerable Chrome for Android build present
- Exploit primitive aligns with the target device's memory layout and graphics stack
- Google often withholds bug details until broad patch uptake, so public exploit development is slowed
- Heap overflows are not automatically weaponizable into stable code execution
- Android model fragmentation hurts reliability at scale
Escape renderer constraints into Chrome app context
isolated_app, while un-sandboxed helper processes such as GPU run under untrusted_app with the same UID as the browser process. That means a successful exploit can materially widen access from a tightly sandboxed renderer into the broader Chrome app context, which is meaningful but still not equivalent to full device compromise.- Successful memory corruption exploitation, not just crash
- Ability to pivot into GPU/browser-side execution
- Impact is bounded by the Android app sandbox unless chained again
- This is still a browser-app compromise, not a turnkey OS takeover
- Further privilege escalation would require another bug
com.android.chrome from your EMM/MDM and identify devices pinned behind Play updates, kiosk modes, or user-disabled updates. For this verdict there is no mitigation SLA, so the operational job is accurate scoping and patch completion within the remediation window.- Perimeter vulnerability scanning doesn't help because this is not a remotely discoverable server; there is nothing meaningful for Shodan-style discovery to find.
- WAF rules don't help because exploitation happens inside the client browser's graphics path, not against a web application you control.
- Email gateway blocking alone doesn't solve it because the hard prerequisite is a browser renderer foothold from any delivery path, not just email.
The supporting signals.
| In-the-wild status | No public in-the-wild exploitation evidence was found in the consulted source set, and CISA KEV does not list this CVE. |
|---|---|
| Proof-of-concept availability | No public PoC or exploit repo for CVE-2026-10929 was found in the consulted source set. Google also notes Chrome bug details may stay restricted until most users are patched. |
| EPSS | 0.00062 per the user-supplied intel — extremely low predicted near-term exploitation probability, consistent with a chain-only browser bug rather than a mass-exploited edge service. |
| KEV status | Not KEV-listed. That removes the biggest upward pressure we usually apply to browser bugs. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the important parts are AC:H and UI:R. More importantly than either, the narrative explicitly says the attacker had compromised the renderer. |
| Affected versions | User-supplied intel says Chrome on Android prior to 149.0.7827.53. Google shipped Android stable as 149.0.7827.59 on 2026-06-02, stating Android carries the same corresponding desktop security fixes unless otherwise noted. |
| Fixed version | Treat Chrome for Android 149.0.7827.59 or later as the practical patched baseline for managed-device checks. |
| Scanning / exposure data | Internet scanning sources like Shodan/Censys/FOFA are not useful here because this is a client-side mobile browser issue, not an externally exposed listening service. Your exposure data source is MDM/app inventory, not perimeter scan counts. |
| Disclosure timeline | User-supplied disclosure date: 2026-06-04. Chrome's 2026 release index shows CVE-2026-10929 was reported to Google on 2026-04-07 and fixed in the Chrome 149 stable train released on 2026-06-02. |
| Reporter / discovery source | Chrome's release index attributes this bug as reported by Google on 2026-04-07. |
Sources.
- Chrome Releases 2026 index (includes CVE-2026-10929 listing and Chrome 149 stable notes)
- Early Stable Update for Desktop 149.0.7827.53/.54
- Chrome Android sandbox design
- Chromium GPU process / command buffer architecture
- ANGLE project README
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- Canadian Centre for Cyber Security Chrome advisory for 149.0.7827.53/54 train
Why this verdict
- Renderer compromise prerequisite cuts the score down hard: this is not internet-to-RCE by itself; it is a post-renderer-compromise sandbox-boundary bug, so I discount the vendor's 8.3 baseline substantially.
- Android client-side population is real but not perimeter-exposed: you cannot mass-scan for this like VPNs, firewalls, or edge appliances; reachability depends on user browsing plus a separate first-stage exploit.
- No active exploitation pressure: no KEV listing, no public PoC found in the consulted sources, and the supplied EPSS 0.00062 is about as non-urgent as browser memory corruption gets.
- Impact is still meaningful once hit: Chromium documents that Android renderers run in
isolated_app, while unsandboxed GPU/browser-side components run with the browser app's UID, so a successful exploit can materially expand attacker rights inside Chrome.
Why not higher?
If this were a one-click remote code execution bug or there were credible evidence of active exploitation, it would move up fast. But the prerequisite chain is too restrictive: user interaction, high complexity, mobile-browser targeting, and an explicit need for prior renderer compromise all compound downward pressure.
Why not lower?
I am not calling this LOW because browser sandbox escapes still matter to real attackers, especially on widely deployed software like Chrome. Once an attacker has renderer execution, a working ANGLE overflow can widen access beyond the isolated renderer and become a valuable second-stage primitive in a full exploit chain.
Crowdsourced verification payload.
Run this on an auditor workstation with adb installed and an authorized Android device connected over USB or TCP/IP debugging. Invoke it as ./check_chrome_android.sh SERIAL_OR_TRANSPORT_ID or set ADB_SERIAL; no root is required on the device, but USB debugging authorization is required.
#!/usr/bin/env bash
# check_chrome_android.sh
# Determine whether Google Chrome on Android is patched for CVE-2026-10929.
# Practical fixed baseline: 149.0.7827.59 or later.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/environment error
set -u
PKG="com.android.chrome"
FIXED="149.0.7827.59"
SERIAL="${1:-${ADB_SERIAL:-}}"
fail() {
echo "UNKNOWN: $1"
exit 2
}
if ! command -v adb >/dev/null 2>&1; then
echo "UNKNOWN: adb not found in PATH"
exit 3
fi
ADB=(adb)
if [ -n "$SERIAL" ]; then
ADB+=( -s "$SERIAL" )
fi
if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
echo "UNKNOWN: adb device not available or not authorized"
exit 2
fi
version="$(("${ADB[@]}" shell dumpsys package "$PKG" 2>/dev/null || true) | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n 1)"
if [ -z "$version" ]; then
version="$(("${ADB[@]}" shell cmd package resolve-activity --brief "$PKG" 2>/dev/null || true) | tr -d '\r' >/dev/null; ("${ADB[@]}" shell pm dump "$PKG" 2>/dev/null || true) | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n 1)"
fi
if [ -z "$version" ]; then
echo "UNKNOWN: package $PKG not found or version could not be read"
exit 2
fi
normalize() {
local IFS=.
local parts=($1)
printf "%d.%d.%d.%d\n" \
"${parts[0]:-0}" "${parts[1]:-0}" "${parts[2]:-0}" "${parts[3]:-0}"
}
ver_lt() {
local a b IFS=.
read -r -a a <<<"$(normalize "$1")"
read -r -a b <<<"$(normalize "$2")"
for i in 0 1 2 3; do
if [ "${a[$i]}" -lt "${b[$i]}" ]; then
return 0
elif [ "${a[$i]}" -gt "${b[$i]}" ]; then
return 1
fi
done
return 1
}
if ver_lt "$version" "$FIXED"; then
echo "VULNERABLE: $PKG version $version is older than fixed baseline $FIXED"
exit 1
else
echo "PATCHED: $PKG version $version is at or above fixed baseline $FIXED"
exit 0
fi