SailingLab AppLock CVE-2025-68709

Exploitation requires two concrete prerequisites: (1) a malicious application must be co-installed on the same Android device as SailingLab AppLock 4.3.8 - this is the adjacency condition reflected in CVSS AV:A; and (2) user interaction is required (CVSS UI:R), meaning the victim must trigger or interact with AppLock's BrowserMainActivity during or after the malicious intent is sent. The vulnerability is specifically conditioned on BrowserMainActivity being exported and accepting implicit VIEW intents without URI scheme validation - this is the exploitable configuration. Exploitation is limited by the requirement that the attacker's app already reside on the device (no remote network delivery path exists), and that some degree of user engagement with AppLock occurs. Authentication is not required from the attacking app (PR:N). The attack does not work against devices where the attacker cannot install applications (e.g., fully managed enterprise devices with strict allowlisting).

The CVSS base score of 5.2 (Medium) reflects a constrained but non-trivial attack surface. The vector AV:A/AC:L/PR:N/UI:R/S:C breaks down as follows: no privileges are required by the attacker app, complexity is low once a malicious app is installed, but user interaction is required (the victim must interact with or trigger the AppLock component), and scope is changed - impact escapes the calling app boundary into AppLock's elevated context. The changed scope (S:C) is the most significant signal here: AppLock's purpose is to gate access to other applications, meaning JavaScript executing within its WebView may interact with or visually impersonate its locking UI, potentially deceiving users into bypassing or misconfiguring security controls. No EPSS score was provided in the input data; without it, exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation at time of analysis. A publicly available proof-of-concept exists at the reporter's GitHub repository, which lowers the exploitation barrier. Real-world risk is moderate: exploitation requires a malicious app to already be installed on the victim device and requires user interaction, but the privilege escalation implication through a security-focused app (AppLock) makes this higher-priority than a typical medium-CVSS WebView XSS.

An attacker distributes a malicious Android application that, once installed alongside AppLock, programmatically fires a VIEW intent targeting com.alpha.applock's BrowserMainActivity with a payload such as javascript:document.write('<phishing UI>'). When the victim interacts with AppLock - for instance, when it prompts to unlock a protected app - the injected JavaScript executes within AppLock's WebView context, potentially rendering a spoofed unlock screen to harvest a PIN or manipulating AppLock's UI to disable protection. A publicly available proof-of-concept at https://github.com/actuator/com.alpha.applock/blob/main/CVE-2025-68709 demonstrates this technique.