CVE-2026-58989 in Android
Summary
by MITRE • 11/02/2026
In setOemUnlockAllowedByUser of OemLockService.java, there is a possible way to bypass FRP due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in the setOemUnlockAllowedByUser method within OemLockService.java represents a critical security flaw rooted in insufficient access control mechanisms on Android-based devices. This specific component manages OEM lock states, which are integral to device provisioning and factory reset protection (FRP) implementations. The core technical deficiency lies in the absence of mandatory permission checks before allowing modifications to the state that governs whether an original equipment manufacturer unlock is permitted by a user. In secure system design, operations that alter security-critical settings such as FRP status must be strictly gated behind high-privilege permissions or signature-level signatures to prevent unauthorized modification. The lack of this validation allows any application with access to the relevant service interface to manipulate these settings without proper authorization.
Factory Reset Protection is a vital anti-theft feature designed to render stolen devices useless by requiring the original account credentials after a factory reset. By bypassing the permission check in OemLockService.java, an attacker can effectively disable or alter the FRP state remotely and locally without user interaction. This capability undermines the fundamental security model intended to deter device theft. The vulnerability enables local privilege escalation because it allows lower-privileged applications or processes to perform actions that should be restricted to system-level components with elevated privileges. Since no additional execution privileges are required beyond what is typically granted to standard apps, and no user interaction is needed, the attack surface is significantly expanded, making exploitation straightforward for any malicious entity present on the device.
From a classification perspective, this flaw aligns closely with CWE-284 Improper Access Control, specifically where access control decisions are not enforced before performing actions that affect system security state. It also relates to CWE-732 Incorrect Permission Assignment for Critical Resource, as the resource in question is the OEM unlock and FRP configuration which requires strict integrity controls. In terms of offensive tactics, this vulnerability facilitates techniques associated with MITRE ATT&CK ID T1055 Process Injection or more broadly T1068 Exploitation for Privilege Escalation, depending on how the service interface is accessed. It may also relate to T1492 Stored Data Manipulation if the state change persists across reboots and resets, thereby maintaining the attacker's foothold even after security measures like factory resets are attempted by a victim or administrator.
The operational impact of this vulnerability is severe for both end-users and device manufacturers. For users, it means that FRP can be circumvented, potentially allowing unauthorized access to personal data stored on the device if an attacker gains physical access and performs a reset. For OEMs, it represents a failure in implementing secure bootstrapping and provisioning protocols, which could lead to compliance issues with industry security standards such as GSMA Device Integrity requirements. The ability to bypass FRP without user interaction removes a key deterrent against theft, potentially increasing the resale value of stolen devices on black markets where unlocked or easily reset units are more desirable.
Mitigation strategies must focus on enforcing strict access controls within the OemLockService.java module. Developers should implement explicit permission checks using Android's standard security model, ensuring that only applications with specific system-level permissions such as android.permission.OEM_UNLOCK_STATE or equivalent signature-level signatures can invoke setOemUnlockAllowedByUser. Additionally, integrating integrity verification mechanisms to detect tampering attempts and logging all state changes for audit purposes would enhance visibility into potential exploitation events. Regular code audits focusing on permission validation in service methods are essential to prevent similar flaws from being introduced during future updates. Patching this issue requires a coordinated effort between the framework developers and OEMs to ensure that security-critical services remain isolated from untrusted applications, thereby preserving the integrity of device protection features like FRP.