GHSA-ggh8-3chg-48w7: 
PHP Análisis y mitigación de vulnerabilidades

Summary

The ATTACH/VACUUM-INTO blocklist that GHSA-q5mp-gfjf-cf2j (CVE-2026-96630) added at admin/sql.inc.php:147 anchors with ^$space*+ where $space matches only PCRE whitespace or SQL comments. A leading UTF-8 BOM (EF BB BF) is none of those, so the regex returns 0 (ALLOWED), while SQLite's sqlite3_prepare_v2 silently skips the BOM and executes the statement. This is an incomplete-fix bypass of the exact regex the fix introduced.

Root Cause

admin/sql.inc.php:147 (v5.8.0):

if (DIALECT == "sqlite" && preg_match("~^$space*+(ATTACH|VACUUM\\b.*\\bINTO)\\b~is", $q, $match) !== 0) {

with $space = (?:\s|/\*[\s\S]*?\*/|(?:--)[^\n]*\n?|--\r?\n). PCRE \s does NOT match EF BB BF, and $space cannot consume it, so a BOM-prefixed VACUUM INTO/ATTACH fails the anchor → match=0 → statement is forwarded to Connection::get()->multiQuery($q) → SQLite3::query(). SQLite's tokenizer skips the leading BOM and executes the statement, writing the file.

Impact

Authenticated SQLite user writes an attacker-controlled SQLite database file (PHP polyglot in a table name) to a web-served path → PHP web shell → RCE. Identical impact and precondition to GHSA-q5mp-gfjf-cf2j (CVE-2026-96630).

Proof of Concept

query field begins with raw bytes EF BB BF then VACUUM INTO '/var/www/html/x.php', submitted with a valid token.

Attack Chain

1. Entry: POST /admin/?sqlite=... with query = bytes EF BB BF + VACUUM INTO '/var/www/html/x.php' + valid token.
   • Guard: verify_token() + Sec-Fetch-Site (auth.inc.php:391).
   • Bypass: authenticated user's own valid token + same-origin submit (same precondition as GHSA-q5mp-gfjf-cf2j).
2. Processing: admin/sql.inc.php:34 $query = $_POST["query"] — BOM preserved (no trim); statement splitter yields $q still starting with the BOM (first bytes ef bb bf 56 41 43).
3. Check: admin/sql.inc.php:147 preg_match("~^$space*+(ATTACH|VACUUM\\b.*\\bINTO)\\b~is", $q) → returns 0.
   • Guard: this IS the v5.5.1 fix.
   • Bypass proof: regex test — BOM VACUUM match=0 ALLOWED, BOM ATTACH match=0 ALLOWED; plain forms match=1 BLOCKED. PCRE \s does not match EF BB BF.
4. Sink: admin/sql.inc.php Connection::get()->multiQuery($q) → admin/drivers/sqlite.inc.php:34 @$this->sqlite->query($q) → sqlite3_prepare_v2 strips the BOM and executes.
   • Bypass proof: sqlite3 (libsqlite) executes BOM-prefixed VACUUM INTO — file written = True (reproduced via Python sqlite3.execute).
5. Impact: PHP web shell written to a web path → RCE. ATTACH bypassed identically.

Bypass Evidence

Regex test (exact line-147 pattern):

plain VACUUM   match=1 BLOCKED
BOM VACUUM     match=0 ALLOWED   <-- bypass
plain ATTACH   match=1 BLOCKED
BOM ATTACH     match=0 ALLOWED   <-- bypass

SQLite execution: '\ufeff' + "VACUUM INTO '<path>'" via sqlite3 → file_written=True. Control: identical string WITHOUT the BOM is BLOCKED (match=1) — the BOM is the sole differentiator; the fix works for every non-BOM case. Both SQLite3 and PDO_SQLite drivers wrap the same C sqlite3_prepare_v2. Verified: regex and export sink present on latest release v5.8.0 (line 147, unchanged).

Affected Versions

>= 5.5.1, <= 5.8.0 (the BOM-vulnerable regex was introduced by the v5.5.1 fix).

Suggested Fix

Strip/normalize a leading UTF-8 BOM before the blocklist check, OR make the $space anchor Unicode-aware (e.g. also consume \x{FEFF}), OR validate the normalized statement SQLite will actually execute rather than the raw bytes.

Reported by zx (Jace) — GitHub: @manus-use