Easyelife App Lock CVE-2025-68710

Physical access to the target Android device is required, as confirmed by the CVSS vector (AV:P). The device must have Easyelife App Lock version 1.9.2 installed and at least one application (such as Chrome) must be configured under its protection. The exploit path requires the attacker to interact with the Easyelife App Lock interface while it is active - specifically, to trigger either an advertisement interaction or a browser intent within the app's UI flows. No attacker privileges are required (PR:N per CVSS). Exploitation is bounded by: (1) mandatory physical device presence - remote exploitation is categorically impossible, (2) the victim must have installed and configured the app lock on target applications, and (3) the attacker must have sufficient unobserved time to navigate multiple UI steps. The vulnerability does not affect the underlying Android OS screen lock or any apps protected by native Android authentication mechanisms.

The CVSS base score of 2.4 with vector AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N correctly constrains risk: physical access (AV:P) is a hard prerequisite that eliminates remote exploitation entirely. The EPSS score of 0.05% at the 16th percentile aligns with this constraint - threat actors rarely write automated exploits for vulnerabilities requiring hands-on device access. The app is not listed in CISA KEV. The 'Privilege Escalation' tag in the intelligence data is somewhat misleading when compared to the CVSS vector, which scores scope as Unchanged (S:U) and integrity impact as None (I:N); the realistic impact is information disclosure from apps the attacker can now access, not a full privilege elevation. Automatable exploitation is not possible given the physical vector, and SSVC would likely score this as 'defer' for most enterprise contexts. The risk is highest in scenarios involving shared or briefly unattended devices (e.g., kiosk, shared family device, or device briefly left with a semi-trusted party). Users who installed this app specifically to protect sensitive apps are the most directly harmed, as the security control they rely on provides a false sense of assurance.

An attacker with brief physical access to an Android device running Easyelife App Lock 1.9.2 opens the app's interface and triggers an in-app advertisement or manipulates a browser intent to cause the application to navigate through its internal activity stack. The overlay PIN prompt is bypassed as the underlying protected app (e.g., Chrome) is brought to the foreground through Android's activity manager without authentication being verified, granting the attacker direct access to the target app's content and any stored credentials or session data. A researcher writeup with likely proof-of-concept steps is publicly available on GitHub.