In enableSystemPackageLPw of Settings

CVE-2026-0011 is an Android Package Manager logic flaw in enableSystemPackageLPw within Settings.java. Google says it can cause a system app to be re-enabled incorrectly after an update is uninstalled, creating a path to local privilege escalation and breaking location access behavior. Officially affected Android branches are 14, 15, 16, and 16-qpr2; NVD also shows beta variants of 16 qpr2 in the affected CPE set.

The vendor's HIGH 8.4 score overstates enterprise urgency because the bug is local-only and sits behind a very specific state transition in package management. In practice, the attacker needs code execution on the handset first, then must reach a niche package lifecycle condition involving a system app and shared-UID handling. That is valuable for targeted mobile post-exploitation, but it is not the kind of broadly reachable fleet-wide emergency that deserves top-of-queue treatment on Monday morning.

Why this verdict

• Requires local code execution first: AV:L means the attacker must already be running on the handset, which is a built-in downward adjustment from the vendor's 8.4 baseline.
• Specific package-manager state transition: the AOSP fix points to a narrow uninstall/re-enable/shared-UID edge case, not a universal privilege-escalation primitive you can spray across every device.
• Low operational scale: even successful exploitation gives per-device impact, not one-shot compromise of a server tier or 10,000-host estate.

Why not higher?

It is not higher because this is not remotely reachable and not obviously wormable, internet-facing, or mass-exploited. The exploit chain appears to depend on both prior device foothold and a particular package-management condition, which compounds friction fast.

Why not lower?

It is not lower because local privilege escalation on managed mobile devices still matters, especially for executives, developers, and users with strong mobile token or messaging access. If an attacker already has app-level execution, an Android LPE can materially improve stealth, data access, and persistence.

1. Block sideloading — Use MDM/UEM policy to disable unknown-source installs and restrict app installation to managed stores. This attacks the main prerequisite — local malicious code — and for a MEDIUM verdict there is no mitigation SLA, so apply as normal hardening rather than emergency change.
2. Enforce Play Protect and MTD — Keep Google Play Protect enabled and ensure mobile threat defense telemetry is active on corporate Android devices. That raises the cost of initial on-device execution and should be maintained continuously; again, no mitigation SLA applies here.
3. Prioritize high-risk user groups — Inventory Android 14/15/16 devices used by admins, executives, developers, and travelers, then move those cohorts to 2026-03-05 or later SPL first. This narrows the realistic surveillance and token-theft payoff while you work through standard remediation.
4. Monitor package-manager anomalies — Collect device telemetry for app uninstall/re-enable events, especially around system apps and unusual package-state churn. It will not prevent exploitation, but it improves post-compromise visibility during the remediation window.

Run this on an auditor workstation with adb installed and a USB- or network-connected Android device. Invoke it as ./check-cve-2026-0011.sh SERIAL or ./check-cve-2026-0011.sh for the default device; it needs permission to use adb, but not root on the device. It classifies by Android version and security patch level, so it is a practical fleet triage check, not a live exploit test.

#!/usr/bin/env bash
# check-cve-2026-0011.sh
# Determine likely exposure to CVE-2026-0011 on an Android device via adb.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

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

need_cmd() {
  command -v "$1" >/dev/null 2>&1 || {
    echo "UNKNOWN: required command '$1' not found"
    exit 2
  }
}

need_cmd adb

adb_getprop() {
  local prop="$1"
  "${ADB_BASE[@]}" shell getprop "$prop" 2>/dev/null | tr -d '\r'
}

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

ANDROID_VERSION="$(adb_getprop ro.build.version.release)"
CODENAME="$(adb_getprop ro.build.version.release_or_codename)"
PATCH_LEVEL="$(adb_getprop ro.build.version.security_patch)"
MODEL="$(adb_getprop ro.product.model)"
FINGERPRINT="$(adb_getprop ro.build.fingerprint)"

if [[ -z "$PATCH_LEVEL" ]]; then
  echo "UNKNOWN: could not read security patch level"
  exit 2
fi

# Normalize version family.
# Affected according to Google/NVD: Android 14, 15, 16, and 16-qpr2 line.
AFFECTED=0
case "$ANDROID_VERSION" in
  14|15|16) AFFECTED=1 ;;
  *)
    case "$CODENAME" in
      14|15|16) AFFECTED=1 ;;
      *) AFFECTED=0 ;;
    esac
    ;;
esac

if [[ "$AFFECTED" -eq 0 ]]; then
  echo "PATCHED: device is not on an affected Android branch (model=$MODEL android=$ANDROID_VERSION codename=$CODENAME spl=$PATCH_LEVEL)"
  exit 0
fi

# Google states SPL 2026-03-05 or later addresses all March 2026 bulletin issues.
FIX_SPL="2026-03-05"

if [[ "$PATCH_LEVEL" < "$FIX_SPL" ]]; then
  echo "VULNERABLE: affected Android branch with security patch level before $FIX_SPL (model=$MODEL android=$ANDROID_VERSION codename=$CODENAME spl=$PATCH_LEVEL fp=$FINGERPRINT)"
  exit 1
fi

if [[ "$PATCH_LEVEL" >= "$FIX_SPL" ]]; then
  echo "PATCHED: affected Android branch but security patch level is $PATCH_LEVEL, which is >= $FIX_SPL (model=$MODEL android=$ANDROID_VERSION codename=$CODENAME)"
  exit 0
fi

echo "UNKNOWN: unable to classify device (model=$MODEL android=$ANDROID_VERSION codename=$CODENAME spl=$PATCH_LEVEL fp=$FINGERPRINT)"
exit 2

Sources

1. Android Security Bulletin—March 2026
2. Pixel Update Bulletin—March 2026
3. AOSP fix commit for A-454062218
4. NVD entry for CVE-2026-0011
5. OSV record for CVE-2026-0011
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS API documentation