In parsePermissionGroup of ParsedPermissionUtils

CVE-2026-0020 is an Android permission-handling flaw in ParsedPermissionUtils.java that can let a locally running app bypass a consent dialog and obtain permissions it should not get. Google lists Android 14, 15, 16, and 16-qpr2 as affected in the March 2, 2026 bulletin, and the fix lands in the 2026-03-01 Android security patch level.

Google's HIGH 8.4 score is defensible in a lab because the end-state is serious privilege gain with no user interaction once the malicious app is in play. In enterprise reality, that baseline is too hot: the exploit path starts from a local app context, which means the attacker already cleared the biggest hurdle on managed fleets—getting code onto the device at all—so this is a meaningful mobile hardening issue, not the thing you bump remote edge bugs for.

Why this verdict

• Downgrade for attacker position: AV:L means the attacker needs code running on the handset first; that is a major real-world gate, not a footnote.
• Downgrade for exposure fraction: managed enterprise Android fleets often restrict sideloading, unknown sources, and non-approved app install paths, so only a slice of devices are realistically reachable.
• Downgrade for blast radius: exploitation compromises one device context at a time; this is not a tenant-wide, server-side, or perimeter-facing failure mode.
• Hold at MEDIUM, not LOW: once a malicious app is present, the bypass is low-complexity, needs no additional privileges, and can materially expand access without user approval.
• Hold at MEDIUM, not HIGH: there is no KEV listing, no confirmed campaign use, and the provided EPSS (0.00004) is near-zero, which is the opposite of urgent, broad weaponization.

Why not higher?

To score this as HIGH in an enterprise patch queue, you would want one of three amplifiers: remote reachability, active exploitation, or a broadly exposed population. This CVE has none of them in the reviewed evidence. The exploit chain begins after the attacker already has a local app foothold, which is exactly the kind of compounding prerequisite that pushes severity down.

Why not lower?

This is still a real privilege boundary failure in a massively deployed platform, and the impact on an individual device can be substantial once abused. The absence of required user interaction after install, plus the possibility of sensitive permission gain, keeps it above backlog-only hygiene.

1. Block untrusted app installation — Enforce MDM policy to disable sideloading, unknown sources, and unmanaged app stores. For a MEDIUM verdict there is no mitigation SLA, so do this in the next mobile policy cycle while you work toward patching within the 365-day remediation window.
2. Tighten mobile app allowlisting — Restrict installs to approved enterprise catalogs or Play-managed distributions so the attacker cannot easily satisfy the local-app prerequisite. With no mitigation SLA at this severity, align rollout to your normal mobility governance cadence and complete patching within 365 days.
3. Review work-profile and conditional-access policy — Limit what a compromised handset can reach by enforcing app protection, device compliance gates, and minimum OS patch levels for enterprise data access. This reduces blast radius even if a device-level permission bypass succeeds.
4. Monitor for suspicious newly installed apps — Use MTD/EDR for Android, Play Protect, and MDM inventory deltas to flag unexpected app installs and permission anomalies. This does not fix the bug, but it attacks the prerequisite that matters most here: getting code onto the device.

Run this from an auditor workstation with adb installed and USB or managed debugging access to the Android device. Invoke it as ./check_cve_2026_0020.sh <device-serial> or ./check_cve_2026_0020.sh for the only attached device; no root is required, but the host must be authorized for adb shell on the target.

#!/usr/bin/env bash
# check_cve_2026_0020.sh
# Determine likely exposure to CVE-2026-0020 from Android version + security patch level.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/adb failure

set -u

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

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

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

STATE="$(${ADB[@]} get-state 2>/dev/null || true)"
if [[ "$STATE" != "device" ]]; then
  echo "UNKNOWN: adb device not available or not authorized"
  exit 3
fi

getprop_trim() {
  ${ADB[@]} shell getprop "$1" 2>/dev/null | tr -d '\r' | tr -d '\n'
}

PATCH_LEVEL="$(getprop_trim ro.build.version.security_patch)"
RELEASE="$(getprop_trim ro.build.version.release_or_codename)"
if [[ -z "$RELEASE" ]]; then
  RELEASE="$(getprop_trim ro.build.version.release)"
fi
SDK="$(getprop_trim ro.build.version.sdk)"
FINGERPRINT="$(getprop_trim ro.build.fingerprint)"

if [[ -z "$PATCH_LEVEL" || -z "$SDK" ]]; then
  fail "missing security patch level or SDK version"
fi

# Android SDK mapping used here:
# 34 = Android 14
# 35 = Android 15
# 36 = Android 16 / 16-qpr2 family
TARGET_PATCH="2026-03-01"

case "$SDK" in
  34|35|36)
    if [[ "$PATCH_LEVEL" < "$TARGET_PATCH" ]]; then
      echo "VULNERABLE: Android release=${RELEASE:-unknown} sdk=$SDK patch_level=$PATCH_LEVEL fingerprint=$FINGERPRINT"
      exit 1
    else
      echo "PATCHED: Android release=${RELEASE:-unknown} sdk=$SDK patch_level=$PATCH_LEVEL fingerprint=$FINGERPRINT"
      exit 0
    fi
    ;;
  '')
    fail "unable to determine Android SDK version"
    ;;
  *)
    # Outside the vendor-listed affected range; treat older versions as not affected by this CVE.
    # Future versions are marked PATCHED/UNAFFECTED here because the specific vulnerable range is 14/15/16/16-qpr2.
    echo "PATCHED: SDK $SDK is outside the vendor-listed affected range (14/15/16/16-qpr2); patch_level=$PATCH_LEVEL fingerprint=$FINGERPRINT"
    exit 0
    ;;
esac

Sources

1. Android Security Bulletin—March 2026
2. Android fix commit for A-453649815
3. Patch diff for ParsedPermissionUtils.java
4. NVD record
5. OpenCVE / CVE record mirror
6. CISA Known Exploited Vulnerabilities Catalog
7. Feedly CVE intelligence page