Description

Anyquery is an SQL query engine built on top of SQLite. Prior to 0.4.5, the clear_plugin_cache(plugin) SQL scalar function in namespace/other_functions.go passes the caller-controlled plugin parameter through path.Join to os.RemoveAll without rejecting traversal segments. A low-privileged bearer-token holder can invoke the function through the /v1/query HTTP endpoint, causing path.Join to resolve .. segments outside $XDG_CACHE_HOME/anyquery/plugins/ and os.RemoveAll to recursively delete any reachable directory writable by the Anyquery server process. This causes permanent data loss and denial of service without disclosing file contents. This issue is fixed in version 0.4.5.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-09-14T20:16:44.070Z",
  "pubdate": "2026-09-14T20:16:44.070Z",
  "executiveSummary": "A critical path traversal vulnerability exists in the clear_plugin_cache(plugin) SQL scalar function of the Anyquery SQL query engine, affecting versions prior to 0.4.5.\nThe vulnerability allows a low-privileged user possessing a valid bearer token to trigger recursive directory deletion on the host filesystem via the /v1/query HTTP endpoint.\nBy injecting path traversal sequences into the plugin parameter, an attacker can escape the intended $XDG_CACHE_HOME/anyquery/plugins/ directory.\nThe impact includes significant data loss and denial of service (DoS) for any filesystem location writable by the Anyquery server process user.\nThis vulnerability highlights a critical failure in input sanitization, allowing arbitrary filesystem manipulation by unprivileged users with API access.\nImmediate remediation requires upgrading to version 0.4.5, where input validation has been implemented to reject traversal segments.",
  "technicalDetails": "The vulnerability resides in the clear_plugin_cache(plugin) SQL scalar function, specifically within the implementation located in namespace/other_functions.go.\nThe root cause is an improper neutralization of special elements in the plugin argument, which is passed directly to the path.Join function without prior sanitization or validation of the input path.\nWhen the clear_plugin_cache function is invoked via the /v1/query HTTP endpoint, the application takes the user-provided plugin name and concatenates it with the base directory for plugins using path.Join. Because path.Join performs lexical cleanup but does not inherently block parent directory traversal (..), the resulting path can resolve to locations outside the intended cache directory.\nThis constructed path is then passed as an argument to os.RemoveAll. In the Go programming language, os.RemoveAll attempts to recursively remove the specified path and all its contents. If the server process is running with sufficient privileges to write to or modify target directories, an attacker can specify arbitrary system paths.\nThe attack flow follows these steps: 1) An attacker authenticates with a low-privileged bearer token to the /v1/query endpoint. 2) The attacker crafts a SQL query invoking the clear_plugin_cache function, injecting a payload such as '../../../../some/target/directory'. 3) The backend processes this string, leading path.Join to resolve the path outside the application's restricted scope. 4) The os.RemoveAll function executes with the malicious path, deleting directories and files recursively.\nThe vulnerability is limited to filesystem deletion; it does not facilitate the disclosure of file contents or arbitrary code execution. However, the risk of permanent data loss is high, as the Anyquery process may have extensive write access depending on the environment configuration (e.g., containerized environments with mounted volumes).\nAffected versions include all releases prior to 0.4.5. The vulnerability is network-exposed due to the accessibility of the /v1/query HTTP endpoint, which necessitates strict access control to prevent unauthorized use of this destructive function."
}