CVE-2026-50006: Anyquery SQL Engine RCE Vulnerability

CVE-2026-50006 Overview

CVE-2026-50006 is a path traversal vulnerability [CWE-22] in Anyquery, an SQL query engine built on top of SQLite. Versions prior to 0.4.5 expose a MySQL-compatible server port that forwards unauthenticated SQL directly to SQLite without restricting ATTACH DATABASE filesystem targets. A remote attacker can attach a database at any path writable by the Anyquery server process and populate it with attacker-controlled table content. This produces arbitrary file creation or overwrite on the host filesystem. The issue is fixed in version 0.4.5, which introduces sandboxing controls for the server.

Critical Impact

Unauthenticated remote attackers can create or overwrite arbitrary files on the Anyquery server host, leading to filesystem integrity loss, denial of service, and potential remote code execution when a secondary service interprets the written file.

Affected Products

• Anyquery versions prior to 0.4.5
• Anyquery server (MySQL-compatible listener)
• Anyquery deployments exposing the MySQL protocol port to untrusted networks

Discovery Timeline

• 2026-09-14 - CVE-2026-50006 published to the National Vulnerability Database (NVD)
• 2026-09-15 - Last updated in NVD database

Technical Details for CVE-2026-50006

Vulnerability Analysis

Anyquery ships a MySQL wire-protocol compatible server that accepts SQL statements and forwards them to an embedded SQLite engine. The server does not authenticate clients and does not filter SQL verbs before passing them to SQLite. SQLite's ATTACH DATABASE statement can create a new database file at any filesystem path the process can write to. Once attached, an attacker can create tables, insert rows, and cause SQLite to serialize those pages onto disk at the attacker-selected path.

The primary impact is arbitrary file write. Because SQLite writes structured binary content, the resulting file is not attacker-arbitrary at byte-level granularity, but the file exists at an attacker-chosen location with attacker-influenced content. This is sufficient to overwrite configuration files, cron entries, or webroot artifacts and can lead to code execution when another process consumes the written file.

Root Cause

The root cause is missing input validation and missing sandboxing on the server's SQL execution path. The MySQL-compatible listener trusts all inbound statements, and no allowlist restricts filesystem-touching SQLite features such as ATTACH DATABASE, VACUUM INTO, or the read_* virtual tables. Combined with the absence of authentication on the server port, any network-reachable attacker can invoke privileged SQLite functionality.

Attack Vector

An attacker connects to the exposed Anyquery MySQL port using any MySQL client. The attacker issues ATTACH DATABASE '/target/path/file' AS pwn; followed by CREATE TABLE pwn.t(...); and INSERT statements. SQLite creates the file at the specified path with the attacker-controlled schema and rows written into the SQLite page structure.

The fix in version 0.4.5 introduces sandboxing flags that restrict which directories are eligible for ATTACH and VACUUM INTO, with server sandboxing enabled by default:

// addSandboxFlags registers the sandboxing flags.
//
// For the server, sandboxing is on by default and --no-sandbox disables it; for
// CLI commands, --sandbox opts in (off by default, since local use is trusted).
// The relaxation flags are identical in both cases.
func addSandboxFlags(cmd *cobra.Command, isServer bool) {
	cmd.Flags().StringSlice("allow-dirs", []string{}, "When sandboxed, directories that read_* tables (and on-disk ATTACH) may access (repeatable, comma-separated)")
	cmd.Flags().Bool("allow-remote", false, "When sandboxed, allow read_* tables to fetch remote URLs (http/https/s3/...)")
	cmd.Flags().Bool("allow-attach", false, "When sandboxed, allow ATTACH/VACUUM INTO to on-disk paths within --allow-dirs")
	cmd.Flags().Bool("allow-db-connections", false, "When sandboxed, allow the database reader modules (duckdb/postgres/mysql/clickhouse/cassandra)")
	if isServer {
		cmd.Flags().Bool("no-sandbox", false, "Disable server sandboxing entirely (UNSAFE: exposes local file read, SSRF, and arbitrary file write)")
	} else {
		cmd.Flags().Bool("sandbox", false, "Apply server-style sandboxing restrictions (off by default in CLI mode)")
	}
}

Source: GitHub Commit 27f84fc

Detection Methods for CVE-2026-50006

Indicators of Compromise

• Unexpected .db, .sqlite, or other files created in directories writable by the Anyquery service account
• Modification of sensitive files such as authorized_keys, cron entries, or web server document roots by the Anyquery process
• Anyquery process logs showing inbound connections from unexpected source IPs on the MySQL-compatible port

Detection Strategies

• Inspect Anyquery query logs for ATTACH DATABASE and VACUUM INTO statements originating from network clients
• Monitor filesystem audit events (Linux auditd, Windows Sysmon FileCreate) attributed to the Anyquery process for writes outside its expected data directory
• Flag network connections to the Anyquery MySQL port from any source outside an approved administrative allowlist

Monitoring Recommendations

• Enable process-level file creation telemetry for the Anyquery service account and alert on writes to /etc, /root, /var/spool/cron, and web content directories
• Alert on any inbound TCP session to the Anyquery listener from non-management network segments
• Baseline the Anyquery data directory and generate alerts when new SQLite files appear outside expected paths

How to Mitigate CVE-2026-50006

Immediate Actions Required

• Upgrade Anyquery to version 0.4.5 or later, which enables server sandboxing by default
• Restrict network exposure of the Anyquery MySQL-compatible port using firewall rules or bind to 127.0.0.1 where possible
• Run the Anyquery server as an unprivileged user with a minimal, dedicated data directory to reduce the write blast radius
• Audit filesystem locations writable by the Anyquery process for signs of tampering

Patch Information

The fix is available in Anyquery release 0.4.5. The patch introduces sandboxing that blocks ATTACH DATABASE and VACUUM INTO to on-disk paths unless the operator explicitly opts in via --allow-attach combined with --allow-dirs. Full technical details are in the GHSA-xrcf-6jh3-ggvx advisory and the remediation commit.

Workarounds

• Block inbound traffic to the Anyquery MySQL-compatible port at the network perimeter until the patch is applied
• Run Anyquery under an OS-level sandbox such as systemdProtectSystem=strict with a narrow ReadWritePaths allowlist
• Deploy the process inside a container with a read-only root filesystem and an isolated writable volume for legitimate data

# Post-upgrade: run the Anyquery server with sandboxing enabled (default in 0.4.5)
# and constrain any permitted ATTACH targets to a single directory.
anyquery server \
  --host 127.0.0.1 \
  --port 8070 \
  --allow-dirs /var/lib/anyquery/data

# To temporarily allow ATTACH/VACUUM INTO for a specific workflow:
anyquery server \
  --host 127.0.0.1 \
  --allow-attach \
  --allow-dirs /var/lib/anyquery/data