CVE-2026-10953 · Google Chrome on Android Core use-after-free sandbox escape

01 · The Real Story

This is a lockpick hidden behind another locked door

CVE-2026-10953 is a use-after-free in Chrome Core affecting Google Chrome on Android before 149.0.7827.53. In practical terms, the bug matters only after an attacker has already compromised the renderer process, then uses a crafted HTML page to try to break out of Chrome's sandbox. Google’s Android stable rollout on June 2, 2026 shipped Chrome 149.0.7827.59 and explicitly states Android carries the same security fixes as desktop 149.0.7827.53/54.

Google's HIGH 8.3 label is fair in a lab chain, but too hot for enterprise patch triage by itself. The decisive friction is the prerequisite: the attacker must already own the renderer, which makes this a post-initial-execution sandbox escape, not an internet-reachable first-hop compromise; add low EPSS, no KEV entry, no public exploitation evidence, and no public PoC, and this lands lower in a real 10,000-device queue.

"Dangerous only as a second-stage Chrome-on-Android chain piece, not a stand-alone fleet emergency"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code execution in the renderer first

The attacker still needs a separate browser bug, exploit chain, or equivalent path to gain execution inside Chrome's renderer process on Android. CVE-2026-10953 does not provide that first foothold; it only becomes useful after the renderer is already compromised. In practice this means a malicious page alone is insufficient unless paired with another flaw or exploit primitive.

Conditions required:

Victim uses vulnerable Chrome on Android
Victim visits attacker-controlled content
Attacker has a separate renderer-compromise bug or chain

Where this breaks in practice:

This is a second-stage requirement, not initial access
Modern Safe Browsing, site isolation, and exploit mitigations increase failure rate of the first-stage chain
Attackers must carry at least two working bugs, not one

Detection/coverage: Version scanners cannot see this stage directly. Detection is mostly indirect through web filtering, threat intel on exploit chains, crash telemetry, or mobile EDR/browser telemetry if present.

STEP 02

Trigger the Core use-after-free from the compromised renderer

Once the renderer is compromised, the attacker drives the vulnerable Core code path with crafted HTML to hit stale memory and corrupt execution flow. The intended outcome is to pivot from the low-privilege renderer into a more privileged context. Because this is a memory-corruption path, exploit reliability depends on allocator behavior, build details, and mitigation bypasses.

Conditions required:

Renderer compromise already achieved
Target is running an affected Chrome build
Attacker can reach the vulnerable Core path with controlled page content

Where this breaks in practice:

Use-after-free exploitation is notoriously reliability-sensitive on mobile
Chrome and Android hardening reduce stability of generic weaponization
Issue details are still restricted, so copycat weaponization is not trivial

Detection/coverage: Runtime detection is weak. Most defenders can only infer exposure by version; successful exploitation may leave only crashes, abnormal renderer exits, or follow-on behavior.

STEP 03

Attempt the sandbox escape

If memory corruption is steered correctly, the attacker may escape the renderer sandbox and gain execution in a higher-privilege browser process. That is the real security boundary at stake here. For an exploit developer this is valuable, but only as the middle link in a larger chain.

Conditions required:

A working exploit primitive from the use-after-free
Ability to bypass Chrome process isolation and sandbox protections
Target-specific exploit reliability on Android

Where this breaks in practice:

Sandbox escapes are harder than same-process renderer RCE
Android-specific process and SELinux boundaries further constrain post-escape options
Mobile EDR and OS crash reporting may expose unstable attempts

Detection/coverage: No commodity scanner can validate exploitability here. Detection comes from anomaly telemetry, crash spikes, forensic artifacts, or discovery of a full exploit chain.

STEP 04

Turn browser escape into useful impact

Post-escape, the attacker can try to access data or capabilities outside the renderer's normal confinement and potentially support broader compromise goals. On Android, however, a browser sandbox escape is still not the same as device root; further privilege boundaries remain. The business risk is strongest for high-risk users where browser compromise is a realistic initial vector.

Conditions required:

Successful sandbox escape
Meaningful post-escape objective such as data theft or chaining into another local boundary
Victim workflow exposes valuable browser-resident data or tokens

Where this breaks in practice:

Android app sandboxing still limits blast radius compared with desktop kernel-level compromise
Many enterprises have limited sensitive data resident in mobile Chrome
High-value follow-on impact often needs yet another local or OS-level weakness

Detection/coverage: Impact-stage detection depends on the follow-on payload: token abuse, credential theft, abnormal network traffic, or suspicious app/process behavior.

03 · Compensating Control

Force Chrome auto-update on managed Android — Push managed Google Play auto-update enforcement and verify devices move to a fixed Chrome build. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the remediation window, so use this as the primary control while ensuring patch completion within 365 days.

Prioritize high-risk mobile user groups — Apply accelerated update verification for executives, admins, researchers, and users routinely targeted by web-delivered exploits. There is no mitigation SLA at this severity, but these cohorts deserve earlier internal priority because a sandbox escape is most valuable in targeted chains; still complete broad remediation within 365 days.

Keep Safe Browsing and Play Protect enforced — These controls do not fix the bug, but they raise the cost of delivering the first-stage renderer compromise that this CVE depends on. Treat them as hardening rather than mitigation; no mitigation SLA applies, and the real requirement remains patching Chrome within 365 days.

Use MDM compliance to quarantine stale Chrome builds — Inventory com.android.chrome versions and flag devices below the fixed threshold for follow-up or conditional access pressure. This is the only scalable way to manage exposure for a client-side mobile browser issue; no mitigation SLA applies, but remediation should still close within 365 days.

What doesn't work

A WAF does not help; this is a client-side browser flaw, not a web app vulnerability on your servers.
Perimeter scanning does not help; there is no internet-facing service banner to find, so Shodan-style workflows miss the problem entirely.
MFA does not stop exploitation of the browser memory bug itself; it only limits some downstream account abuse after compromise.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence of active exploitation located as of 2026-06-05; the CVE is not KEV-listed.
PoC availability	No public PoC found in the official references or GHSA entry; Chromium issue details remain restricted.
EPSS	0.068% (21st percentile) per the GHSA/FIRST data point — low predictive pressure compared with routinely weaponized browser bugs.
KEV status	Not listed in CISA KEV; no date added because there is no catalog entry for this CVE.
CVSS and meaning	`CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H` = remote delivery is possible, but exploitation is high complexity, needs user interaction, and in reality also depends on a prior renderer compromise.
Affected versions	Chrome on Android <149.0.7827.53 per the CVE text.
Fixed versions	Security fix threshold is 149.0.7827.53 in the CVE record; Google’s Android stable rollout on 2026-06-02 shipped 149.0.7827.59 carrying the same security fixes as desktop 149.0.7827.53/54.
Exposure reality	This is a client-side browser flaw, not an externally exposed server service. Shodan/Censys/FOFA exposure is effectively not applicable; exposure must be measured through MDM/EPM inventory, not internet scanning.
Disclosure timeline	NVD shows the CVE record published on 2026-06-04; GHSA published on 2026-06-05; Chrome stable Android fix shipped on 2026-06-02.
Reporter	Reported by Google to Chromium on 2026-04-24; no external researcher credit is listed in the release notes.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (6.2/10)

Why this verdict

Renderer compromise required: -1.7 This is not initial access. Requiring a compromised renderer implies the attacker has already landed a separate browser exploit stage, which is compounding friction in real operations.
Client-side mobile population only: -0.3 The affected population is broad in theory, but only among Android Chrome clients; there is no server-side blast radius and no externally reachable enterprise service to mass-scan or mass-exploit.
No current exploitation pressure: -0.1 No KEV listing, low EPSS, restricted bug details, and no public PoC reduce immediate weaponization likelihood compared with browser zero-days that are already burning.

Why not higher?

If this were a stand-alone renderer RCE or had confirmed in-the-wild exploitation, it would stay in HIGH without much debate. But a sandbox escape that explicitly requires prior renderer compromise is a chain component, and enterprise prioritization should score chain friction, not just theoretical end-state impact.

Why not lower?

This is still a sandbox escape in Chrome, and that boundary matters. In the hands of a capable actor with a paired renderer bug, the impact can be serious for targeted users, so writing it off as backlog-only hygiene would understate the risk.

06 · Verification

Crowdsourced verification payload.

Run this on an auditor workstation with adb installed against a connected Android device, or through a remote shell workflow that exposes package metadata. Invoke it as ./check_cve_2026_10953.sh SERIAL or ./check_cve_2026_10953.sh for the only attached device; no root is required, but you do need USB debugging or an enterprise-approved shell channel.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_10953.sh
# Verify whether Google Chrome on Android is below the fix level for CVE-2026-10953.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_SERIAL="${1:-}"
PACKAGE="com.android.chrome"
MIN_SAFE="149.0.7827.53"

adb_cmd=(adb)
if [[ -n "$TARGET_SERIAL" ]]; then
  adb_cmd+=( -s "$TARGET_SERIAL" )
fi

version_ge() {
  # returns 0 if $1 >= $2
  local IFS=.
  local i
  local -a a=($1) b=($2)
  local len=${#a[@]}
  if (( ${#b[@]} > 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 0
}

if ! command -v adb >/dev/null 2>&1; then
  echo "UNKNOWN: adb not found in PATH"
  exit 2
fi

if ! "${adb_cmd[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: no reachable Android device/emulator via adb"
  exit 2
fi

pkg_out=$("${adb_cmd[@]}" shell dumpsys package "$PACKAGE" 2>/dev/null)
if [[ -z "$pkg_out" ]]; then
  echo "UNKNOWN: package $PACKAGE not found or dumpsys unavailable"
  exit 2
fi

version=$(printf '%s
' "$pkg_out" | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1 | tr -d '\r')
if [[ -z "$version" ]]; then
  version=$("${adb_cmd[@]}" shell cmd package list packages -f "$PACKAGE" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1)
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN: could not determine Chrome version"
  exit 2
fi

if version_ge "$version" "$MIN_SAFE"; then
  echo "PATCHED: $PACKAGE version $version >= $MIN_SAFE"
  exit 0
else
  echo "VULNERABLE: $PACKAGE version $version < $MIN_SAFE"
  exit 1
fi