Android EUVD-2026-33786

A malicious application must already be installed on the target Android device - the local attack vector (AV:L) confirms this precondition. The attacker application requires no special system privileges (PR:N) prior to exploitation, meaning a standard user-space app is sufficient. Exploitation targets Android 14, 15, 16, and 16-qpr2 specifically; patched devices or Android versions outside this range are not affected. The CVSS vector states UI:N (no user interaction required), but this directly conflicts with the CVE description's language of 'trick a user into accepting a permission' - if the attack truly requires the user to tap a disguised dialog, then successful exploitation is limited by whether the user can be induced to interact with a spoofed UI element. Enterprise environments with strict MDM controls preventing sideloading or enforcing application allowlists are significantly less exposed, as the attack chain is broken at the installation stage.

CVSS scores this at 5.9 Medium with a local attack vector (AV:L), low complexity (AC:L), no required privileges (PR:N), no user interaction (UI:N), and low impact across confidentiality, integrity, and availability (C:L/I:L/A:L). However, a significant internal contradiction exists: the CVE description explicitly states the attacker must 'trick a user into accepting a permission,' implying user interaction is required, yet the CVSS vector specifies UI:N (no user interaction). This discrepancy is material - if user interaction is actually required (UI:R), the CVSS base score would be lower and the exploitation model would require a social engineering component. Security teams should verify this inconsistency with the Android Security Bulletin. EPSS at 0.01% (1st percentile) and absence from CISA KEV strongly suggest no widespread or confirmed active exploitation. The local attack vector limits exposure to scenarios where a malicious app is already installed on the device, reducing the immediate severity compared to a remote-exploitable vulnerability. Nonetheless, the breadth of affected versions (four actively supported Android releases) makes this a meaningful patch priority for enterprise Android fleet managers.

An attacker publishes a malicious Android application - potentially disguised as a utility or game - and social-engineers the target into installing it. Once installed, the app deploys a transparent overlay precisely positioned over a system permission dialog (such as a request for camera, location, or storage access), causing the user's intended tap to silently grant elevated permissions to the malicious app instead. No public exploit code has been identified at time of analysis, but the attack technique is well-understood within the Android security research community and does not require sophisticated tooling.