SQLite CLI through 3.54.1 Command Injection via .recover Output
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
SQLite command-line shell through 3.54.1 contains a command injection vulnerability in the .recover command that emits attacker-planted dot-commands stored in sqlite_schema.sql values verbatim. Attackers can craft a database whose schema holds a valid CREATE statement followed by a .shell or .system line, executing OS commands when victims pipe .recover output into sqlite3.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- SQLite SQLite
through 3.54.1
References 5
GitHub · sqlite/sqlite
abraxaslabs.tech
Questions about CVE-2026-119586
What does this mean?
When the SQLite command-line tool's .recover output is piped into a second sqlite3 process, a line in the recovered schema that starts with a dot is run as a shell-style command under the operator's user account. A crafted corrupt database can plant such a line.Source: abraxaslabs.tech
Am I affected, and how do I check?
The facts list SQLite through 3.54.1 as the affected range, with 3.53.4 (b09c88c) named as a tested build. The exposure applies to the sqlite3 CLI's .recover and .dump output, not to the libsqlite3 library, and to restore runs that are not in --safe mode. Check your version with sqlite3 --version and whether the restore command uses --safe.Source: abraxaslabs.tech
What should I do about it?
No fixed version is listed in the checked facts, so no upgrade target can be given from these sources. Re-check the SQLite release notes for a version after 3.54.1 before relying on one.Source: abraxaslabs.tech
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What if there's no patch?
Until a fix is confirmed, restore recovered databases with sqlite3 run in --safe mode rather than through a plain pipe. Avoid piping .recover output into an unsandboxed sqlite3 process.Source: abraxaslabs.tech