In onTransact of IDrmManagerService

CVE-2026-0010 is an Android local elevation-of-privilege bug in drm/common/IDrmManagerService.cpp reachable through Binder IPC. The March 2, 2026 Android bulletin lists affected AOSP releases as Android 14, 15, and 16, and the fix lands in the March 2026 patch train; the patch replaces unsafe formatting around the FileDescriptorKey handling path in onTransact, eliminating the out-of-bounds write condition.

Google's HIGH 8.4 label is technically understandable because memory corruption in a privileged service can end in full device compromise. But for enterprise patch triage this is overstated: the attacker already needs code execution on the handset, the flaw is local-only (AV:L), there is no KEV listing, the supplied EPSS is negligible (0.00003), and there is no public exploit chain showing reliable weaponization at scale. That combination pushes this out of emergency patch territory.

Why this verdict

• Down from 8.4 because AV:L means post-compromise. An attacker must already be executing code on the device; that is a major real-world filter compared with remotely reachable bugs.
• Down again because exposure population is narrow. This is Binder-mediated local IPC, not an internet-facing service, so external attack-surface size is effectively zero.
• Down again because threat intel is cold. No KEV listing, no public exploitation claim, no public PoC, and the supplied EPSS of 0.00003 all argue against urgent mass exploitation risk.
• Held at MEDIUM, not LOW, because successful exploitation breaks the Android app sandbox. Once triggered, the impact on an individual device can still be severe.

Why not higher?

This is not a one-packet fleet problem. It requires prior code execution on the handset and then a reliable local memory-corruption exploit path against a privileged service, which compounds attacker cost and cuts the exposed population dramatically. If this were remotely reachable, KEV-listed, or backed by a public exploit, the rating would move up fast.

Why not lower?

Do not shrug this off as harmless hygiene. A sandbox escape / privesc on managed mobile devices still matters because one malicious or compromised app can turn into a much deeper device compromise. The impact is strong enough that it belongs above backlog-only treatment, just not above remotely exploitable or actively exploited issues.

1. Restrict app installation paths — Use MDM to block sideloading, unknown sources, and unapproved app stores because this CVE needs local code execution first. For a MEDIUM verdict there is no mitigation SLA, but this is the best risk-reduction lever and should be enforced in your normal mobile policy cycle rather than waiting on the patch.
2. Enforce Play Protect and mobile threat defense — Keep Google Play Protect enabled and require your mobile threat defense agent on managed Android devices so malicious APK delivery is harder and suspicious app behavior is surfaced sooner. For MEDIUM, there is no mitigation SLA — go straight to the remediation window unless your environment allows broad sideloading.
3. Prioritize risky device cohorts — If you cannot update everything at once, move devices used by admins, executives, developers, shared kiosks, and BYOD-like exception groups to the front because the value of a local privesc is highest where device trust matters most. For MEDIUM, do this inside normal maintenance planning rather than emergency change control.

Run this on the target Android device shell through adb shell sh /data/local/tmp/check_cve_2026_0010.sh or from your EMM/MDM shell runner. It needs only standard shell access to read system properties; no root is required. Example: adb push check_cve_2026_0010.sh /data/local/tmp/ && adb shell sh /data/local/tmp/check_cve_2026_0010.sh.

#!/system/bin/sh
# check_cve_2026_0010.sh
# Determine likely exposure to CVE-2026-0010 using Android release and security patch level.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

TARGET_SPL="2026-03-01"

release="$(getprop ro.build.version.release)"
codename="$(getprop ro.build.version.release_or_codename)"
spl="$(getprop ro.build.version.security_patch)"
product="$(getprop ro.product.manufacturer) $(getprop ro.product.model)"

# Normalize release major version.
major=""
case "$release" in
  14|15|16)
    major="$release"
    ;;
  *)
    case "$codename" in
      14*|15*|16*) major="$(echo "$codename" | cut -d. -f1)" ;;
      *) major="" ;;
    esac
    ;;
esac

if [ -z "$spl" ]; then
  echo "UNKNOWN - missing security patch level property on $product"
  exit 2
fi

# Lexical compare works for YYYY-MM-DD format.
if [ -z "$major" ]; then
  echo "UNKNOWN - Android release '$release' / codename '$codename' not in known affected set; SPL=$spl on $product"
  exit 2
fi

if [ "$major" != "14" ] && [ "$major" != "15" ] && [ "$major" != "16" ]; then
  echo "PATCHED - release $major not listed as affected; SPL=$spl on $product"
  exit 0
fi

if [ "$spl" \< "$TARGET_SPL" ]; then
  echo "VULNERABLE - Android $major with SPL $spl is older than $TARGET_SPL on $product"
  exit 1
fi

echo "PATCHED - Android $major with SPL $spl meets or exceeds $TARGET_SPL on $product"
exit 0

Sources

1. Android Security Bulletin — March 2026
2. NVD entry for CVE-2026-0010
3. AOSP fix commit
4. AOSP patch diff
5. Android Binder overview
6. Android security features / application sandbox
7. FIRST EPSS data and statistics
8. CISA Known Exploited Vulnerabilities catalog