In removePermission of PermissionManagerServiceImpl

CVE-2026-0026 is an Android local privilege-escalation bug in PermissionManagerServiceImpl.removePermission(). The fix shows the core mistake: Android should reject removal of non-dynamic permissions and return immediately, but vulnerable builds could continue into the removal path, creating a way to override system permissions. Public records tie the issue to Android 14 and fixes shipped in the 2026-03-01 Android security patch level; OSV also shows a related fix carried into 16-qpr2-next development branches.

Google scored it High 7.8, which is technically defensible in a lab because the post-exploit impact is big. In real enterprise conditions, that overstates urgency: this is not remotely reachable, needs local code execution plus user interaction, and mostly matters after an attacker already lands a malicious app on the device. That combination pushes it down from emergency patch territory to a controlled mobile-fleet remediation item.

Why this verdict

• Down from vendor 7.8: AV:L is the biggest drag. This is not remotely reachable, so an attacker must already be on the handset with executable code.
• Further down: UI:R means the chain needs the user to do something useful for the attacker, which modern mobile enterprise controls often disrupt.
• Population cap: the public scope is basically Android 14, not a broad cross-version Android fleet issue.
• Blast radius is local: compromise is per-device or per-profile, not a server-side or tenant-wide takeover primitive.
• No exploitation heat: no KEV listing, no public PoC found, and EPSS is near zero.

Why not higher?

If this were remotely triggerable, wormable, or already showing active exploitation, it would climb fast. But every major prerequisite compounds downward pressure: local foothold, user action, and a narrow affected version set mean this is a post-delivery escalation bug, not an initial-access event.

Why not lower?

This is still a genuine privilege-escalation flaw in the Android permission model, not harmless noise. If an attacker does get a malicious app onto a vulnerable handset, the resulting integrity and data-access impact on that device can be serious enough that backlog-only treatment would be too casual.

1. Block sideloading — Use EMM/MDM policy to disable unknown-source installs and restrict app sources to managed Google Play. This attacks the most important prerequisite in the chain; for a MEDIUM verdict there is no mitigation SLA, so apply on the next policy cycle and then patch through normal mobile maintenance.
2. Enforce app allowlisting — Limit devices to approved apps, especially on corporate-owned profiles. That materially reduces the reachable population because this CVE needs local code execution first; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window while maintaining this policy control.
3. Turn on Play Protect and MTD — Verify Google Play Protect is enabled and integrate mobile threat defense where available to catch malicious APKs and suspicious post-install behavior. This will not 'fix' the bug, but it is one of the few controls that can stop the chain before privilege escalation; with MEDIUM, keep it enforced continuously while scheduling patch rollout.
4. Inventory Android 14 with old SPLs — Query EMM for devices on Android 14 with ro.build.version.security_patch earlier than 2026-03-01. That gives you the real exposure set instead of treating the entire mobile fleet as affected; for MEDIUM, use that inventory to drive patching inside the normal remediation window.
5. Tighten high-risk user cohorts first — Prioritize executives, admins, developers, and frequent travelers whose phones see more untrusted content or sideload requests. The CVE is not internet-scale, so risk is driven by user behavior and app hygiene more than raw device count.

Run this from an auditor workstation with adb installed and USB/network debugging access to the target Android device. Invoke it as ./check-cve-2026-0026.sh <serial> or ./check-cve-2026-0026.sh for the only attached device; it needs adb access only, not root on the handset.

#!/usr/bin/env bash
# check-cve-2026-0026.sh
# Detect likely exposure to CVE-2026-0026 on Android devices via adb.
# Logic:
#   - Vulnerable population from public records: Android 14
#   - Fixed by Android security patch level 2026-03-01 or later
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

set -u

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

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

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

if ! "${ADB_BASE[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: no reachable adb device${TARGET:+ for serial $TARGET}"
  exit 3
fi

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

ANDROID_RELEASE="$(getprop_trim ro.build.version.release)"
SDK="$(getprop_trim ro.build.version.sdk)"
PATCH="$(getprop_trim ro.build.version.security_patch)"
FINGERPRINT="$(getprop_trim ro.build.fingerprint)"

if [[ -z "$ANDROID_RELEASE" && -z "$SDK" && -z "$PATCH" ]]; then
  fail_unknown "unable to read Android properties"
fi

# Normalize Android major version from release string.
MAJOR=""
if [[ "$ANDROID_RELEASE" =~ ^([0-9]+) ]]; then
  MAJOR="${BASH_REMATCH[1]}"
fi

# Fallback via SDK if release is unavailable.
# Android 14 == SDK 34
if [[ -z "$MAJOR" && "$SDK" == "34" ]]; then
  MAJOR="14"
fi

# Validate patch date format YYYY-MM-DD
valid_patch=0
if [[ "$PATCH" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
  valid_patch=1
fi

echo "Device fingerprint: ${FINGERPRINT:-unknown}"
echo "Android release: ${ANDROID_RELEASE:-unknown}"
echo "SDK: ${SDK:-unknown}"
echo "Security patch level: ${PATCH:-unknown}"

if [[ -z "$MAJOR" ]]; then
  fail_unknown "cannot determine Android major version"
fi

# Public sources tie CVE-2026-0026 mainly to Android 14.
if [[ "$MAJOR" != "14" ]]; then
  echo "PATCHED: device is not in the public affected Android 14 population"
  exit 0
fi

if [[ $valid_patch -ne 1 ]]; then
  fail_unknown "Android 14 device but security patch level is unreadable"
fi

FIXED_PATCH="2026-03-01"

# Lexicographic compare is safe for YYYY-MM-DD.
if [[ "$PATCH" < "$FIXED_PATCH" ]]; then
  echo "VULNERABLE: Android 14 with security patch level older than $FIXED_PATCH"
  exit 1
else
  echo "PATCHED: Android 14 with security patch level $PATCH (fixed if OEM backporting is accurate)"
  exit 0
fi

Sources

1. Android Security Bulletin — March 2026
2. NVD entry for CVE-2026-0026
3. OSV advisory ASB-A-321711213
4. OSV entry for CVE-2026-0026
5. AOSP fix commit for PermissionManagerServiceImpl
6. CISA Known Exploited Vulnerabilities Catalog
7. Stack.watch EPSS/affected-version summary for CVE-2026-0026