CVE-2026-89229 in BlueLM Copilot
Summary
by MITRE • 11/03/2026
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') in the ShareActivity component of BlueLM Copilot (com.vivo.ai.copilot) allows a malicious application installed on the same device to write arbitrary files via a crafted ACTION_SEND intent with a ContentProvider-supplied file name containing '..' sequences.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in the ShareActivity component of BlueLM Copilot, specifically within the com.vivo.ai.copilot package, represents a classic instance of improper limitation of a pathname to a restricted directory, commonly known as path traversal or directory traversal. This flaw arises from insufficient validation and sanitization of user-supplied input when handling file paths provided through Android intents. The ShareActivity component is designed to facilitate the sharing of content between applications on an Android device. When it receives an ACTION_SEND intent containing data supplied by a ContentProvider, it processes the associated filename without adequately checking for directory traversal sequences such as double dots (..). This lack of rigorous input validation allows external entities to manipulate the intended file path structure, effectively bypassing security boundaries that are meant to restrict write operations to specific, safe directories.
From a technical perspective, the core issue lies in how the application constructs and resolves file paths before performing write operations. When an attacker crafts an ACTION_SEND intent with a ContentProvider-supplied filename containing '..' sequences, they can alter the relative path resolution mechanism inherent in most operating systems. By including these traversal characters, the malicious input causes the system to navigate up one or more directory levels from the intended target location. Consequently, instead of writing data into the designated application-specific sandboxed storage area where it is safely contained and isolated from other apps, the write operation targets arbitrary locations on the device's file system. This behavior violates the principle of least privilege and fails to enforce strict access controls over resource paths, which are fundamental requirements for secure software design in mobile environments.
The operational impact of this vulnerability is significant due to its potential for local exploitation by any malicious application installed on the same device. Since Android applications typically operate within their own sandboxed environment, cross-application attacks require a specific vector such as an exported activity or service that accepts intents from other apps. In this case, the ShareActivity component serves as that entry point. An attacker can develop a rogue application that constructs and sends a specially crafted intent to BlueLM Copilot's ShareActivity. Upon execution, the vulnerable code processes the malicious filename, leading to arbitrary file writes on the device storage. This capability enables several severe consequences including data corruption of system or user files, installation of additional malware payloads by overwriting executable binaries or configuration files, and potential privilege escalation if critical security configurations are modified. Furthermore, it compromises the integrity of the host application's local state, potentially leading to denial-of-service conditions or further exploitation chains depending on which specific files are targeted.
This vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory and is often associated with ATT&CK technique T1564: Host File System Discovery when used in conjunction with other techniques for persistence or impact, though the primary classification here remains related to input validation failures. To mitigate this risk, developers must implement strict input sanitization routines that validate all filenames received via intents against a whitelist of allowed characters and explicitly reject any path traversal sequences such as '..' or null bytes. Additionally, using absolute paths resolved through secure APIs like getFilesDir() or getExternalFilesDir(), rather than relying on relative path concatenation with user-supplied strings, ensures that files are always written to the intended sandboxed directory regardless of input manipulation. Implementing these controls effectively neutralizes the attack vector by ensuring that even if malicious intent data is received, it cannot influence the actual file system location where writes occur, thereby preserving application integrity and device security posture.