SQLite FTS5 CVE-2026-119374

Exploitation requires all of the following concrete preconditions: (1) SQLite must be built with the FTS5 full-text-search extension compiled in; (2) secure-delete mode must be enabled (SQLite's secure_delete pragma is OFF by default, so this is a non-default configuration); (3) the attacker must supply a database file containing an FTS5 index with corrupted/crafted footer key offsets; and (4) the victim application must open that untrusted database and execute a DELETE against the FTS5 table, which is the operation that invokes fts5DoSecureDelete(). Limiting factors that reduce realistic risk: the attack vector is LOCAL (the malicious database must first reach the target and be processed, not sent over a network), it needs the victim/application to perform the delete (UI:P / user interaction), FTS5 is not always compiled in, and secure-delete is not enabled by default - so default SQLite deployments that do not process attacker-controlled database files are not exposed.

The input CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, VC:H/VI:H/VA:H) yields 8.5 (high), but the signals pull in different directions. Attack vector is LOCAL and requires passive user interaction (UI:P), meaning an attacker must get a crafted SQLite database in front of a victim application and have it operated on - this is not remote, network-facing exploitation. The vuln.today decision label is 'this_week', not act_now or emergency. There is no CISA KEV listing (not confirmed actively exploited) and no EPSS score was provided, so widespread or automated exploitation is not evidenced. A public PoC reference exists (VulnCheck/abraxaslabs research plus a reproducer database embedded in the vendor's fts5corruptB.test), though the input does not confirm it as a working weaponized exploit. Note a discrepancy to verify: the published CVSS claims full confidentiality AND integrity AND availability impact (VC:H/VI:H/VA:H), yet the description only states that heap memory is corrupted and the application crashes - it does not demonstrate data disclosure or code execution, so the confidentiality/RCE claim is not substantiated by the available description. Net: a genuine memory-safety defect worth patching on the stated 'this week' cadence, with elevated priority for software that opens untrusted SQLite files with FTS5 and secure-delete, but the local vector, required user interaction, and non-default preconditions make it lower real-world risk than the 8.5 alone suggests.

An attacker crafts a malicious SQLite database containing an FTS5 index with corrupted footer key offsets and delivers it to a target application that opens untrusted database files with FTS5 compiled in and secure-delete enabled. When the application performs a DELETE against the FTS5 table, fts5DoSecureDelete() writes past the leaf page buffer, corrupting the heap and crashing the process. A reproducer database exists in the vendor's test suite and in the VulnCheck/abraxaslabs research writeup, but the input does not confirm it as verified working exploit code.