CVE-2026-107016 in Simple Contacts
Summary
by MITRE • 10/29/2026
Insecure permissions in Fossify v1.3.0 allows unauthorized attackers to access and read another user's stored contacts.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in Fossify version 1.3.0 represents a critical failure in operating system-level permission enforcement, specifically concerning the isolation of application data between different users on multi-user devices or emulators. In Android-based environments, applications are typically assigned unique user identifiers to ensure that one user's private data remains inaccessible to others unless explicitly shared through secure mechanisms such as content providers with granular permissions. However, in this instance, insecure file system permissions were configured within the application package, allowing any authenticated process running under a different user context to traverse into and read files belonging to another user. This flaw effectively bypasses the sandboxing model that is fundamental to mobile security architectures, creating a direct pathway for unauthorized data exfiltration without requiring elevated privileges or exploitation of complex code execution flaws.
From a technical perspective, this issue stems from improper configuration of file modes during application installation or runtime initialization. When an Android application creates private files using standard APIs like openFileOutput with MODE_PRIVATE, the system is expected to set restrictive permissions that prevent access by other users. In Fossify v1.3.0, these permissions were either left at default world-readable states or explicitly misconfigured, resulting in file attributes such as 644 (rw-r--r--) instead of the required 600 (rw-------). This allows any process with a valid user ID on the device to open and read the contacts database stored by Fossify. The vulnerability does not require remote code execution or social engineering; it relies solely on local access, which can be achieved if an attacker has physical access to the device or controls another application installed on the same system that runs under a different user profile.
The operational impact of this vulnerability is severe due to the sensitivity of the data involved. Contacts often contain personally identifiable information including names, phone numbers, email addresses, and sometimes associated notes or social media links. Unauthorized access to this dataset facilitates identity theft, targeted phishing campaigns, and stalking. Furthermore, because contacts are frequently linked to other services such as two-factor authentication recovery methods or account logins, compromising the contact list can serve as a foothold for broader account takeover attacks. The lack of encryption at rest exacerbates the risk, meaning that even if an attacker gains access, they can immediately read and harvest the data without needing to decrypt any protected storage areas. This aligns with CWE-732, which describes improper permission assignment for critical resources, a common root cause in mobile application security failures where developers fail to enforce least privilege principles on local file systems.
In terms of threat modeling, this vulnerability maps directly to MITRE ATT&CK technique T1005, Data from Local System, specifically the sub-technique involving data from removable media or local storage. An attacker leveraging this flaw would be conducting a passive reconnaissance phase, gathering intelligence for future exploitation rather than immediately disrupting service. The attack vector is classified as adjacent network or physical depending on whether the second user account was created by another person sharing the device or if it involves an emulator environment used in development testing that leaked into production builds. For enterprise environments deploying Fossify via mobile device management solutions, this vulnerability poses a significant compliance risk under regulations such as GDPR and HIPAA due to the potential exposure of personal health information or private correspondence stored within contact fields.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary solution is for the vendor to release an updated version that correctly sets file permissions using MODE_PRIVATE, ensuring that created files are only accessible by the application's own user ID. Developers should also implement strict content provider exports with appropriate android:exported flags set to false unless external access is explicitly required and secured via permission checks. For users unable to update immediately, restricting app installation to a single-user profile or using device-level encryption can reduce exposure, though these are not definitive fixes. Security auditors reviewing similar applications should prioritize testing for insecure file permissions by inspecting the application's private directory structure after initial setup, verifying that no files have group or world-readable bits set. Continuous integration pipelines must include static analysis tools configured to detect improper permission assignments in AndroidManifest.xml and Java/Kotlin source code to prevent recurrence of such configuration errors in future releases.