Android CVE-2026-0065

The attacker must have code executing on the target Android device with at minimum user-level (PR:L) app execution privileges - in practice this means a malicious or compromised app must already be installed and running. The attack vector is entirely local (AV:L); there is no remote or network-based exploitation path. The vulnerability does not require any user interaction after installation (UI:N), and complexity is low (AC:L), meaning no special race condition or precise timing is needed. Exploitation is limited by: (1) the requirement to have an app installed on the target device, (2) SSVC Automatable:no indicating it cannot be trivially mass-exploited at scale, and (3) no public exploit or POC code at time of analysis. Default Android security features such as Play Protect and app installation restrictions raise the practical bar for initial code execution.

The CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately reflects a local, low-complexity privilege escalation with total impact across confidentiality, integrity, and availability - consistent with SSVC Technical Impact: total. The local attack vector (AV:L) significantly limits the threat model: an attacker must already have code executing on the target device, typically as an installed (possibly malicious) app. SSVC rates Exploitation: none and Automatable: no, and EPSS at 0.12% (2nd percentile) confirms extremely low observed exploitation probability. Despite the full-impact CVSS triad, this is a classic 'high CVSS, lower real-world urgency' scenario for most defenders: exploitation requires a malicious app to be installed and active on the victim device, which itself is a non-trivial prerequisite. That said, for organizations managing Android fleets, this remains a meaningful escalation risk since a compromised or sideloaded app could use this to silently assume a higher trust posture without any user prompt. The September 2026 Android Security Bulletin provides the authoritative fix.

A malicious Android application installed on a victim device - for example, via social engineering or a compromised third-party app store - invokes internal Android APIs or crafted Intent sequences that trigger areBackgroundActivityStartsAllowed with manipulated process state, causing the logic gate to incorrectly return true. The app then launches a privileged background activity (e.g., a system-trusted UI or a sensitive component it should not be allowed to start), achieving privilege escalation to gain access to protected data or system functions. No user interaction is required after app installation, making this silently exploitable once the malicious app is on-device.