CVE-2026-103591 in DeepWiki-Open
Summary
by MITRE • 10/01/2026
DeepWiki-Open through commit d92819a contains an unauthenticated arbitrary file read vulnerability in the GET /codemap/file endpoint via the repo_url parameter. Attackers can supply a non-URL repo_url value to bypass path containment checks and read any file accessible to the API process by specifying absolute file paths.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/01/2026
The DeepWiki-Open software, specifically through commit d92819a, suffers from an unauthenticated arbitrary file read vulnerability located within its GET /codemap/file endpoint. This security flaw is triggered when processing the repo_url parameter, which is intended to specify a repository location for code mapping operations. The core technical deficiency lies in the insufficient validation and sanitization of user-supplied input before it is used to construct filesystem paths. Instead of strictly enforcing URL-based inputs or validating that the resulting path remains within an allowed directory structure, the application fails to properly contain the file access scope. This allows attackers to bypass standard path containment checks by supplying a non-URL value for the repo_url parameter. By manipulating this input, specifically through the use of absolute file paths such as /etc/passwd or other sensitive system files, an attacker can instruct the API process to read and return the contents of any file that the underlying service account has permission to access.
From a technical perspective, this vulnerability represents a classic path traversal issue exacerbated by weak input validation mechanisms. The application likely concatenates user-supplied strings directly into filesystem operations without adequately resolving or restricting the resulting absolute paths. This lack of normalization allows for directory escape sequences or direct specification of system-critical files that reside outside the intended web root or repository directories. Because the vulnerability is unauthenticated, it does not require any prior login credentials or valid session tokens to exploit. An attacker can interact with this endpoint directly via standard HTTP requests from an external network position, making it a high-risk exposure vector for remote code execution scenarios where file contents are subsequently parsed and executed by other components of the system.
The operational impact of this vulnerability is severe, primarily centered on unauthorized data disclosure and potential compromise of host integrity. By reading arbitrary files, attackers can extract sensitive information such as database credentials stored in configuration files, private keys used for encryption or authentication services, source code containing hardcoded secrets, or operating system user lists that aid in further reconnaissance. In many web application architectures, the API process runs with elevated privileges to access necessary resources; therefore, this file read capability effectively grants an attacker root-level visibility into the server's filesystem. This can serve as a stepping stone for more advanced attacks, including remote code execution if sensitive files like cron jobs or startup scripts are modified and then triggered by other system processes.
This vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes flaws where software does not properly neutralize special elements within file paths that can cause the path to resolve outside of the intended directory. Additionally, in terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1083: File and Directory Discovery, as it enables an adversary to enumerate and access files on a compromised system without detection by standard authentication logs. The unauthenticated nature also touches upon CWE-287: Improper Authentication, although the primary flaw is input validation rather than identity verification failure per se.
To mitigate this vulnerability, immediate remediation should focus on implementing strict allow-listing for file paths and enforcing canonicalization of all user-supplied inputs before they are used in filesystem operations. Developers must ensure that any path constructed from external parameters is resolved to its absolute form and then verified against a predefined base directory using string comparison or secure library functions like realpath with subsequent checks. It is critical to reject any input that attempts to traverse outside the allowed scope, including requests containing null bytes, relative navigation sequences such as ../, or direct absolute paths pointing to system directories. Furthermore, applying principle of least privilege to the API process account can limit the damage if exploitation occurs by restricting file read permissions to only those necessary for application functionality. Regular security audits and static code analysis tools configured to detect path traversal patterns should be integrated into the development lifecycle to prevent similar issues in future releases.