CVE-2026-10923 · Google Chrome on Android WebAppInstalls use-after-free code execution

01 · The Real Story

This is a sharp blade left inside the app, not a front-door key to the enterprise

CVE-2026-10923 is a use-after-free in Chrome's WebAppInstalls component on Android, affecting versions before 149.0.7827.53. Per the published CVE record, exploitation requires a local attacker and a malicious file, with the outcome being arbitrary code execution in Chrome's context on the device.

Chromium tags the bug High internally, which is fair from a pure memory-corruption standpoint, but in enterprise reality this lands lower. The decisive friction is the attacker position: this is not unauthenticated remote web exploitation, it is post-delivery / local-on-device abuse on one platform, and Chrome's sandbox further limits blast radius unless the attacker already has another bug or an existing foothold.

"Local attacker plus malicious file on Android Chrome is real risk, but it is not a fleet-wide fire drill"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Get local position on the Android device

The attacker first needs a way to operate locally on the target handset or tablet, or at minimum to place attacker-controlled content where Chrome can access it. In practice that means prior compromise, physical access, malicious app presence, adb access, or a user-mediated file transfer path. Weaponized tooling: adb, sideloaded helper app, or Android share/intent delivery.

Conditions required:

Target runs Chrome on Android below 149.0.7827.53
Attacker can place a file on the device or otherwise act locally
Chrome is installed and usable on the device

Where this breaks in practice:

This is not reachable by generic internet scanning
Requires a prior stage: physical access, malware, or successful social engineering
Enterprise Android fleets often restrict sideloading, adb, and unmanaged file transfer

Detection/coverage: No network scanner will find this. Coverage comes from MDM inventory for Chrome version, Android policy telemetry for sideloading/USB debugging, and EDR/mobile threat defense if deployed.

STEP 02

Trigger Chrome's vulnerable file-handling path

The attacker must get Chrome into the specific WebAppInstalls code path using a crafted malicious file. Because the bug details remain restricted, the exact trigger format is not public, which raises attacker engineering cost even if the primitive is memory corruption. Weaponized tooling: crafted file plus Android Intent/Sharesheet or direct file open in Chrome.

Conditions required:

A valid trigger file exists
The target opens or passes the file to Chrome
The device is still on a vulnerable build

Where this breaks in practice:

No public PoC was found in the reviewed sources
Bug details are still restricted by Chromium
User interaction or local process orchestration is likely required

Detection/coverage: Expect weak pre-exploit detection. Useful signals are unusual Chrome launches on local files, MTD alerts on suspicious file delivery, and Chrome crash spikes after file open attempts.

STEP 03

Exploit the use-after-free for code execution inside Chrome

If the crafted file reliably exercises the dangling-pointer state, the attacker can attempt controlled memory reuse and arbitrary code execution in the browser's process context. This is serious, but it is still Chrome-process compromise, not automatic full-device takeover. Weaponized tooling: custom exploit chain targeting Android Chrome memory layout.

Conditions required:

The UAF is reachable and exploitable on the target build
Exploit reliability works across the device/ABI mix
Chrome's hardening does not crash the process first

Where this breaks in practice:

Modern Chrome has substantial exploit mitigations and crash-hardening
Android fragmentation hurts reliability across OEM builds and chipsets
Memory corruption without public primitives usually takes real exploit development

Detection/coverage: Mobile crash telemetry, Play Protect, and device-side behavioral monitoring may catch failed attempts. Traditional perimeter controls will not.

STEP 04

Try to turn app compromise into business impact

Post-exploitation, the attacker is constrained by Chrome's sandbox and Android app isolation. To get durable device compromise, broader data access, or privilege escalation, they likely need a second bug or already elevated local position. Weaponized tooling: chained sandbox escape, local privilege escalation, or credential/session abuse from the browser context.

Conditions required:

Useful enterprise data is reachable from the compromised browser context
A second-stage escape or abuse path exists
The target device stores valuable sessions or tokens in reachable scope

Where this breaks in practice:

Sandboxing sharply limits immediate blast radius
Per-device impact dominates; this is not a one-shot server compromise
Managed-work-profile separation can further reduce reachable enterprise data

Detection/coverage: Detection shifts to post-exploitation signals: suspicious token use, impossible-travel auth events, new app installs, privilege escalation artifacts, and anomalous device posture changes.

03 · Compensating Control

Inventory Android Chrome versions — Pull device/app version data from MDM, EMM, or managed Google Play and isolate any device below 149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA, so use this as normal remediation planning and complete patch validation within the 365-day remediation window.

Lock down sideloading and USB debugging — Reduce the easiest local-attack paths by disabling unknown sources, restricting adb/USB debugging, and enforcing app install policy on corporate Android devices. This is the highest-value friction point because the exploit starts with local file placement; keep the policy in force while devices move through the 365-day remediation window.

Prefer managed Play auto-update enforcement — Ensure Chrome auto-updates are not deferred for Android work devices and that update rings are not pinning vulnerable builds. For MEDIUM, there is no separate mitigation deadline, so this is a straightforward patch hygiene action to keep remediation inside the 365-day window.

Watch for suspicious local-file abuse in Chrome — If you run mobile threat defense or Android telemetry, alert on unusual Chrome launches from downloads, file managers, or untrusted apps. This will not prevent exploitation by itself, but it can surface the prerequisite local-delivery stage during the 365-day remediation period.

What doesn't work

Perimeter firewalls and external attack-surface scanners do nothing here because the target is a client-side Android browser path, not an exposed service.
WAF controls do nothing here because the trigger is described as a malicious file used by a local attacker, not a server-side HTTP parsing flaw.
Desktop Chrome patching alone is irrelevant because the CVE record is explicitly scoped to Chrome on Android.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence of active exploitation was found in the reviewed sources, and the CVE is not listed in CISA KEV.
Proof-of-concept availability	No public PoC located. The Chromium issue remains restricted, which materially slows copycat exploitation.
EPSS	EPSS provided in the case data is 0.00009, which is effectively background noise for near-term exploitation risk; exact percentile was not confirmed from the source set.
KEV status	No. No CISA KEV entry identified for `CVE-2026-10923`.
Vendor/CNA severity	The CVE JSON states "Chromium security severity: High" even though there is no published CVSS score/vector.
Affected versions	Google Chrome on Android < 149.0.7827.53.
Fixed version	Update to 149.0.7827.53 or later on Android. Later stable respins also inherit the fix.
Exposure and scanning reality	This is a client-side Android browser bug, not an internet-facing service. Shodan/Censys/FOFA-style exposure counting is largely irrelevant; your exposure inventory must come from MDM / managed Google Play / EMM version data.
Disclosure timeline	Reserved 2026-06-04, published 2026-06-04 in the official CVE record; Chromium release notes list the issue in the Chrome 149 security fixes published 2026-06-02.
Reporter	Reported by Google on 2026-04-04, per Chrome release notes.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (4.4/10)

Why this verdict

Local-only prerequisite cuts the population hard: this is not unauthenticated remote exploitation from the internet; it assumes the attacker already has device access or another delivery foothold.
Malicious-file trigger adds another gate: the attacker needs file placement and likely user or local-process interaction to reach the vulnerable path, which is materially harder than a drive-by web page.
Android-only scope narrows enterprise blast radius: even in Chrome-heavy estates, only the Android slice is affected, and impact is primarily per-device rather than a central service compromise.
No public exploitation signal: no KEV entry, no public PoC found, and a near-zero EPSS all argue against urgent weaponization pressure.
Sandboxing matters: arbitrary code execution in Chrome is serious, but on Android it does not automatically equal full device compromise without a second-stage escape or abuse path.

Why not higher?

A higher rating would fit a remotely reachable browser RCE with a public PoC or active exploitation, especially one triggered by a malicious page with no local foothold requirement. That is not what this record says: it explicitly requires a local attacker and a malicious file, and the remaining details are still restricted.

Why not lower?

It should not be pushed to LOW because it is still a memory-corruption code-execution bug in a massively deployed browser component. If an attacker already has local presence on a managed Android device, this can become a useful privilege-expanding pivot inside a real intrusion chain.

06 · Verification

Crowdsourced verification payload.

Run this from an auditor workstation with Android Platform Tools (adb) installed, not on the device itself. Invoke it as ./check_cve_2026_10923.sh SERIAL1234 or ANDROID_SERIAL=SERIAL1234 ./check_cve_2026_10923.sh; it needs adb access to the target device but does not require root.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_10923.sh
# Verify whether Google Chrome on an Android device is vulnerable to CVE-2026-10923
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

PKG="com.android.chrome"
FIXED_VERSION="149.0.7827.53"
SERIAL="${1:-${ANDROID_SERIAL:-}}"

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

fail_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

version_ge() {
  # returns 0 if $1 >= $2
  local a b i
  IFS='.' read -r -a a <<< "$1"
  IFS='.' read -r -a b <<< "$2"
  for ((i=${#a[@]}; i<4; i++)); do a[i]=0; done
  for ((i=${#b[@]}; i<4; i++)); do b[i]=0; done
  for i in 0 1 2 3; 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
}

command -v adb >/dev/null 2>&1 || fail_unknown "adb not found in PATH"

state="$(${adb_cmd[@]} get-state 2>/dev/null || true)"
[[ "$state" == "device" ]] || fail_unknown "no reachable adb device"

pkg_info="$(${adb_cmd[@]} shell dumpsys package "$PKG" 2>/dev/null || true)"
[[ -n "$pkg_info" ]] || fail_unknown "package $PKG not found or inaccessible"

version_name="$(printf '%s\n' "$pkg_info" | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1)"
if [[ -z "$version_name" ]]; then
  version_name="$(${adb_cmd[@]} shell cmd package list packages --show-versioncode "$PKG" 2>/dev/null | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1 || true)"
fi

[[ -n "$version_name" ]] || fail_unknown "could not determine Chrome version"

# Normalize potential suffixes (e.g. 149.0.7827.53-beta -> 149.0.7827.53)
normalized="$(printf '%s' "$version_name" | sed 's/[^0-9.].*$//')"
[[ -n "$normalized" ]] || fail_unknown "unable to normalize version string: $version_name"

if version_ge "$normalized" "$FIXED_VERSION"; then
  echo "PATCHED: $PKG version $version_name on device meets or exceeds fixed version $FIXED_VERSION"
  exit 0
else
  echo "VULNERABLE: $PKG version $version_name on device is below fixed version $FIXED_VERSION"
  exit 1
fi