In createSessionInternal of PackageInstallerService

CVE-2026-0023 is an Android PackageInstallerService authorization flaw in createSessionInternal(). Public records tie it to Android 14, 15, 16, and 16-qpr2 before the March 2026 fixes; the bug lets an already-installed app abuse installer session state because a permission/flag check was missing or incomplete, resulting in local elevation of privilege on that one device.

Google's HIGH 7.8 CVSS is technically fair in a lab because the impact on the compromised handset can be serious. In enterprise reality, though, this starts after the attacker already has code running on the device, has no network reachability, has no KEV or exploitation signal, and often runs into Managed Google Play, sideload restrictions, and Play Protect. That's why this drops to MEDIUM for a 10,000-device patch queue.

Why this verdict

• Starts post-compromise: AV:L and PR:L mean the attacker already has an installed app executing on the handset before this CVE matters.
• Exposure population is narrow: enterprise Android fleets using Managed Google Play, app allowlists, and unknown-source restrictions materially reduce the number of devices where step 1 is realistic.
• No active exploitation signal: no KEV, no public campaign attribution, and an extremely low EPSS keep downward pressure on urgency.

Why not higher?

This is not remotely reachable, not wormable, and not an edge-service bug that can be sprayed across your estate. Even if the per-device impact is severe, the prerequisite of local code execution means the attacker is already through your first line of defense.

Why not lower?

Once a malicious app is on an affected device, exploitation appears low-complexity and silent. For organizations with Android BYOD, permissive sideloading, or weak mobile app governance, this can still convert a modest foothold into a stronger one on the same handset.

1. Block unknown app sources — Use Android Enterprise controls such as DISALLOW_INSTALL_UNKNOWN_SOURCES and Google Play managed configuration to keep installs inside Managed Google Play. For a MEDIUM verdict there is no noisgate mitigation SLA, so do this in the next mobile policy cycle rather than as an emergency change.
2. Enforce app allowlisting — Restrict work-profile and fully managed devices to approved app catalogs only. This directly attacks the hardest prerequisite in the chain: getting attacker code onto the handset in the first place.
3. Watch for package-installer abuse — Turn on whatever MTD/UEM telemetry you have for suspicious installs, silent update attempts, or unexpected installer/package-owner changes. This won't prevent the bug, but it improves visibility on the only practical exploitation path.
4. Prioritize risky mobile cohorts — Focus first on BYOD, COPE, contractor, kiosk, and field devices that routinely receive third-party APKs or looser app controls. That's where the local-app prerequisite is most credible.

Run this on an auditor workstation with adb installed and USB debugging or enterprise debugging access to the target Android device. Invoke it as ./check-cve-2026-0023.sh <serial> or omit the serial if only one device is attached; no root is required, but you need adb shell access.

#!/usr/bin/env bash
# check-cve-2026-0023.sh
# Purpose: Determine likely exposure to CVE-2026-0023 using Android version + security patch level.
# Logic:
#   - Affected major versions: Android 14, 15, 16 / API 34, 35, 36
#   - Patched if security patch level >= 2026-03-05
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

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

need_cmd() {
  command -v "$1" >/dev/null 2>&1
}

if ! need_cmd adb; then
  echo "UNKNOWN: adb not found in PATH"
  exit 2
fi

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

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

SDK="$(getprop_safe ro.build.version.sdk)"
RELEASE="$(getprop_safe ro.build.version.release)"
PATCH="$(getprop_safe ro.build.version.security_patch)"
FINGERPRINT="$(getprop_safe ro.build.fingerprint)"
MODEL="$(getprop_safe ro.product.model)"

if [[ -z "$SDK" || -z "$PATCH" ]]; then
  echo "UNKNOWN: unable to read required properties"
  echo "model=${MODEL:-unknown} release=${RELEASE:-unknown} sdk=${SDK:-unknown} patch=${PATCH:-unknown}"
  exit 2
fi

# Normalize patch string to YYYY-MM-DD and compare lexicographically.
PATCH_CUTOFF="2026-03-05"

echo "model=${MODEL:-unknown}"
echo "release=${RELEASE:-unknown}"
echo "sdk=${SDK:-unknown}"
echo "patch=${PATCH:-unknown}"
echo "fingerprint=${FINGERPRINT:-unknown}"

case "$SDK" in
  34|35|36)
    if [[ "$PATCH" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
      if [[ "$PATCH" < "$PATCH_CUTOFF" ]]; then
        echo "VULNERABLE"
        exit 1
      else
        echo "PATCHED"
        exit 0
      fi
    else
      echo "UNKNOWN: unexpected patch format"
      exit 2
    fi
    ;;
  ''|*[!0-9]*)
    echo "UNKNOWN: unexpected SDK value"
    exit 2
    ;;
  *)
    # Outside the affected Android major versions cited by bulletin/OSV.
    echo "PATCHED"
    exit 0
    ;;
esac

Sources

1. Android Security Bulletin — March 2026
2. AOSP fix commit for bug A-459461121
3. OSV advisory for ASB-A-459461121 / CVE-2026-0023
4. NVD entry for CVE-2026-0023
5. Android PackageInstaller API docs showing `ENFORCE_UPDATE_OWNERSHIP` requirement
6. Android Enterprise security controls for blocking unknown sources
7. CISA Known Exploited Vulnerabilities Catalog
8. Secondary enrichment with EPSS percentile and affected-version summary