CVE-2026-54629 in Anyquery
Summary
by MITRE • 09/14/2026
Anyquery is an SQL query engine built on top of SQLite. Prior to 0.4.5, anyquery server exposes file-backed SQLite virtual table modules such as csv_reader and log_reader through its MySQL-compatible server port without authentication, authorization, or directory restrictions. A remote attacker can use SQLite CREATE VIRTUAL TABLE statements to provide a local path to these modules, which use hashicorp/go-getter under the Anyquery server process and return the selected file contents as queryable table rows. The disclosure is limited only by the filesystem permissions of the server process and can expose system configuration, credentials, and private keys. This issue is fixed in version 0.4.5.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified involves Anyquery, an SQL query engine built upon SQLite that provides a MySQL-compatible interface for querying various data sources. Prior to the release of version 0.4.5, the server component contained a critical security flaw related to how it handled file-backed virtual table modules such as csv_reader and log_reader. These modules are designed to allow users to treat files on the local filesystem as database tables, enabling SQL queries against their contents. However, in vulnerable versions, these capabilities were exposed through the MySQL-compatible port without implementing any form of authentication or authorization mechanisms. This architectural oversight meant that any remote actor with network access to the service could interact directly with these modules, bypassing standard security controls typically expected for database interfaces.
The technical root cause lies in the unrestricted ability of a client to execute SQLite CREATE VIRTUAL TABLE statements against exposed endpoints. By crafting specific SQL queries, an attacker can instruct the Anyquery server process to load local file paths into virtual tables using underlying libraries like hashicorp/go-getter. Because there are no directory restrictions or path validation checks implemented within these modules prior to version 0.4.5, the system does not prevent access to arbitrary locations on the filesystem where the service is running. The scope of data exposure is strictly limited only by the file permissions assigned to the Anyquery server process itself. If the service runs with elevated privileges or has read access to sensitive directories, an attacker can retrieve virtually any readable file from that environment.
The operational impact of this vulnerability is severe, as it effectively allows for unauthenticated remote code execution in terms of data exfiltration rather than direct command execution on the host operating system. Attackers can systematically enumerate and download critical system configuration files, user credentials stored in plaintext or hashed formats, SSH private keys, database connection strings, and other sensitive artifacts. This level of access facilitates further lateral movement within a network infrastructure, as stolen credentials often serve as footholds for deeper compromise. The lack of authentication means that the attack surface is maximized, allowing any entity on the same network segment or with routed access to exploit this flaw without needing valid user accounts or tokens.
From an industry standards perspective, this vulnerability aligns closely with CWE-284, which describes Improper Access Control, specifically regarding the failure to enforce proper authorization checks before granting access to resources. Additionally, it relates to CWE-538, Insertion of Sensitive Information into Externally-Accessible File or Resource, as sensitive data is made accessible through an external interface without adequate safeguards. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1005, Data from Local System, where adversaries collect data directly from the local system using automated tools and scripts after gaining initial access. The exploitation method also reflects aspects of T1213, Data from Information Repositories, as attackers query structured repositories (the SQL interface) to extract unstructured or semi-structured sensitive files.
To mitigate this vulnerability, organizations running Anyquery must immediately upgrade to version 0.4.5 or later, where the developers have addressed these access control deficiencies. In addition to upgrading, it is recommended that administrators enforce authentication on all MySQL-compatible ports if they are exposed to untrusted networks. Implementing network-level restrictions such as firewalls or reverse proxies can further limit exposure by allowing only authorized IP addresses to connect to the service. Furthermore, running the Anyquery process with minimal necessary filesystem permissions ensures that even in the event of a future vulnerability, the blast radius is contained to non-sensitive directories. Regular auditing of exposed services and enforcing strict input validation on all database interfaces are essential practices for maintaining robust security posture against similar exploitation techniques.