This is a second lock behind a first broken door, dangerous in a full break-in but rarely the thing that gets opened first
The authoritative record matching your description appears to be CVE-2026-11256, not CVE-2026-11085. It is an integer overflow in the GPU component of Google Chrome on Android affecting versions before 149.0.7827.53. The key detail is the one that changes everything operationally: the attacker must have already compromised the renderer process and then use a crafted HTML page to try to turn that foothold into a sandbox escape.
Your supplied HIGH 8.8 framing overstates the real enterprise urgency. The vendor language says Chromium security severity: Low, and while CISA-ADP later attached a high CVSS-style score, that numeric model still treats the bug too much like a first-hop remote compromise. In the real world this is a post-renderer-compromise chain element on Android only, with no KEV listing, no public exploitation evidence, and extremely low EPSS, so the right move is to downgrade it to a routine browser-update priority rather than a fleet-wide fire drill.
4 steps from start to impact.
Land a renderer foothold with a separate browser bug
- Victim uses vulnerable Chrome on Android prior to 149.0.7827.53
- Victim is lured to attacker-controlled content
- Attacker has a separate renderer-compromise primitive
- Requires a second vulnerability or pre-existing compromise before this CVE matters
- Modern Safe Browsing, site isolation, and renderer hardening raise the bar for the prerequisite stage
- No public PoC or exploit chain was found for this specific issue
Trigger the GPU integer overflow from crafted web content
- Renderer process is already controlled or materially compromised
- GPU code path is reachable on the target device and build
- The specific vulnerable code path is still present in the installed version
- Exploit reliability on Android GPU paths is often device/build sensitive
- Chrome bug details are still restricted, limiting commodity weaponization
- Attack complexity is reflected as high by ADP
Turn browser-component memory corruption into sandbox escape
- Precise memory corruption control sufficient for exploitation, not just crash
- Target device/browser mitigations can be bypassed
- Browser sandbox boundaries remain the next reachable privilege tier
- Many memory bugs crash far more often than they cleanly escape sandbox
- Exploit must survive modern mitigations and Android variance
- Impact is significant only if the attacker already solved stage one
Use the escaped context for follow-on abuse
- Sandbox escape succeeded
- There is valuable enterprise data in browser/session context
- Additional controls such as app isolation or MDM policies do not blunt impact
- Blast radius is limited to Android Chrome users, not your server estate
- Many enterprises keep mobile browsers low-privilege and containerized
- No evidence this CVE is being operationalized in the wild today
com.android.chrome mandatory and verify update deferrals are not pinning devices below 149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control is low-cost and should be implemented during the next routine mobile policy review.149.0.7827.53; for MEDIUM, there is no mitigation SLA, so use this to drive orderly remediation inside the 365-day window.- A network IDS signature will not save you here; the exploit would ride normal web content and the decisive stage is client-side memory corruption.
- External attack-surface scanners like Shodan/Censys are basically irrelevant; this is not a remotely fingerprintable listener.
- WAF rules do not meaningfully help because the victim is the browser engine, not your web server.
The supporting signals.
| Record sanity check | The description you supplied matches CVE-2026-11256, not CVE-2026-11085. I assessed the authoritative record matching the description. |
|---|---|
| In-the-wild status | No current exploitation evidence found and not KEV-listed in the CISA catalog. |
| PoC availability | No public PoC found. The Chromium bug reference is still restricted: issues.chromium.org/issues/498856565. That meaningfully slows commodity weaponization. |
| EPSS | 0.00068 probability, 0.211 percentile on 2026-06-05 via CVE.report's FIRST-fed aggregation. That's effectively background noise, not an exploitation magnet. |
| KEV status | No. As of the current CISA KEV catalog, this issue is absent. |
| CVSS reality check | ADP shows 8.3 / CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H on NVD, but the practical hidden prerequisite is renderer already compromised. That is major downward pressure in real fleets. |
| Affected versions | Google Chrome on Android before 149.0.7827.53 per NVD. |
| Fixed version | Update to 149.0.7827.53 or later. Chrome Android stable updates are distributed via Google Play; Chrome release notes show Android 149 rollout on May 28, 2026. |
| Vendor-vs-ADP severity | Vendor text says 'Chromium security severity: Low' on NVD, while CISA-ADP later attached a HIGH 8.3 vector. For patch triage, the vendor's *chain-element* framing is closer to reality. |
| Scanning / exposure data | Not Shodan/Censys/GreyNoise-friendly. This is a client-side mobile-browser bug, not an internet-listenable service. Exposure measurement is an asset inventory / app-version problem, not an external-attack-surface problem. |
Sources.
- NVD detail for the authoritative matching record
- Chrome Early Stable desktop update 149.0.7827.53/.54
- Chrome for Android update 149.0.7827.48 rollout
- Chromium issue tracker reference for this bug
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS project overview
- CVE.report aggregation including EPSS snapshot
Why this verdict
- Requires prior compromise: an attacker must already control or materially compromise the renderer process before this CVE does anything useful.
- Android-only population: this is not your Windows/Mac/Linux browser fleet; it is a narrower mobile subset with smaller enterprise blast radius.
- No live-fire intel: no KEV listing, no public exploitation evidence, and a near-floor EPSS score argue against emergency treatment.
- Version exposure is common, exploitability is not: lots of devices may be behind on Chrome, but very few real attackers can chain a renderer bug plus a reliable Android GPU sandbox escape.
Why not higher?
This is not a stand-alone drive-by RCE from the open internet. The attack path assumes a prior renderer break, plus reliable exploitation of a GPU memory bug on Android, plus successful sandbox escape. Each prerequisite sharply narrows the number of attackers and targets that can operationalize it.
Why not lower?
It is still a memory-corruption bug in a massively deployed browser component, and its intended end state is a sandbox escape. If you operate a large managed Android fleet, especially with sensitive browser-based workflows, this is worth fixing through normal browser-update discipline rather than treating it as pure backlog trivia.
Crowdsourced verification payload.
Run this on an auditor workstation with Android platform-tools (adb) installed, targeting a managed Android device with USB debugging or enterprise ADB access enabled. Invoke it as ./check_chrome_android.sh <device-serial> for a specific device or ./check_chrome_android.sh when only one device is attached; no root is required on the phone, but you need permission to query package metadata over ADB.
#!/usr/bin/env bash
# check_chrome_android.sh
# Verifies whether Google Chrome on an attached Android device is below 149.0.7827.53.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
FIXED_VERSION="149.0.7827.53"
PACKAGE="com.android.chrome"
SERIAL="${1:-}"
adb_cmd() {
if [ -n "$SERIAL" ]; then
adb -s "$SERIAL" "$@"
else
adb "$@"
fi
}
version_lt() {
# returns 0 if $1 < $2
local IFS=.
local i
local -a a=($1) b=($2)
local len=${#a[@]}
if [ ${#b[@]} -gt $len ]; then len=${#b[@]}; fi
for ((i=0; i<len; i++)); do
local ai=${a[i]:-0}
local bi=${b[i]:-0}
if ((10#$ai < 10#$bi)); then
return 0
elif ((10#$ai > 10#$bi)); then
return 1
fi
done
return 1
}
# Basic device check
if ! adb_cmd get-state >/dev/null 2>&1; then
echo "UNKNOWN - no accessible Android device via adb"
exit 2
fi
# Try several methods because OEM builds differ
VERSION="$(adb_cmd shell dumpsys package "$PACKAGE" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n1)"
if [ -z "$VERSION" ]; then
VERSION="$(adb_cmd shell cmd package list packages -f "$PACKAGE" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n1)"
fi
if [ -z "$VERSION" ]; then
VERSION="$(adb_cmd shell pm dump "$PACKAGE" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n1)"
fi
if [ -z "$VERSION" ]; then
# Final fallback: try package manager path presence to distinguish absent vs unreadable
if adb_cmd shell pm path "$PACKAGE" >/dev/null 2>&1; then
echo "UNKNOWN - Chrome installed but version could not be read"
else
echo "UNKNOWN - Chrome is not installed or package metadata is inaccessible"
fi
exit 2
fi
if version_lt "$VERSION" "$FIXED_VERSION"; then
echo "VULNERABLE - $PACKAGE version $VERSION is below fixed $FIXED_VERSION"
exit 1
else
echo "PATCHED - $PACKAGE version $VERSION is at or above fixed $FIXED_VERSION"
exit 0
fi