SQLite CVE-2026-119591

Exploitation requires the attacker to control SQL submitted to SQLite, or to supply a SQLite database file containing a crafted view, such that a count(*) is evaluated over a large multi-row VALUES clause - the specific trigger that drives the count-of-view optimization into deeply nested TK_PLUS expressions and overflows the C stack during recursive expression freeing. Limiting factors per the CVSS 4.0 vector: the vector is Local (AV:L) with passive user interaction (UI:P), so the malicious SQL or database file must reach and be parsed by a SQLite instance - applications that only ever run trusted, fixed queries over trusted databases are not reachable. Impact is denial of service only (VA:H, with VC:N/VI:N): a crash of the host process, with no confidentiality or integrity effect and no code execution.

This is a medium-severity denial-of-service issue, and the signals are consistent rather than conflicting. The vendor CVSS 4.0 base score is 6.8 with vector AV:L/AC:L/AT:N/PR:N/UI:P and impact confined to availability (VA:H; VC:N/VI:N) - i.e. a crash, not code execution or data compromise, matching CWE-674 (uncontrolled recursion). The attack vector is Local with passive user interaction, so this is not a remotely-reachable network bug by default; it requires the attacker's SQL or database file to actually reach a SQLite instance that will parse it. There is no CISA KEV listing and no EPSS score in the supplied data, so there is no evidence of active or widespread exploitation. The vuln.today decision label is 'this_month', indicating a routine-but-non-ignorable patch priority rather than an emergency. Net assessment: real but bounded risk - genuinely exploitable and reliable where an application feeds untrusted SQL or opens untrusted SQLite database files, but low urgency where SQLite only ever processes trusted, application-controlled queries. The headline worry is SQLite's enormous deployment footprint, not the per-instance severity.

An application lets an attacker influence SQL (e.g. an analytics/query feature) or open an attacker-supplied SQLite database file containing a crafted view. The attacker issues a count(*) over a very large multi-row VALUES clause, which the count-of-view optimization turns into a deeply nested chain of TK_PLUS expressions; recursive teardown in sqlite3ExprDeleteNN() exhausts the C stack and crashes the host process. A public research write-up (abraxaslabs.tech) and a VulnCheck advisory describe the issue, but the input does not confirm packaged working exploit code.