In hasInteractAcrossUsersFullPermission of AppInfoBase

CVE-2026-0021 is an Android Settings app confused-deputy bug in AppInfoBase.java that can bypass a cross-user permission check and let code on the device act across user boundaries. Google lists Android 14, 15, 16, and 16-qpr2 as affected in the March 2026 bulletin, and the public fix adds an explicit INTERACT_ACROSS_USERS_FULL permission check for the calling package on multi-pane devices; the patch level that addresses the bulletin is 2026-03-05 or later.

The vendor's HIGH 8.4 score reflects worst-case device impact once the bug is reached, but it overstates enterprise patch urgency. This is not an initial-access bug: the attacker needs local code execution on the handset first, the vulnerable path sits in the Settings app, the fix strongly suggests multi-pane / large-screen form factors are the meaningful exposure set, and there is no KEV listing, no exploitation note for this CVE, and extremely low EPSS.

Why this verdict

• Start from 8.4 HIGH, then cut for attacker position: AV:L on Android means the adversary already has code running on the device, usually via a malicious app or prior compromise.
• Cut again for exposure population: the patch explicitly references permission checking on multi-pane devices, which points to tablets/foldables/large-screen paths rather than the entire Android phone fleet.
• Cut again for threat intel: no KEV, no public exploitation note for this CVE, no primary-source PoC, and a near-zero EPSS score all argue against emergency treatment.

Why not higher?

This should not stay HIGH because it does not give an attacker a path onto the device; it only helps after they already landed code locally. The blast radius is also usually limited to a single handset and its user/profile boundaries, not broad tenant or server compromise.

Why not lower?

I am not pushing it to LOW because cross-user boundary breaks on Android can still matter in enterprise work-profile and shared-user scenarios. If a malicious app is already present, the bug removes an important isolation boundary without requiring extra privileges or user clicks.

1. Enforce managed app sources only — Block sideloading and restrict installs to managed Google Play / approved stores so the attacker never gets the local foothold this bug depends on. Because the reassessed verdict is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but this control should still be standard policy for the affected Android cohorts.
2. Keep Play Protect and MTD telemetry enabled — Play Protect and mobile threat defense are the controls most likely to stop the delivery stage or flag suspicious app behavior before this bug matters. For a MEDIUM issue there is no separate mitigation clock, but keep this enforced continuously while you schedule the patch inside the 365-day remediation window.
3. Disable or tightly govern adb and developer options — USB debugging and unmanaged developer mode make local app delivery and testing materially easier for an attacker or insider. Apply this as device-hardening hygiene on managed fleets; again, no mitigation SLA applies here, but it should be part of your standing baseline before the remediation deadline.
4. Prioritize large-screen and work-profile devices first — If you cannot patch the whole Android fleet uniformly, front-load tablets, foldables, shared-user, kiosk, and work-profile-heavy populations because the public fix points to a multi-pane Settings path and the business impact is highest where cross-user/profile boundaries matter. Use that prioritization while planning vendor/OEM patch uptake within the 365-day remediation window.

Run this on an auditor workstation that has adb installed and USB or network debugging access to the target Android device. Invoke it as ./check-cve-2026-0021.sh <serial> for a specific device, for example ./check-cve-2026-0021.sh ZX1G22B7; no root is required, but adb shell getprop access is required.

#!/usr/bin/env bash
# check-cve-2026-0021.sh
# Conservative verifier for CVE-2026-0021 on Android devices via adb.
# Logic:
#   - Affected Android branches: 14, 15, 16, 16-qpr2
#   - Android bulletin says security patch level 2026-03-05 or later addresses all issues
# Output:
#   PATCHED    = device not in affected major versions, or SPL >= 2026-03-05
#   VULNERABLE = affected major version and SPL < 2026-03-05
#   UNKNOWN    = cannot determine required properties / adb issues
# Exit codes:
#   0 PATCHED
#   1 VULNERABLE
#   2 UNKNOWN

set -u

SERIAL="${1:-}"
ADB_BIN="${ADB:-adb}"
FIXED_SPL="2026-03-05"

adb_cmd() {
  if [[ -n "$SERIAL" ]]; then
    "$ADB_BIN" -s "$SERIAL" "$@"
  else
    "$ADB_BIN" "$@"
  fi
}

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

if ! adb_cmd get-state >/dev/null 2>&1; then
  echo "UNKNOWN - no reachable adb device"
  exit 2
fi

ANDROID_RELEASE="$(adb_cmd shell getprop ro.build.version.release 2>/dev/null | tr -d '\r')"
ANDROID_CODENAME="$(adb_cmd shell getprop ro.build.version.codename 2>/dev/null | tr -d '\r')"
SPL="$(adb_cmd shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')"
BUILD_FINGERPRINT="$(adb_cmd shell getprop ro.build.fingerprint 2>/dev/null | tr -d '\r')"

if [[ -z "$ANDROID_RELEASE" || -z "$SPL" ]]; then
  echo "UNKNOWN - unable to read Android release or security patch level"
  exit 2
fi

# Normalize major release (e.g., 14, 15, 16)
MAJOR="${ANDROID_RELEASE%%.*}"

# Basic SPL format check YYYY-MM-DD
if [[ ! "$SPL" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
  echo "UNKNOWN - unexpected security patch level format: $SPL"
  exit 2
fi

# Determine affected branch
AFFECTED=0
case "$MAJOR" in
  14|15|16)
    AFFECTED=1
    ;;
  *)
    AFFECTED=0
    ;;
esac

if [[ "$AFFECTED" -eq 0 ]]; then
  echo "PATCHED - not in affected Android major versions (release=$ANDROID_RELEASE spl=$SPL)"
  exit 0
fi

# Lexicographic compare is safe for YYYY-MM-DD strings
if [[ "$SPL" < "$FIXED_SPL" ]]; then
  echo "VULNERABLE - affected Android release=$ANDROID_RELEASE spl=$SPL (< $FIXED_SPL); fingerprint=$BUILD_FINGERPRINT"
  exit 1
fi

# Note: this does not validate the device's multi-pane exposure path or OEM backport details.
echo "PATCHED - affected Android release=$ANDROID_RELEASE but spl=$SPL (>= $FIXED_SPL); fingerprint=$BUILD_FINGERPRINT"
exit 0

Sources

1. Android Security Bulletin — March 2026
2. AOSP commit for bug A-430047417
3. AOSP public diff showing caller permission check
4. NVD record for CVE-2026-0021
5. OpenCVE record with CNA and CISA ADP enrichment
6. OSV record ASB-A-430047417
7. CISA Known Exploited Vulnerabilities Catalog