CVE-2026-107056 in OpenTracks
Summary
by MITRE • 10/29/2026
Insecure permissions in the io.file.importer.ImportActivity component of OpenTracks versionCode 6751 allows unauthorized attackers to inject crafted tracking data into the victim's location database via a crafted SEND message.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified within the io.file.importer.ImportActivity component of OpenTracks, specifically in builds with version code 6751 and earlier, represents a critical failure in access control mechanisms that governs how external data is ingested into the application's local storage. This flaw stems from an insecure configuration where the activity responsible for importing file-based tracking data does not adequately restrict its accessibility to other applications on the Android operating system. By failing to enforce strict permission checks or by exporting the component without appropriate safeguards, the application inadvertently exposes a vector through which malicious actors can interact with the import functionality remotely. This misconfiguration allows any installed application on the device, regardless of whether it has legitimate user intent or authorization, to send broadcast messages that trigger this activity and supply arbitrary data payloads for processing.
From a technical perspective, the core issue lies in the improper handling of incoming intents associated with file imports. When an attacker constructs a SEND message containing crafted tracking data, they can exploit the exported nature of the ImportActivity component to force the application to parse and store this malicious input as if it were legitimate user-generated location history. The vulnerability does not require physical access or prior authentication within the app itself; instead, it relies on the default Android permission model which often allows inter-app communication via broadcasts unless explicitly restricted by the developer. This lack of validation means that the application accepts data from untrusted sources without verifying its origin or integrity, leading to a direct injection of false location records into the victim's database.
The operational impact of this vulnerability is significant for both individual privacy and system integrity. By injecting crafted tracking data, an attacker can manipulate the user's perceived location history, potentially causing confusion in navigation applications that rely on OpenTracks data, or facilitating stalking by creating a fabricated trail of movement. Furthermore, if the application syncs this corrupted data to cloud services or shares it with other apps, the integrity of broader datasets is compromised. This type of attack falls under the category of unauthorized information modification and can be leveraged for social engineering attacks where false location evidence is used to deceive third parties. The ability to write arbitrary data into a sensitive database also increases the risk of further exploitation if subsequent processes assume the validity of this stored tracking information, potentially leading to logic flaws in dependent services.
This vulnerability aligns with CWE-284, which describes Improper Access Control, as well as CWE-798, concerning Use of Hard-coded Credentials or Default Permissions that leave systems vulnerable by default. In terms of offensive security frameworks, this behavior is consistent with MITRE ATT&CK technique T1053, specifically the Scheduled Task/Job subcategory if automated via background services, but more accurately maps to data injection vectors similar to those seen in supply chain attacks where trusted components are abused to introduce malicious artifacts. The attack vector leverages local application interactions rather than network-based exploitation, classifying it as a Local Attack Vector with Low Complexity for an attacker who has the ability to install arbitrary applications on the target device.
To mitigate this risk, developers must immediately review and restrict the export status of the io.file.importer.ImportActivity component in the AndroidManifest.xml file by setting android:exported to false unless explicit external interaction is required. If external access is necessary, strict permission checks using custom permissions or signature-level verification should be implemented to ensure that only trusted applications can invoke the import functionality. Additionally, input validation must be enforced on all data received via intents to verify format and content before insertion into the database. Users affected by this vulnerability in version 6751 and earlier are advised to update to a patched release where these access controls have been hardened. Security auditors should also perform static analysis on similar components within the codebase to identify any other exported activities or services that may suffer from analogous permission misconfigurations, ensuring comprehensive remediation of insecure default states across the application ecosystem.