A pickpocket who can only steal your wallet after you've already invited them into your house
CVE-2026-0023 is a local privilege escalation in Android's PackageInstallerService.java. The createSessionInternal function fails to verify whether a calling app has permission to modify the ownership attributes of a package installation session. A malicious app already installed on the device can silently hijack session ownership, effectively impersonating another app or gaining installer-level privileges — full confidentiality, integrity, and availability impact on the device. Affected versions span Android 14, 15, 16, and 16-qpr2, covering essentially every modern Android device. Google patched it in the March 2026 Android Security Bulletin (patch level 2026-03-01), with per-branch AOSP commits for each version.
Google's HIGH 7.8 rating is technically correct by CVSS math — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H is the standard score for a clean local EoP. But the CVSS score doesn't discount the real precondition: an attacker must first get a malicious application installed on the target device. On enterprise-managed Android fleets with MDM restrictions on sideloading and Google Play Protect enabled, that precondition introduces meaningful friction that CVSS doesn't model. The scope is also unchanged — blast radius is limited to the single compromised device. There are no public PoCs, no known exploitation in the wild, no KEV listing, and an EPSS of 0.00084 (~15th percentile). The vendor severity overstates the real-world urgency for enterprise defenders.
4 steps from start to impact.
Malicious app installation
PR:L) permissions; no special install-time permissions are required.- Victim installs or sideloads a malicious APK
- Device permits installation from unknown sources, OR app passes Play Store review
- Google Play Protect scans apps at install time and periodically; known malware patterns are blocked
- Enterprise MDM policies (e.g., Intune, VMware WS1) can restrict installation to managed Play Store only
- Android 14+ restricts accessibility and notification-listener permissions for sideloaded apps via Restricted Settings
Exploit createSessionInternal missing permission check
PackageInstallerService.createSessionInternal(), crafting session parameters that modify the ownership attributes of an installation session. Because the function lacks the required permission validation, the OS accepts the request from any app with basic foreground execution rights. No user interaction or special timing window is needed (AC:L, UI:N).- Malicious app is running on a device with Android 14–16 at patch level < 2026-03-01
- The vulnerability window is strictly pre-patch; once the March 2026 OTA lands, the vector is closed
- Enterprise MDM can enforce minimum security patch levels and quarantine non-compliant devices
Session ownership hijack
- Successful exploitation of step 2
- Target package session exists or can be created
- Android SELinux policies and app sandbox may limit the practical blast radius of ownership change depending on the target package's security context
- Ownership alone may not bypass all DAC/MAC enforcement in hardened OEM builds (Samsung Knox, Google Pixel Tensor security)
dumpsys package logs; no standard SIEM integration for this telemetry on most enterprise MDM platformsPrivilege escalation and data access
C:H/I:H/A:H — the attacker can read sensitive data, modify app state, and potentially disrupt device operation. The scope remains unchanged (S:U), meaning the impact is confined to the single device.- Successful ownership hijack in step 3
- Impact is per-device only; no lateral movement path to other devices or enterprise infrastructure
- Data exfiltration still requires network egress, which enterprise proxies or DLP can monitor
- Network firewalls / WAF / IDS — This is a local on-device vulnerability. No network traffic is involved in the exploitation itself. Network controls only help if you're watching for *post-exploitation* data exfiltration, not the privilege escalation.
- VPN enforcement — Routing device traffic through a corporate VPN does not prevent a local app from calling PackageInstaller APIs. VPN is irrelevant to this attack path.
- Android app permissions review — The malicious app does not need any dangerous permissions to exploit this flaw. Standard low-privilege app permissions suffice (
PR:L), so permission auditing will not flag the attacker app.
The supporting signals.
| In-the-wild exploitation | Not observed. Not listed on CISA KEV. No reports from Google TAG, Mandiant, or Lookout of active exploitation campaigns targeting this CVE. |
|---|---|
| Proof-of-concept availability | No public PoC specific to CVE-2026-0023. The related predecessor CVE-2024-0044 (same function, different flaw class — input validation vs. missing permission check) had multiple PoCs including one from canyie demonstrating run-as-any-app. The exploitation pattern for -0023 would be simpler (API call, no injection needed). |
| EPSS score | 0.00084 (0.084% probability of exploitation in 30 days). Approximately 15th–20th percentile — well below the threshold where EPSS-driven prioritization would flag urgency. |
| KEV status | Not listed. No CISA KEV entry as of 2026-09-26. |
| CVSS vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — Local access only, low complexity, low privilege, no user interaction, scope unchanged. Full CIA impact on the device. The AV:L and S:U are the key limiters: no remote exploitation, no cross-boundary impact. |
| Affected versions | Android 14, 15, 16, 16-qpr2, 16-qpr2-next. Essentially all currently supported Android versions at the time of disclosure. |
| Fixed versions | Security patch level 2026-03-01 or later. AOSP commits: dc741f7 (Android 14), a1435a1 (Android 15), 9904287 (Android 16), 49cd29d (16-qpr2), 23ee35e (16-qpr2-next). OEM/carrier OTA delivery timelines vary. |
| Exposure data | Not applicable for network scanning (Shodan/GreyNoise/Censys). This is a local-only Android vulnerability — no network-facing attack surface. Enterprise exposure is measured by MDM compliance dashboards showing devices below patch level 2026-03-01. |
| Disclosure date | 2026-03-01 (Android Security Bulletin), public CVE record 2026-03-02. |
| Reporter | Not publicly attributed. Reported through Google's Android security reward program. |
Sources.
Why this verdict
- Pre-condition friction (app installation): The entire chain begins with a malicious app already present on the device. This is not a zero-click remote exploit — the attacker must defeat Google Play Protect, third-party MTD, and (on managed devices) MDM sideloading restrictions before the vulnerability is even reachable. This is the single largest downward pressure.
- Scope is per-device, not fleet-scale:
S:Umeans the blast radius is confined to the single compromised Android device. There is no lateral movement path, no domain escalation, no supply-chain pivot. Compromising one phone does not cascade to the fleet. - Role multiplier: Android phones occupy endpoint roles — (a) personal devices, (b) corporate-managed phones with email/calendar/VPN, (c) kiosk/POS/field-worker tablets. Even in the worst case (c), the outcome is single-device data theft or disruption, not domain takeover or fleet compromise. Android is not a canonically high-value-role component (not a DC, hypervisor, CI/CD, PKI, or network edge). No floor override applies.
- Zero exploitation evidence: EPSS 0.00084 (~15th percentile), no KEV listing, no public PoC for this specific CVE, no reported campaigns. The predecessor CVE-2024-0044 in the same function had PoCs but targeted a different flaw class (input validation). The exploitation economics are poor when the precondition (malicious app install) is already a significant barrier.
- Enterprise MDM as structural mitigation: Organizations managing Android fleets via Intune, WS1, or similar MDM can enforce minimum patch levels (2026-03-01), restrict unknown-source installs, and quarantine non-compliant devices — reducing the reachable population to unmanaged or BYOD devices without MDM enforcement.
Why not higher?
A HIGH or CRITICAL rating would require either remote exploitability, fleet-scale blast radius, or evidence of active exploitation — none of which apply here. The vulnerability is strictly local (AV:L), scope-unchanged (S:U), and has zero evidence of weaponization. The precondition of requiring a pre-installed malicious app means the attacker has already achieved initial access on the device before this CVE becomes relevant, which substantially reduces its marginal value.
Why not lower?
A LOW or IGNORE rating would be inappropriate because the vulnerability does provide a *real* privilege escalation path with full CIA impact on the device, requires no user interaction once the malicious app is present, and has low attack complexity. Corporate Android devices hold sensitive data (email, auth tokens, VPN credentials, documents), so per-device compromise is not trivial. The flaw affects every supported Android version, giving it broad theoretical reach across billions of devices.
Crowdsourced verification payload.
Run from an auditor workstation with adb access to the target Android device(s). Requires USB debugging enabled or wireless ADB paired. Invoke: bash check_cve_2026_0023.sh [device_serial]. No root or elevated privileges needed on the device — getprop is accessible to the shell user.
#!/bin/bash
# CVE-2026-0023 Patch Verification
# Checks Android security patch level against the fix (2026-03-01)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
REQUIRED_PATCH="2026-03-01"
if [ -n "$1" ]; then
ADB_TARGET="-s $1"
else
ADB_TARGET=""
fi
# Verify adb connectivity
if ! adb $ADB_TARGET get-state 1>/dev/null 2>&1; then
echo "UNKNOWN - Cannot connect to device. Check adb connectivity."
exit 2
fi
# Retrieve security patch level
PATCH_LEVEL=$(adb $ADB_TARGET shell getprop ro.build.version.security_patch 2>/dev/null | tr -d '\r')
if [ -z "$PATCH_LEVEL" ]; then
echo "UNKNOWN - Could not read ro.build.version.security_patch"
exit 2
fi
# Retrieve device info for reporting
MODEL=$(adb $ADB_TARGET shell getprop ro.product.model 2>/dev/null | tr -d '\r')
ANDROID_VER=$(adb $ADB_TARGET shell getprop ro.build.version.release 2>/dev/null | tr -d '\r')
echo "Device: $MODEL (Android $ANDROID_VER)"
echo "Security patch level: $PATCH_LEVEL"
echo "Required patch level: >= $REQUIRED_PATCH"
echo "---"
# Compare dates (lexicographic comparison works for YYYY-MM-DD)
if [[ "$PATCH_LEVEL" < "$REQUIRED_PATCH" ]]; then
echo "VULNERABLE - CVE-2026-0023: patch level $PATCH_LEVEL is below $REQUIRED_PATCH"
exit 1
else
echo "PATCHED - CVE-2026-0023: patch level $PATCH_LEVEL meets or exceeds $REQUIRED_PATCH"
exit 0
fi