SQLite CLI EUVD-2026-113834

Exploitation requires a specific multi-step local workflow, not a passive or default-config trigger: (1) the victim must obtain and open an attacker-crafted SQLite database whose sqlite_schema.sql value holds a syntactically valid CREATE statement immediately followed by a '.shell' or '.system' dot-command line; (2) the victim must run the sqlite3 CLI '.recover' command against that database; and (3) the victim must pipe the .recover output back into a sqlite3 process (e.g. 'sqlite3 evil.db .recover | sqlite3 out.db'), at which point the planted dot-command is re-interpreted and executed. Limiting factors that reduce real-world risk: the vector is local (AV:L), passive user interaction is required (UI:P - the victim must actively run the recovery/pipe workflow), execution occurs only with the victim's own privileges, and the specific .recover-into-sqlite3 pipeline is a non-default administrative/recovery operation rather than ordinary database use. No authentication is required (PR:N) because the trust boundary crossed is the untrusted database file itself.

This is a genuine but context-dependent integrity/execution risk rather than a mass-exploitation emergency. The authoritative CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H) scores 8.5 and makes the key constraint explicit: the attack vector is LOCAL and requires passive user interaction (UI:P) - the victim must process an attacker-crafted database with the sqlite3 shell. This is NOT remote unauthenticated code execution despite the high score; the high confidentiality/integrity/availability impact reflects full OS command execution on the victim, but only once the victim performs a specific .recover workflow. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a serious-but-not-under-active-mass-exploitation issue. No EPSS score and no KEV listing were provided in the input, so there is no signal of confirmed active exploitation; absence of these is not evidence of safety but should not be read as active exploitation either. A public research write-up (abraxaslabs) and a VulnCheck advisory are referenced, so exploit detail is public even though the input does not mark working exploit code as confirmed. Net: prioritize for remediation this cycle for anyone who ingests untrusted .db files with the CLI, but it is not a drop-everything internet-facing RCE.

An attacker distributes a malicious SQLite database file (e.g. as an email attachment, download, or shared forensic/recovery artifact) whose sqlite_schema.sql value contains a valid CREATE statement followed by a '.shell' or '.system' dot-command line. A victim attempting to recover or rebuild the database runs the sqlite3 CLI .recover command and pipes its output into a sqlite3 instance; the planted dot-command is emitted verbatim and executed, running arbitrary OS commands with the victim's privileges. A public PoC reference exists (abraxaslabs research and VulnCheck advisory); it is not verified as working exploit code in the provided input.