Android CVE-2026-59006

Requires a locally-present malicious application capable of drawing an overlay (e.g., a SYSTEM_ALERT_WINDOW-style overlay) on top of a target window, exploiting faulty touch-occlusion handling in getTouchOcclusionMode so that occluded touches are not properly treated. Exploitation is bounded by several concrete limiting factors: the attacker must already have code running locally on the device (AV:L - this is not remotely reachable), the victim must actively interact with the manipulated/obscured UI (user interaction is explicitly required per the description), and the impact is limited to information disclosure (C:L) with no integrity or availability effect. The exact code path and precise overlay conditions that defeat the occlusion check are not detailed in the available sources beyond the component name.

This is a low-severity, locally-scoped issue that should be patched on a routine cycle rather than treated as an emergency, and the signals are largely consistent on that point. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, base 4.0) describes a local vector with limited confidentiality impact and no integrity or availability impact. EPSS is very low at 0.11% (1st percentile), there is no CISA KEV listing and no exploit or PoC reference in the supplied data, so exploitation is no public exploit identified at time of analysis. The vuln.today decision label is 'this_month', which aligns with the low EPSS and absence of active-exploitation signals - meaningful but not urgent. One internal conflict must be noted: the CVSS vector encodes UI:N (no user interaction) while the description explicitly states 'User interaction is needed for exploitation,' which is also inherent to a tapjacking/overlay attack; the description should be treated as authoritative here, so the UI:N in the vector appears understated - verify against the Android bulletin. Net: a genuine but low-priority tapjacking information-disclosure flaw, not a high-CVSS-but-overrated case because the CVSS is already low and matches the real-world picture.

A user installs or already runs a malicious Android app that draws an overlay window on top of a sensitive system or app window. Because getTouchOcclusionMode does not correctly account for the occluding overlay, the user is induced to interact with (tap on) UI they cannot fully see, allowing the malicious app to glean information it should not have access to. No public exploit code is identified in the available data, and exploitation requires the victim to interact with the manipulated UI.