CVE-2026-90946 in DeepWiki-Open
Summary
by MITRE • 09/14/2026
DeepWiki-Open through commit d92819a contains an arbitrary file read vulnerability in the unauthenticated /ws/chat WebSocket endpoint that accepts repo_url as a filesystem path with no containment. Attackers can supply arbitrary directory paths to read all files with supported extensions including Python, JavaScript, YAML, and JSON files containing hardcoded secrets and credentials.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The DeepWiki-Open application, specifically up through commit d92819a, suffers from a critical insecure direct object reference vulnerability within its WebSocket communication layer. This flaw is located in the unauthenticated /ws/chat endpoint, which serves as an interface for real-time interaction but lacks proper access controls and input validation mechanisms. The core technical issue arises from how the application processes the repo_url parameter provided by clients connecting to this WebSocket service. Instead of treating this input strictly as a repository identifier or URL string requiring sanitization against web-based protocols, the backend logic incorrectly interprets it directly as a filesystem path on the server hosting the application. This architectural misconfiguration allows an attacker who can establish a connection to the endpoint to manipulate file system operations without any authentication barrier.
The technical manifestation of this vulnerability is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory, often referred to as path traversal or arbitrary file read. Because there are no containment measures such as chroot jails, strict allow-lists for permitted directories, or canonicalization checks to prevent directory traversal sequences like ../ from escaping the intended scope, an attacker can supply absolute paths relative to the server's root filesystem. By injecting specific characters and navigating up through directory levels, the malicious actor gains read access to files that are not part of the public repository structure but reside within the application's execution environment or broader system directories. This lack of input validation represents a fundamental failure in secure coding practices where user-supplied data is used directly in operating system commands or file I/O operations without adequate sanitization.
The operational impact of this vulnerability is severe, primarily due to the exposure of sensitive configuration files and source code artifacts that often contain hardcoded secrets. Attackers can target common locations for credential storage such as .env files, YAML configurations like config.yaml, JSON settings files, Python scripts containing API keys or database passwords, and JavaScript bundles with embedded tokens. The ability to read these files unauthenticated means that an adversary does not need valid user credentials to initiate the attack vector. Once sensitive data is extracted, it can be leveraged for further compromise of downstream systems where those secrets are reused, leading to potential unauthorized access, data exfiltration, and service disruption. This aligns with ATT&CK technique T1083: File and Directory Discovery, as well as T1552.004: Unsecured Credentials in Configuration Files, highlighting the risk of credential harvesting through local file system exploration.
Mitigation strategies must address both the immediate code flaw and broader architectural security postures. The primary remediation involves implementing strict input validation on the repo_url parameter to ensure it only contains expected characters and does not attempt directory traversal sequences such as dots or slashes that could alter path resolution. Additionally, developers should enforce a whitelist approach where only specific, predefined repository identifiers are accepted rather than allowing arbitrary string inputs. From an architectural perspective, running the application with minimal privileges limits the scope of files accessible even if exploitation occurs. Implementing authentication and authorization checks on all WebSocket endpoints is also critical to prevent unauthenticated access entirely. Finally, regular security audits focusing on CWE-20: Improper Input Validation will help identify similar patterns in other parts of the codebase where external data influences internal system resources.