In setupLayout of PickActivity

CVE-2026-0013 is a *local* Android elevation-of-privilege bug in DocumentsUI's PickActivity. Google says affected AOSP versions are Android 14, 15, and 16, and the fixing change clears a malicious Intent selector before the app reuses the incoming request. In plain English: a rogue app already running on the device can try to trick the system's file-picker app into launching an arbitrary activity *as DocumentsUI* instead of as the untrusted app.

The vendor's HIGH 8.4 score reflects the technical impact once an attacker is already on the handset, but it overstates enterprise urgency. The decisive friction is attacker position: this starts at AV:L, which means the adversary already has code execution on the device through a malicious app, sideload, or prior compromise. That makes this a useful *chain* bug for mobile malware, not a stand-alone fleet fire.

Why this verdict

• Downgrade for attacker position: vendor CVSS starts high because the impact is full local EoP, but AV:L means the attacker is already on the device. That is immediate downward pressure for enterprise prioritization.
• Downgrade for exposure population: this is reachable only on Android endpoints running affected DocumentsUI code, not on public-facing infrastructure. Real exposed population is far narrower than a browser, VPN, or mail gateway bug.
• Downgrade for controls that should break step 1: mobile app allow-listing, Play Protect, managed Play, MTD, and sideload restrictions can stop the prerequisite malicious app before this CVE matters.
• Hold at MEDIUM, not LOW: once a malicious app lands, exploitation appears low-complexity and needs no extra privileges or user interaction. That makes it a credible second-stage privilege escalator in mobile intrusion chains.
• Hold at MEDIUM because of enterprise data value: on high-value devices with SSO tokens, corporate mail, chat, and MDM enrollment, a local EoP can materially improve attacker access even if the blast radius is one device at a time.

Why not higher?

There is no internet-reachable entry point, no KEV listing, no confirmed active exploitation in the sources reviewed, and no public mass-weaponized PoC signal. Most importantly, AV:L implies the attacker has already crossed the hardest boundary by executing code on the endpoint.

Why not lower?

This is still a real privilege-boundary failure in a system component, not a cosmetic bug or lab-only edge case. If a hostile app is present, the exploit chain removes meaningful sandbox friction and can materially strengthen mobile malware operations against corporate data on the device.

1. Block untrusted app installs — Enforce managed Play allow-lists, disable unknown sources, and restrict developer-mode pathways because the prerequisite for this CVE is attacker-controlled code on the device. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control should already be baseline for Android fleet hygiene.
2. Harden mobile threat telemetry — Tune MTD/EDR/EMM to alert on sideloaded apps, low-prevalence packages, unexpected adb use, and suspicious launches into system components such as DocumentsUI. This does not patch the bug, but it raises the odds of catching the only realistic precondition before attackers can use the deputy flaw.
3. Segment high-risk Android cohorts — Prioritize executives, admins, developers, and users with broad SaaS/mobile access for update verification because the exploit is per-device and value-driven. On those cohorts, confirm both Android patch state and Google Play system update state rather than trusting one date string alone.
4. Reduce local code-exec paths — Turn off unnecessary adb in production, restrict test-signing exceptions, and review MDM policies that permit unmanaged app installs. This directly attacks the exploit chain's first step, which matters more than overreacting to the CVSS label.

Run this from an auditor workstation that has adb installed and USB debugging authorized on the target Android device. Invoke it as bash check-cve-2026-0013.sh SERIAL or omit the serial for a single attached device; no root is required, but adb shell access is required.

#!/usr/bin/env bash
# check-cve-2026-0013.sh
# Best-effort verifier for CVE-2026-0013 on Android devices via adb.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/adb error

set -u

SERIAL_ARG="${1:-}"
ADB_BASE=(adb)
if [[ -n "$SERIAL_ARG" ]]; then
  ADB_BASE+=( -s "$SERIAL_ARG" )
fi

run_adb() {
  "${ADB_BASE[@]}" "$@"
}

# Basic connectivity check
if ! run_adb get-state >/dev/null 2>&1; then
  echo "UNKNOWN: adb device not reachable"
  exit 3
fi

# Helper to trim CRs often returned by adb shell
trim() {
  tr -d '\r'
}

ANDROID_VERSION=$(run_adb shell getprop ro.build.version.release 2>/dev/null | trim)
SDK_INT=$(run_adb shell getprop ro.build.version.sdk 2>/dev/null | trim)
SEC_PATCH=$(run_adb shell getprop ro.build.version.security_patch 2>/dev/null | trim)
DOC_PKG=""

# Find likely DocumentsUI package name
for pkg in com.android.documentsui com.google.android.documentsui; do
  if run_adb shell pm path "$pkg" >/dev/null 2>&1; then
    DOC_PKG="$pkg"
    break
  fi
done

DOC_VER=""
if [[ -n "$DOC_PKG" ]]; then
  DOC_VER=$(run_adb shell dumpsys package "$DOC_PKG" 2>/dev/null | trim | awk -F= '/versionName=/{print $2; exit}')
fi

# Try to read a visible Google Play system update date from secure settings if present.
# This is not guaranteed across OEMs, so absence is normal.
GPSU_DATE=$(run_adb shell settings get secure "android_version_mainline" 2>/dev/null | trim)
if [[ "$GPSU_DATE" == "null" ]]; then
  GPSU_DATE=""
fi

# Normalize version gating from vendor advisory/NVD: Android 14, 15, 16 affected.
AFFECTED_OS=0
case "$ANDROID_VERSION" in
  14*|15*|16*) AFFECTED_OS=1 ;;
  *) AFFECTED_OS=0 ;;
esac

if [[ $AFFECTED_OS -eq 0 ]]; then
  echo "PATCHED: Android version '$ANDROID_VERSION' is outside the documented affected range (14/15/16)"
  exit 0
fi

# Best-effort patch decision:
# - If security patch level is >= 2026-03-01, treat as PATCHED.
# - Else if we cannot establish component patching, return UNKNOWN.
# - Else if affected OS and clearly pre-bulletin, return VULNERABLE.
# Note: This CVE sits in a Mainline-associated component, so security patch date alone is imperfect.

compare_dates() {
  # lexical compare works on YYYY-MM-DD
  local left="$1"
  local right="$2"
  [[ "$left" > "$right" || "$left" == "$right" ]]
}

TARGET_DATE="2026-03-01"

if [[ -n "$SEC_PATCH" ]]; then
  if compare_dates "$SEC_PATCH" "$TARGET_DATE"; then
    echo "PATCHED: security patch level '$SEC_PATCH' is at or after $TARGET_DATE; package='$DOC_PKG' version='${DOC_VER:-unknown}'"
    exit 0
  fi
fi

# If the device is in the affected OS family and clearly behind the bulletin date,
# call it vulnerable unless there is evidence of newer component delivery.
if [[ -n "$SEC_PATCH" && "$SEC_PATCH" < "$TARGET_DATE" ]]; then
  if [[ -n "$GPSU_DATE" ]]; then
    echo "UNKNOWN: security patch '$SEC_PATCH' is before $TARGET_DATE, but Google Play system update state '$GPSU_DATE' needs manual validation for Mainline-delivered DocumentsUI; package='$DOC_PKG' version='${DOC_VER:-unknown}'"
    exit 2
  else
    echo "VULNERABLE: affected Android version '$ANDROID_VERSION' with security patch '$SEC_PATCH' before $TARGET_DATE; package='$DOC_PKG' version='${DOC_VER:-unknown}'"
    exit 1
  fi
fi

# No usable patch signal beyond OS range.
echo "UNKNOWN: affected Android version '$ANDROID_VERSION'; unable to prove Mainline/DocumentsUI fix state. security_patch='${SEC_PATCH:-unknown}' package='$DOC_PKG' version='${DOC_VER:-unknown}' play_system='${GPSU_DATE:-unknown}'"
exit 2

Sources

1. Android Security Bulletin—March 2026
2. AOSP fix commit for DocumentsUI
3. NVD entry for CVE-2026-0013
4. OSV record for CVE-2026-0013
5. CWE-441 definition
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS API documentation
8. Android Enterprise system updates guidance