← Back to Feed CACHED · 2026-09-26 08:02:24 · CACHE_KEY CVE-2026-0013
CVE-2026-0013 · CWE-441 · Disclosed 2026-03-02

Android DocumentsUI PickActivity Confused Deputy Privilege Escalation

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like handing a forged letter to the king's courier — who delivers it because it looks official

CVE-2026-0013 is a confused deputy vulnerability in Android's DocumentsUI system app, specifically in the setupLayout method of PickActivity.java. The flaw allows a malicious application — already installed on the device — to craft an intent with a malicious selector that tricks DocumentsUI into launching arbitrary activities under its own elevated identity and permissions. Because DocumentsUI is a privileged system app with broad storage and content-provider access, this effectively bypasses Android's permission sandbox. No user interaction and no special app permissions are required once the malicious app is running. Affected versions are Android 14, 15, and 16. The fix (clearing the selector on copied intents) shipped in the March 2026 security bulletin (patch level 2026-03-01) and is also available through Google Play System Update (Project Mainline).

Google's HIGH / 8.4 rating is technically defensible per the CVSS formula — AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H is what you get when a local, no-interaction, no-privilege chain yields full CIA impact. But the score overstates enterprise risk for two reasons. First, the entire chain depends on a malicious app being present on the target device, and enterprise MDM policies, Google Play Protect, and sideloading restrictions make that a non-trivial prerequisite. Second, the blast radius is confined to a single mobile device — there's no lateral movement, no domain escalation, and no fleet-wide impact. The EPSS score of 0.14% (3.9th percentile) and the absence from CISA's KEV catalog corroborate that this is not drawing attacker attention in the wild. For an enterprise fleet with MDM controls, this is a MEDIUM — patch in your normal Android security update cycle, don't scramble.

"Local-only Android EoP via DocumentsUI — real risk hinges on getting a malicious app installed first"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Malicious app lands on target device

The attacker must get a malicious application installed on the victim's Android device. This could happen via a trojanized app on the Play Store that evades review, a sideloaded APK delivered through phishing, or a supply-chain compromise of a legitimate app's build pipeline. The malicious app does not need to request any dangerous Android permissions — a zero-permission app is sufficient.
Conditions required:
  • Victim installs or already has the malicious app on their Android 14/15/16 device
  • Google Play Protect does not flag the app
  • MDM policy (if present) permits installation
Where this breaks in practice:
  • Google Play Protect actively scans and removes known malicious apps
  • Enterprise MDM solutions restrict app installation sources and enforce allowlists
  • Sideloading is disabled by default on most enterprise-managed devices
  • Google Play review catches overtly malicious intent-manipulation code
Detection/coverage: Google Play Protect, MDM compliance reporting, mobile threat defense (MTD) agents like Lookout, Zimperium, or CrowdStrike Falcon for Mobile detect malicious app installations.
STEP 02

Malicious app crafts exploit intent

The installed malicious app constructs an intent targeting com.android.documentsui/.picker.PickActivity with ACTION_PICK. It embeds a second intent as a selector — this selector points to the arbitrary target activity the attacker wants to launch under DocumentsUI's identity. The PoC (attributed to researcher *inforcqb*) demonstrates launching Termux as DocumentsUI. No special timing, race condition, or user interaction is needed.
Conditions required:
  • Malicious app is running (can be triggered by a broadcast receiver on boot)
  • Target device runs Android 14, 15, or 16 with security patch level before 2026-03-01
Where this breaks in practice:
  • Devices with March 2026 or later patches are immune
  • Mainline module delivery means many devices received the fix automatically without a full OTA
Detection/coverage: Static analysis of APKs for intents targeting PickActivity with embedded selectors. Runtime detection by MTD agents monitoring cross-app intent abuse patterns.
STEP 03

DocumentsUI launches arbitrary activity as itself

PickActivity's setupLayout method copies the incoming intent and reuses it — including the attacker-controlled selector — to display additional apps. Because the selector is not cleared, Android resolves the intent to the attacker's chosen target activity, launching it under DocumentsUI's UID and permissions. The malicious app has now successfully deputized DocumentsUI to act on its behalf.
Conditions required:
  • Unpatched DocumentsUI (pre-March 2026 patch level)
  • The target activity is exported or accessible to DocumentsUI's UID
Where this breaks in practice:
  • Many high-value system activities enforce additional caller checks beyond just the calling UID
  • Activities protected by signature-level permissions remain unreachable even from DocumentsUI
Detection/coverage: Android audit logs may record unusual activity launches from DocumentsUI. SELinux policies may block some cross-domain transitions depending on the target.
STEP 04

Privilege escalation and data access

Running as DocumentsUI, the attacker gains access to storage providers, content URIs, and file-system paths that the original malicious app could not reach. This can include reading files from other apps' scoped storage, accessing managed profile data, or interacting with content providers that trust DocumentsUI's identity. The impact is bounded by DocumentsUI's own permission set — this is not a root or kernel-level escalation.
Conditions required:
  • Target data or functionality is accessible to DocumentsUI's UID and permissions
  • SELinux policy does not block the specific access pattern
Where this breaks in practice:
  • DocumentsUI does not run as root or system — it has elevated but bounded permissions
  • Scoped storage restrictions on Android 11+ limit even system apps' access to certain data
  • Work profile separation may prevent cross-profile data access
Detection/coverage: File access anomaly detection via MTD. Unusual content provider queries originating from DocumentsUI process.
03 · Compensating Control

1
MEDIUM 5.5→LOW 2.5
SEVERITY REDUCED
Enforce MDM app installation restrictions — Configure your MDM (Intune, Workspace ONE, JAMF, etc.) to restrict app installation to an approved allowlist and disable sideloading (block adb install and unknown sources). This breaks step 1 of the attack path by preventing the malicious app from being installed in the first place. As a MEDIUM verdict, this falls within the noisgate remediation SLA of 365 days, but MDM hardening should be a standing baseline — verify this policy is active across your fleet now.
2
MEDIUM 5.5→IGNORE 0.0
SEVERITY REDUCED
Verify fleet patch level ≥ 2026-03-01 — Use your MDM's compliance dashboard to query all Android 14/15/16 devices for security patch level. Devices at 2026-03-01 or later are fully remediated. Flag non-compliant devices for accelerated OTA or manual update. Since the Mainline module was also updated, devices with recent Play System Updates may already be patched even if the full OTA patch level appears older — verify the DocumentsUI module version specifically if possible.
3
MEDIUM 5.5→LOW 3.0
SEVERITY REDUCED
Deploy Mobile Threat Defense (MTD) agents — Solutions like Lookout, Zimperium, CrowdStrike Falcon for Mobile, or Microsoft Defender for Endpoint (Android) provide runtime detection of malicious intent patterns and app behavior anomalies. An MTD agent would detect the PoC's cross-app intent abuse pattern at step 2, even on unpatched devices. Deploy within the 365-day noisgate remediation SLA window.
4
MEDIUM 5.5→LOW 2.0
SEVERITY REDUCED
Quarantine or block unmanaged BYOD devices — If your environment allows unmanaged personal Android devices to access corporate resources (email, VPN, intranet), enforce conditional access policies requiring a minimum patch level of 2026-03-01 for Android devices. This prevents vulnerable, unmanaged devices from accessing sensitive corporate data even if exploited.
What doesn't work
  • Network-level controls (firewalls, IDS/IPS, WAF): This is a local attack vector — there is no network traffic to inspect or block. Perimeter defenses are irrelevant.
  • Android runtime permissions: The malicious app does not need any dangerous permissions to exploit this vulnerability. Prompting users to deny permissions has no effect on this chain.
  • Google SafetyNet/Play Integrity attestation alone: While these APIs detect rooted or compromised devices, they do not specifically detect or block the confused deputy intent pattern. They complement but do not substitute for patching or MTD.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNo evidence. Not listed on CISA KEV. No known campaigns or APT usage reported as of September 2026.
Proof of ConceptPublic PoC available. Researcher *inforcqb* published a working Android exploit app on GitHub demonstrating arbitrary activity launch (Termux) via the confused deputy chain.
EPSS Score0.00161 (0.14%) — 3.9th percentile. The exploitation probability model rates this well below the threshold for prioritized patching.
KEV StatusNot listed. No CISA Known Exploited Vulnerabilities catalog entry.
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — Local attack vector with no privileges or interaction required. Scope unchanged means impact is confined to the vulnerable component's authorization context.
Affected VersionsAndroid 14.0, 15.0, 16.0 (all devices below March 2026 security patch level 2026-03-01).
Fixed VersionsPatch level 2026-03-01 and later. Per-branch AOSP commits: Android 14 (631cfe0), Android 15 (550b1a4), Android 16 (8eebea1), 16-qpr2-next (32d6a73). Also delivered via Google Play System Update (Mainline DocumentsUI module).
Scanning / ExposureNot applicable for network-level scanners (GreyNoise/Shodan/Censys). Exposure is assessed via MDM fleet patch-level reporting. No remote attack surface.
Disclosure Date2026-03-02 (NVD published), security patch level 2026-03-01.
Reporting ResearcherPatch authored by Himanshu Arora ([email protected]) at Google. PoC by inforcqb.

Sources.

  1. Android Security Bulletin — March 2026
  2. AOSP Patch Commit (DocumentsUI)
  3. OSV — ASB-A-447135012
  4. SentinelOne Vulnerability Database — CVE-2026-0013
  5. Strix.ai — CVE-2026-0013 Details
  6. OpenCVE — CVE-2026-0013
  7. HKCERT — Android Multiple Vulnerabilities (March 2026)
  8. CyberStrike — CVE-2026-0013 Detail
05 · The Call

Final Verdict
↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

  • Malicious app prerequisite is the real gate: The entire chain requires a malicious application already installed on the target device. On enterprise-managed Android fleets, MDM app allowlists, Google Play Protect, and disabled sideloading make this a high-friction first step that the CVSS local-vector metric doesn't adequately penalize. This is the single largest downward pressure — it converts a theoretical no-interaction chain into a multi-stage attack that first requires social engineering or supply-chain compromise.
  • Device-scoped blast radius with no lateral movement: Even successful exploitation only yields DocumentsUI-level permissions on one device. There is no path to domain takeover, fleet compromise, or supply-chain pivot. The attacker gains file access on a single handset — significant for the individual user, but not an infrastructure-scale event for an enterprise managing 10,000 endpoints.
  • Role multiplier: Android devices occupy the *workstation/endpoint* tier, not the high-value infrastructure catalog (no identity provider, hypervisor, CI/CD, backup, or network-edge role). The worst plausible high-value outcome is exfiltration of corporate email or VPN tokens from a single managed device — serious but host-scoped. The ≥1% high-value-role floor does NOT trigger because Android handsets are not canonically infrastructure components. No floor override applies.
  • EPSS and KEV corroborate low real-world urgency: At 0.14% (3.9th percentile) exploitation probability and no KEV listing after seven months of disclosure, the threat intelligence signal strongly supports a MEDIUM classification rather than HIGH.
  • Mainline delivery narrows the vulnerable window: Unlike traditional Android OTA fragmentation, DocumentsUI is a Project Mainline module. Many devices received the fix automatically through Google Play System Updates without waiting for OEM firmware releases, further shrinking the exploitable population.

Why not higher?

Upgrading to HIGH would require either active exploitation evidence, a realistic path to fleet-scale or identity-scale impact, or removal of the malicious-app-installation prerequisite. None of these conditions are met. The attack is local-only, device-scoped, bounded by DocumentsUI's non-root permissions, and has an EPSS score in the bottom 4th percentile. A PUBLIC PoC exists but has not translated into real-world campaigns after seven months.

Why not lower?

Dropping to LOW would understate the risk because a working PoC exists, the chain requires zero user interaction once a malicious app is present, and DocumentsUI's permissions are genuinely elevated — access to storage providers and content URIs across app boundaries is a meaningful confidentiality and integrity impact. On unmanaged BYOD devices without MDM controls, this chain is realistic enough to warrant tracking and patching within a reasonable window.

06 · Verification

Crowdsourced verification payload.

Run this script from an auditor workstation with adb connected to the target Android device (USB debugging enabled or wireless ADB). Requires adb in PATH. Invoke: bash check_cve_2026_0013.sh. No root required on the device.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_0013.sh — Verify CVE-2026-0013 patch status on connected Android device
# Usage: bash check_cve_2026_0013.sh
# Requires: adb in PATH, one Android device connected
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PATCH_THRESHOLD="2026-03-01"

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

DEVICE_COUNT=$(adb devices | grep -c -E '\bdevice$' || true)
if [ "$DEVICE_COUNT" -eq 0 ]; then
  echo "UNKNOWN — no Android device connected via adb"
  exit 2
elif [ "$DEVICE_COUNT" -gt 1 ]; then
  echo "UNKNOWN — multiple devices connected; specify with ANDROID_SERIAL"
  exit 2
fi

SDK=$(adb shell getprop ro.build.version.sdk 2>/dev/null | tr -d '\r')
PATCH_LEVEL=$(adb shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')
MODEL=$(adb shell getprop ro.product.model 2>/dev/null | tr -d '\r')
ANDROID_VER=$(adb shell getprop ro.build.version.release 2>/dev/null | tr -d '\r')

if [ -z "$PATCH_LEVEL" ]; then
  echo "UNKNOWN — could not read security patch level"
  exit 2
fi

echo "Device: $MODEL (Android $ANDROID_VER, SDK $SDK)"
echo "Security patch level: $PATCH_LEVEL"
echo "Required patch level: $PATCH_THRESHOLD"
echo ""

# Check if Android version is affected (14, 15, 16)
MAJOR_VER=$(echo "$ANDROID_VER" | cut -d. -f1)
if [ "$MAJOR_VER" -lt 14 ] 2>/dev/null; then
  echo "PATCHED — Android $ANDROID_VER is not in the affected range (14-16)"
  exit 0
fi

if [ "$MAJOR_VER" -gt 16 ] 2>/dev/null; then
  echo "PATCHED — Android $ANDROID_VER is beyond the affected range"
  exit 0
fi

# Compare patch levels (lexicographic works for YYYY-MM-DD format)
if [[ "$PATCH_LEVEL" < "$PATCH_THRESHOLD" ]]; then
  echo "VULNERABLE — CVE-2026-0013: patch level $PATCH_LEVEL is before $PATCH_THRESHOLD"
  exit 1
else
  echo "PATCHED — CVE-2026-0013: patch level $PATCH_LEVEL meets or exceeds $PATCH_THRESHOLD"
  exit 0
fi