In createRequest of MediaProvider

CVE-2026-0035 is an Android MediaProvider logic flaw in MediaProvider.java's createRequest path. Google says a local app can gain read/write access tied to non-existent file URIs, which can lead to elevation of privilege without extra permissions or user interaction. The March 2026 Android bulletin marks Android 14, 15, 16, and 16-qpr2 as affected, and the issue sits in the MediaProvider Mainline component rather than a network-facing service.

The vendor's HIGH 8.4 score is technically defensible in a lab because the bug needs no permissions and can affect confidentiality, integrity, and availability on the device. In real enterprise operations, though, the biggest friction is decisive: the attacker must already get a malicious app running locally on the handset. That makes this a post-delivery, on-device abuse primitive with low internet-scale reach, so it lands lower than the vendor baseline for patch-priority purposes.

Why this verdict

• Requires local code execution The attacker must already land a malicious app or equivalent code on the handset. In enterprise terms, that means this CVE is usually *post-delivery* rather than an initial-access event, which pushes severity down from the vendor baseline.
• Reachable population is limited Only devices on affected Android 14/15/16 branches without the March 5, 2026 fix are in scope, and even then only if app-install controls, Play Protect, or mobile threat defense fail first.
• No exploitation heat There is no KEV listing, no public in-the-wild note from Google for this CVE, no public PoC found, and the supplied EPSS is effectively floor-level.

Why not higher?

This is not remotely reachable, not wormable, and not useful without an app foothold on the device. The fleet-wide emergency cases are the bugs that give an outsider entry; this one mostly helps an attacker who is already on the phone.

Why not lower?

Once the app is present, exploitation appears low-complexity and does not need permissions or user interaction. The affected component is also broadly deployed across modern Android releases, so ignoring it would understate the risk to already-compromised devices.

1. Block sideloading — Use EMM/MDM policy to disable unknown-source installs and developer-install paths where business allows it. This directly attacks the key prerequisite for exploitation; for a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this is still the highest-value preventive control.
2. Enforce app allowlisting — Restrict installation to approved stores and approved package IDs, especially on COBO/COPE devices. This cuts off the most likely delivery path for a local exploit app; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
3. Turn on mobile threat defense — Enable Play Protect and, if you run it, your MTD agent's detections for suspicious content-provider abuse, unusual storage access, and sideload events. This will not patch the bug, but it raises the cost of operationalizing a malicious APK; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
4. Prioritize unpatched Android 14-16 inventory — Use EMM inventory to find devices below Android security patch level 2026-03-05 and queue them for normal patching. Because this is a Mainline component issue, also verify Play system update posture where your tooling exposes it; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.

Run this on the target Android device via adb shell from an auditor workstation, or push it through an EMM shell if your platform supports that. Example: adb shell 'sh -s' < check-cve-2026-0035.sh. It needs no root and checks the device security patch level against the Android bulletin's fix anchor of 2026-03-05.

#!/system/bin/sh
# check-cve-2026-0035.sh
# Purpose: infer exposure to CVE-2026-0035 from Android security patch level.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

TARGET_PATCH="2026-03-05"
TARGET_NUM="20260305"

get_prop() {
  /system/bin/getprop "$1" 2>/dev/null
}

SPL="$(get_prop ro.build.version.security_patch)"
RELEASE="$(get_prop ro.build.version.release)"
BUILD_ID="$(get_prop ro.build.id)"
FINGERPRINT="$(get_prop ro.build.fingerprint)"

if [ -z "$SPL" ]; then
  echo "UNKNOWN - security patch level not available"
  echo "release=${RELEASE:-unknown} build_id=${BUILD_ID:-unknown}"
  exit 2
fi

case "$SPL" in
  ????-??-??) ;;
  *)
    echo "UNKNOWN - unparsable security patch level: $SPL"
    echo "release=${RELEASE:-unknown} build_id=${BUILD_ID:-unknown}"
    exit 2
    ;;
esac

SPL_NUM="$(echo "$SPL" | tr -d '-')"

if [ "$SPL_NUM" -ge "$TARGET_NUM" ] 2>/dev/null; then
  echo "PATCHED - security patch level $SPL is >= $TARGET_PATCH"
  echo "release=${RELEASE:-unknown} build_id=${BUILD_ID:-unknown}"
  exit 0
fi

echo "VULNERABLE - security patch level $SPL is < $TARGET_PATCH"
echo "release=${RELEASE:-unknown} build_id=${BUILD_ID:-unknown}"
if [ -n "$FINGERPRINT" ]; then
  echo "fingerprint=$FINGERPRINT"
fi
exit 1

Sources

1. Android Security Bulletin — March 2026
2. OSV advisory ASB-A-418773439
3. AOSP fixing commit for MediaProvider
4. AOSP patch diff showing invalid-URI check
5. NVD entry for CVE-2026-0035
6. Pixel Update Bulletin — March 2026
7. CISA Known Exploited Vulnerabilities Catalog