SailingLab AppLock CVE-2025-68708

Physical access to the target Android device is the absolute prerequisite - exploitation cannot occur remotely or over any network. SailingLab AppLock 4.3.8 must be installed and actively configured to lock one or more target applications. The bypass is triggered via advertisement intents or browser intent navigation paths that expose internal Activity routes within AppLock, meaning the attack sequence relies on interacting with AppLock's own UI rather than the locked app directly. The limiting factors are: (1) physical possession of the device is required, (2) the screen must be accessible (device must be unlocked at the OS level or the attacker must bypass the OS lock separately), and (3) the bypass navigates overlay dismissal rather than credential theft, so it does not yield the PIN itself. Authentication requirements at the Android OS level are outside the scope of this CVE - if the device screen lock is active, that must be addressed independently before this bypass applies.

Real-world risk is LOW and tightly constrained by the physical access requirement. The CVSS 3.1 base score of 2.4 accurately reflects the threat model: AV:P (physical access required), AC:L (low complexity once physically present), PR:N (no OS-level credentials needed), UI:N, Scope:Unchanged, Confidentiality:Low, Integrity:None, Availability:None. EPSS at 0.04% (11th percentile) corroborates that automated or remote exploitation is not occurring. There is no CISA KEV listing. The researcher has published a disclosure at GitHub (actuator/com.alpha.applock), which functions as a technical writeup that could guide manual exploitation, but automated weaponization is implausible given the physical-touch prerequisite. The 'Privilege Escalation' tag in the intelligence data is worth noting: while CVSS marks I:N, the ability to access PIN-locked apps on someone else's device represents a meaningful real-world privacy and access-control violation even if it doesn't rise to system-level privilege escalation. The primary risk population is shared or stolen devices. This is NOT a priority for enterprise patch management queues but IS relevant to personal privacy threat models.

An attacker with brief unsupervised physical access to an Android device running AppLock 4.3.8 opens a browser or triggers an advertisement intent within the AppLock interface, navigating a cascading sequence of UI screens that routes around the PIN overlay without invoking PIN verification. The overlay is dismissed or bypassed by the intent navigation, exposing the protected application - for example, Chrome and its saved passwords or open sessions - directly to the attacker. A researcher-published technical writeup at GitHub provides implementation detail that could guide this sequence for a technically motivated actor.