In multiple locations

CVE-2026-0008 is an Android elevation-of-privilege bug caused by a *confused deputy* condition. The public record says exploitation can yield local privilege escalation with no user interaction, and the affected product mapping currently points to Google Android 16. Google lists it in the March 2, 2026 Android Security Bulletin under the Framework section with bug ID A-433252423, and devices reporting a security patch level of 2026-03-01 or later are documented as having the 2026-03-01 fixes.

The vendor's HIGH 8.4 score overstates enterprise patch urgency for most fleets. The decisive friction is attacker position: this is AV:L on a client OS, so the attacker already needs code execution on the handset before this bug matters; that makes it a *post-initial-access privilege escalator*, not an initial compromise vector. Add the tiny EPSS, no KEV listing, no cited in-the-wild use, and an affected range effectively narrowed to Android 16, and this lands in MEDIUM for real-world patch prioritization.

Why this verdict

• Downgrade for attacker position: AV:L means the attacker must already be on the device. That's a post-initial-access step, not a breach entry point.
• Downgrade for exposure population: current public mappings point to Android 16 only, not a broad multi-generation Android fleet issue.
• Downgrade for threat evidence: no KEV listing, no confirmed active exploitation, and an extremely low EPSS remove the urgency amplifier that would normally keep a vendor HIGH intact.

Why not higher?

It is not higher because this is not a remotely reachable service bug and not an unauthenticated network path. The attacker must first clear the hardest part of the chain—getting code onto the handset—before this CVE can help. There is also no public evidence that defenders are currently losing to this bug in the wild.

Why not lower?

It is not lower because once triggered, the technical impact is still serious: local privilege escalation on a managed endpoint can expose enterprise app data and trust material. 'Local-only' does not mean harmless; it means the bug is dangerous *after* another control has already failed.

1. Enforce managed-app install policy — Use MDM/EMM to block unknown sources, restrict sideloading, and require approved app stores. This attacks the main prerequisite—local code execution—and, for a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, though this control is worth enforcing sooner if your mobile posture is weak.
2. Require Play Protect and mobile threat defense — Ensure Google Play Protect stays enabled and feed mobile risk signals into conditional access. These controls reduce the odds that a malicious app reaches the device in the first place; again, no mitigation SLA applies here, but they are strong standing controls while patching proceeds.
3. Inventory Android 16 devices — Pull a device list from MDM for all handsets reporting Android 16 and compare ro.build.version.security_patch against 2026-03-01. Because this is a MEDIUM issue, use the inventory to drive orderly remediation inside the 365-day window.
4. Gate high-risk mobile access — Apply stricter conditional access to unmanaged, out-of-date, or high-risk mobile devices for sensitive enterprise apps. This limits the blast radius if a local privilege escalator is chained after malicious app execution.

Run this from an auditor workstation with adb installed and USB debugging or approved enterprise ADB access to the target Android device. Invoke it as ./check-cve-2026-0008.sh <device-serial> or ./check-cve-2026-0008.sh for the default device; no root is required, but you do need ADB connectivity to the handset.

#!/usr/bin/env bash
# check-cve-2026-0008.sh
# Verify likely exposure to CVE-2026-0008 on an Android device via ADB.
# Logic:
#   - CVE currently maps to Android 16.
#   - Android security patch level 2026-03-01 or later is treated as patched.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

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

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

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

if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
  fail_unknown "no reachable ADB device"
fi

ANDROID_VERSION=$("${ADB[@]}" shell getprop ro.build.version.release 2>/dev/null | tr -d '\r')
PATCH_LEVEL=$("${ADB[@]}" shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')
BUILD_FINGERPRINT=$("${ADB[@]}" shell getprop ro.build.fingerprint 2>/dev/null | tr -d '\r')

if [[ -z "$ANDROID_VERSION" ]]; then
  fail_unknown "could not read Android version"
fi

if [[ -z "$PATCH_LEVEL" ]]; then
  fail_unknown "could not read security patch level"
fi

# Basic validation of patch date format YYYY-MM-DD
if [[ ! "$PATCH_LEVEL" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
  fail_unknown "unexpected patch level format: $PATCH_LEVEL"
fi

# Only Android 16 is currently mapped as affected.
if [[ "$ANDROID_VERSION" != "16" ]]; then
  echo "PATCHED: device reports Android $ANDROID_VERSION; current public mappings for CVE-2026-0008 indicate Android 16 is affected"
  echo "Fingerprint: $BUILD_FINGERPRINT"
  exit 0
fi

THRESHOLD="2026-03-01"
if [[ "$PATCH_LEVEL" < "$THRESHOLD" ]]; then
  echo "VULNERABLE: Android 16 device with security patch level $PATCH_LEVEL (< $THRESHOLD)"
  echo "Fingerprint: $BUILD_FINGERPRINT"
  exit 1
fi

echo "PATCHED: Android 16 device with security patch level $PATCH_LEVEL (>= $THRESHOLD)"
echo "Fingerprint: $BUILD_FINGERPRINT"
exit 0

Sources

1. NVD CVE record
2. Android Security Bulletin — March 2026
3. OpenCVE record
4. OSV advisory page for A-433252423
5. Current Android OSV JSON for A-433252423
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS API documentation