What is the CVSS score of CVE-2026-0091?

CVE-2026-0091 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Android are affected by CVE-2026-0091?

Google Android devices running versions 14 through 16-qpr2 are vulnerable to a privilege escalation vulnerability (CVE-2026-0091) that could allow malware to gain elevated system access without user…

How to fix or mitigate CVE-2026-0091?

Within 24 hours: Inventory all Android devices in your environment, identifying those running versions 14, 15, 16, or 16-qpr2. Within 7 days: Implement compensating controls including mobile device management (MDM) policies to restrict shell access, enable application allowlisting, and enforce SELinux in enforcing mode; deploy mobile threat defense solutions for runtime detection. Within 30 days: Establish a monitoring process for Google Android security advisories; prepare rapid deployment procedures for when vendor patches become available.

Android CVE-2026-0091

EUVD-2026-33802 HIGH

Improper Privilege Management (CWE-269)

2026-06-01 google_android

GHSA-q687-8858-63rc

Privilege Escalation

7.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 02, 2026 - 00:29 vuln.today

CVSS changed

Jun 01, 2026 - 23:22 NVD

7.8 (HIGH)

CVE Published

Jun 01, 2026 - 21:14 nvd

UNKNOWN (no severity yet)

CVE Published

Jun 01, 2026 - 21:14 nvd

HIGH 7.8

DescriptionCVE.org

In multiple locations, there is a possible way to execute code in the launcher process due to an over-privileged shell user. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

AnalysisAI

Local privilege escalation in Google Android (versions 14, 15, 16, and 16-qpr2) allows a low-privileged shell user to execute code within the launcher process due to over-privileged shell user permissions in multiple code locations. The flaw requires no user interaction and no additional execution privileges, enabling an attacker with shell-level access to gain elevated privileges. No public exploit identified at time of analysis, and SSVC indicates no observed exploitation, though technical impact is rated total.

Technical ContextAI

The vulnerability resides in the Android launcher process - the system component responsible for the home screen and app management - where shell user accounts (typically the 'shell' UID used for ADB and developer access) hold permissions beyond what they require. This is a classic CWE-269 (Improper Privilege Management) weakness, where a process or user identity is granted capabilities that should be restricted to higher-trust contexts. The CPE entry cpe:2.3:a:google:android:*:*:*:*:*:*:*:* covers all Android variants, and the EUVD enumeration confirms the issue spans Android 14 through 16-qpr2, suggesting a long-standing over-permissive configuration rather than a regression introduced in a single release.

RemediationAI

Patch available per vendor advisory - apply the Android security patch level published in the June 2026 Android Security Bulletin (https://source.android.com/docs/security/bulletin/2026/2026-06-01), which addresses the over-privileged shell user condition in the launcher process. Device owners should update to the latest available OTA from their OEM that includes the 2026-06-01 (or later) security patch level; enterprise fleets should enforce minimum SPL via MDM compliance policies. As compensating controls until patches roll out, disable USB debugging (ADB) on production devices to remove the most common path to shell-level access, restrict physical device access in shared/kiosk deployments, and for MDM-managed fleets consider disabling developer options entirely via policy - note that this will block legitimate debugging workflows and field-support tooling.