Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-14T20:16:46.867Z",
  "pubdate": "2026-09-14T20:16:46.867Z",
  "executiveSummary": "Anyquery prior to version 0.4.5 contains a critical vulnerability involving the improper exposure of SQLite virtual table modules. The Anyquery server process provides a MySQL-compatible port that lacks mandatory authentication and authorization controls, allowing remote, unauthenticated access to the underlying SQL engine.\nThe vulnerability stems from the ability of a remote attacker to instantiate file-backed SQLite virtual table modules, specifically csv_reader and log_reader, without any directory or filesystem path validation. By executing a CREATE VIRTUAL TABLE statement, an attacker can coerce the server process into reading arbitrary local files.\nBecause the server process utilizes hashicorp/go-getter to interact with these modules, the vulnerability allows an attacker to retrieve the contents of sensitive system files, configuration files, private keys, and credentials accessible to the service user.\nThe risk is severe, as it facilitates remote information disclosure and unauthorized data exfiltration with minimal interaction requirements. The exploitation is restricted only by the filesystem permissions assigned to the Anyquery server process. Organizations utilizing Anyquery must upgrade to version 0.4.5 or later to mitigate this risk.",
  "technicalDetails": "The vulnerability resides in the architectural design of the Anyquery server component, which exposes a MySQL-compatible interface to the network. This interface provides direct access to the SQLite execution environment without implementing a robust authentication layer or authorization framework to gate database operations.\nThe core issue involves the mishandling of SQLite virtual table modules—specifically csv_reader and log_reader—which are permitted to interact with the local filesystem through the server process. These modules are intended for processing structured data but fail to enforce directory restrictions or path sanitization.\nThe exploitation flow begins when an unauthenticated remote attacker connects to the Anyquery server's MySQL-compatible port. The attacker issues a crafted CREATE VIRTUAL TABLE SQL command, pointing the module's target source to an arbitrary file path on the host system (e.g., /etc/passwd or /root/.ssh/id_rsa).\nUpon execution, the Anyquery server, utilizing the hashicorp/go-getter library under the privileges of the server process, attempts to resolve and parse the specified resource as a tabular data structure. Because the application logic does not restrict the filesystem access scope, the engine successfully reads the contents of the target file and exposes them as rows within the virtual table.\nOnce the virtual table is established, the attacker can execute standard SELECT queries against the table to extract the entire contents of the sensitive file into the query response. This bypasses typical access controls because the SQLite engine performs these operations as the server process itself.\nThe vulnerability is present in all versions prior to 0.4.5. The impact is significant: an attacker can exfiltrate sensitive environment variables, service credentials, session tokens, and system-level configurations. There are no requirements for valid user credentials, and the network exposure is global for any listener bound to a reachable interface. The process environment effectively serves as a proxy for the attacker to read the contents of the server's filesystem.\nThis behavior represents an improper neutralization of special elements used in a command/file path, leading to an information disclosure vulnerability that persists as long as the server process maintains elevated or broad filesystem access permissions."
}