Android EUVD-2026-33811

Exploitation requires (1) a malicious application already installed on the device with at least the low privileges implied by CVSS PR:L - typically the SYSTEM_ALERT_WINDOW / 'Display over other apps' permission or an equivalent overlay capability - and (2) the device running an unpatched build of Android 14, 15, 16, or 16-qpr2 prior to the 2026-06-01 Security Patch Level. Limiting factors: the attack is local-only (AV:L, no remote network reach), it cannot be triggered against a stock device with no attacker-controlled app installed, and although the CVSS marks UI:N, the overlay technique inherently depends on the victim subsequently interacting with a sensitive screen the attacker can predict and cover. Devices that have disabled or never granted 'Display over other apps' to the malicious app are not exploitable via the documented vector.

The CVSS base of 7.8 with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H indicates a locally-exploitable, low-complexity issue requiring some pre-existing privilege (an installed app) but no user interaction, yielding full confidentiality, integrity, and availability impact - consistent with privilege escalation on mobile. SSVC reinforces this: Exploitation=none (no observed attacks), Automatable=no (each victim requires a targeted overlay timed to a specific UI flow), Technical Impact=total. There is no CISA KEV listing and no public exploit identified at time of analysis, so this should be prioritized as a standard monthly Android Security Bulletin patch rather than an emergency. Note the apparent tension between the CVSS string (PR:L, UI:N) and the description's mention of a tapjacking/overlay attack, which conceptually depends on the user tapping the overlay - defenders should treat 'no user interaction' as referring to no consent dialog acknowledgement rather than zero user activity, and verify the precise trigger with Google's bulletin.

A user sideloads or downloads from Play a seemingly benign utility app that requests 'Display over other apps'; in the background it monitors foreground activities and, when a privileged system dialog (e.g., a runtime permission grant or a Device Admin enablement screen) appears, it calls addWindow to render a transparent overlay containing crafted UI that captures the tap intended for the 'Allow' button. The victim believes they are tapping the malicious app's own button but actually grants the malicious app elevated privileges. No public exploit identified at time of analysis, but the technique is well-documented in mobile security research and is straightforward to weaponize once the addWindow validation gap is understood.