Google Android CVE-2026-58866

Exploitation requires local access via an app already running on the device; the flaw is reachable by any app calling setAccessibilityWindowAttributes because the permission check is missing, with no user interaction needed (UI:N) and no additional execution privileges required. The practical limiting factors are: (1) the attacker must first get code onto the device (a local foothold / installed app), as the CVSS vector is AV:L, so there is no remote network path; and (2) the device must run an affected Android branch (14, 15, 16, 16-qpr2, or 17). The trigger beyond 'a missing permission check on setAccessibilityWindowAttributes enabling untrusted/misleading UI' is not further detailed in the available sources.

This is a locally-exploitable privilege-escalation flaw (CWE-862, missing permission check in setAccessibilityWindowAttributes) with a CVSS 3.1 vector of AV:L/AC:L/PR:N/UI:N and the input score of 8.4. The CVSS attack vector is explicitly Local (AV:L), so despite the high score this is NOT a remotely reachable issue - it requires code already running on the device (a malicious or compromised app), which bounds real-world risk. Google's SSVC assessment reinforces a measured urgency: Exploitation=none (no observed or public exploitation), Automatable=no, but Technical Impact=total. The vuln.today priority label is 'this_week', consistent with a serious-but-not-emergency EoP. There is no CISA KEV listing and no POC/exploit reference in the supplied data, and no EPSS score was provided, so there is no signal of active or imminent exploitation. Net: a genuinely high-severity local EoP worth patching on a near-term cycle, but not a drop-everything emergency - the combination of local-only access, no known exploitation, and non-automatable exploitation argues against treating it like a wormable remote bug. Note one tension to verify: the input vector asserts PR:N (no privileges) yet an Android local EoP realistically presupposes an installed/running app as a foothold; this is standard Android bulletin convention but means 'unauthenticated' should be read as 'no special app permissions required,' not 'no code on device.'

A user installs a seemingly benign, low- or zero-permission app. Because setAccessibilityWindowAttributes lacks a permission check, the app sets misleading accessibility window attributes to spoof or overlay trusted UI (CVSS AV:L/AC:L, no user interaction), tricking the system or user into granting it elevated capabilities. No public exploit code or PoC reference is present in the supplied data.