---
id: "CVE-2026-119586"
kind: "vulnerability"
aliases: ["CVE-2026-119586"]
title: "SQLite shell: crafted database runs OS commands via .recover"
severity: "high"
cvss: 8.5
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "sqlite", "fixed": [], "affected": "<= 3.54.1", "ecosystem": "vendor"}]
ecosystems: []
tags: ["command-injection", "developer-tools", "package", "sqlite", "sqlite3-cli"]
not_affected_if: ["library-only-use", "managed-hosting", "no-untrusted-databases"]
published_at: "2026-10-30T12:16:44+00:00"
first_seen_at: "2026-10-30T12:30:27+00:00"
updated_at: "2026-10-30T12:32:55+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-119586", "first_seen_at": "2026-10-30T12:30:27+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-30T12:32:55+00:00"}]
---

# SQLite shell: crafted database runs OS commands via .recover

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, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:sqlite affected <= 3.54.1 fixed ?

## How to check

- Run sqlite3 --version. 3.54.1 and earlier are listed as affected (the researcher lab-tested 3.53.4); no fixed release exists yet.
- Look for scripts or runbooks that run 'sqlite3 x.db .recover | sqlite3 y.db', or '.recover > data.sql' followed by 'sqlite3 new.db < data.sql', on databases from outside your team.
- Before restoring, run 'grep -n "^\." data.sql'. Any dot-command other than the .dbconfig line that .recover prints itself (for example .shell or .system) means the database was tampered with.

## Fix

No fixed SQLite release as of 3.54.1 (2026-10-16), the latest on sqlite.org/changes.html. Until one ships, do not pipe .recover or .dump output from untrusted databases straight into sqlite3; read the script first.

## Timeline

- 2026-10-30T12:30:27+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-119586
- 2026-10-30T12:32:55+00:00 analyst — Read VulnCheck advisory (CVSS 4.0 8.5, matches NVD; Abraxas Labs credited) and the researcher's write-up with a public PoC (lab-tested on 3.53.4, local, victim must pipe .recover output into a second sqlite3). sqlite.org/changes.html lists no fix through 3.54.1; sqlite.org does not appear to have acknowledged it, so fix is unknown rather than confirmed absent. Nothing verified: no vendor advisory exists. Exploitation in the wild: none seen. Researcher's own score was CVSS 3.1 7.8, so 8.5 is VulnCheck's v4 score.

## Documents

- [advisory] VulnCheck advisory: SQLite CLI through 3.54.1 .recover command injection https://www.vulncheck.com/advisories/sqlite-cli-through-3.54.1-command-injection-via-recover-output
- [describes] SQLite Release History (latest 3.54.1, no .recover fix listed) https://sqlite.org/changes.html
- [mentions] SQLite.org: Vulnerabilities (vendor stance on CVEs) https://sqlite.org/cves.html
- [poc] Abraxas Labs: SQLite CLI .recover emits hostile schema as dot-command https://abraxaslabs.tech/research/sqlite-cli-recover

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_