Live › vulnerability › CVE-2026-119586
The SQLite command-line shell's .recover command copies schema text from a database without filtering it, so a planted line such as .shell or .system is written out as a dot-command. When a victim pipes that recovered output back into sqlite3, the attacker's commands run on the victim's machine.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-30 12:30 UTC. All times on this page are UTC.
Exposure requires a victim to open a malicious database with the sqlite3 shell's .recover command and feed the output back into sqlite3. Applications that link the SQLite library without the command-line shell are not exposed by this flaw. Teams that run recovery of untrusted database files from the shell should look at that workflow first.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| sqlite | vendor | <= 3.54.1 | – |
3.54.1 (2026-10-16), the latest on sqlite.org/changes.htmlEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-119586")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.