CVE-2026-112005 in WhoDB
Summary
by MITRE • 10/18/2026
WhoDB 0.104.0 before 0.135.0 contains a path traversal vulnerability that allows remote attackers to read and write arbitrary host files by running DuckDB filesystem functions through the query editor. Attackers can log in to a DuckDB file without credentials and use read_text, read_blob, COPY ... TO or ATTACH to steal session.key and stored database credentials or overwrite files.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
WhoDB versions prior to 0.135.0 are susceptible to a critical path traversal vulnerability that stems from the improper validation of file paths within its query editor interface. This flaw allows remote attackers, even those without valid authentication credentials for DuckDB itself, to execute filesystem operations by leveraging specific DuckDB functions such as read_text, read_blob, COPY TO, and ATTACH. The core technical deficiency lies in the application's failure to sanitize or restrict user-supplied input when constructing file paths for these database commands. By manipulating path strings with directory traversal sequences like dot-dot-slash, an attacker can bypass intended access controls and direct the DuckDB engine to interact with arbitrary files on the host operating system rather than limiting operations to designated database directories. This lack of strict boundary enforcement effectively turns the query editor into a powerful tool for unauthorized file system manipulation.
The operational impact of this vulnerability is severe due to its potential for both data exfiltration and system compromise. Attackers can utilize functions like read_text or read_blob to extract sensitive information stored on the host, including session keys, configuration files, and database credentials that may be cached in plaintext or accessible through standard file paths. The ability to write arbitrary files via commands such as COPY TO introduces additional risks, potentially allowing an attacker to overwrite critical system configurations, inject malicious scripts, or establish persistence mechanisms by placing web shells or backdoors in writable directories. Since the vulnerability permits access without requiring DuckDB authentication, it significantly lowers the barrier for exploitation, enabling unauthenticated remote attackers to achieve arbitrary read and write capabilities on the underlying server infrastructure.
From a classification perspective, this issue aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes vulnerabilities where software does not properly neutralize special elements within file paths that could resolve to files or directories outside of the intended restricted directory. Furthermore, the exploitation technique maps directly to MITRE ATT&CK techniques related to Data from Local System and Command and Control via File Transfer, specifically under T1083: File and Directory Discovery when used for reconnaissance, and potentially T1564: Hidden Files and Directories if attackers use it to place concealed files. The attack vector is classified as Network-based with Low Complexity, indicating that no additional conditions are required beyond network access to exploit the flaw.
Mitigation strategies must prioritize immediate patching of WhoDB to version 0.135.0 or later, where these path traversal issues have been addressed through improved input validation and stricter sandboxing of filesystem operations. In environments where upgrading is not immediately feasible, administrators should restrict network exposure of the query editor interface by placing it behind a reverse proxy with strict access control lists that limit connectivity to trusted IP addresses only. Additionally, running WhoDB within a containerized environment or virtual machine with minimal file system permissions can mitigate the impact by preventing processes from accessing sensitive host paths. Implementing robust input validation on any custom integrations and disabling unnecessary DuckDB filesystem functions if they are not required for legitimate operations will further reduce the attack surface available to potential adversaries.