Google Android EUVD-2026-115417

Requires local access to the device - either a locally installed/malicious app or physical possession - because the vector is AV:L; it is not remotely exploitable. The specific prerequisite is reaching OemLockService.setOemUnlockAllowedByUser, which is missing its required permission check (CWE-862), allowing the OEM-unlock-allowed flag to be set and Factory Reset Protection (FRP) to be bypassed without the normally-required permission and without user interaction (UI:N). Limiting factors: the attacker must already be able to execute code on or physically operate the device, and only Android 15, 16, and 16-qpr2 are listed as affected; the exact caller context needed to invoke the method is not described in the available sources.

Signals are moderately consistent and point to a locally-exploitable authorization flaw rather than a remotely-wormable threat. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N) describes a local attack requiring no privileges and no user interaction, with high confidentiality, integrity and availability impact (base 8.4) - consistent with the description's 'local escalation of privilege with no additional execution privileges needed.' EPSS is very low (0.12%, 2nd percentile), which is expected for a local Android privilege-escalation/FRP-bypass bug that cannot be exploited over the network and typically needs a planted app or physical access; low EPSS here reflects non-remote mechanics, not low severity. This is NOT in CISA KEV and no public exploit is identified, so exploitation status is 'no public exploit identified at time of analysis.' The vuln.today Decision label is 'this_week,' indicating prompt but non-emergency patching. Net: a genuine high-severity authorization/FRP-bypass issue meriting patching in the current cycle, but not evidence of active, widespread exploitation - the AV:L vector and the FRP-bypass nature mean realistic risk concentrates on stolen/lost or attacker-handled devices and malicious local apps. One caveat to verify with the vendor: CWE-862 (missing authorization) and the 'missing permission check' description align with the local vector, but the trigger specifics (whether any unprivileged app can invoke setOemUnlockAllowedByUser, or whether some binder/UI path is required) are not detailed in the available sources.

A malicious app installed on the device, or an attacker with hands-on access to a lost/stolen handset, invokes setOemUnlockAllowedByUser in OemLockService without the permission that should gate it. Because the permission check is missing, the OEM-unlock-allowed flag is set, defeating Factory Reset Protection and enabling bootloader unlock / further local privilege escalation. No public exploit is identified at time of analysis, and because the vector is local (AV:L) it cannot be triggered remotely.