SQLite EUVD-2026-113790

Exploitation requires SQLite to be compiled with the session extension (SQLITE_ENABLE_SESSION), which is not enabled in default builds, and requires the target application to call sqlite3changeset_apply() (or apply_v2) on an attacker-controlled changeset. The precise trigger, per the vendor fix, is a changeset that repeats a table name in a second changeset block with a larger column count, driving sessionUpdateFind() to memset beyond the undersized aUpdateMask allocation. Limiting factors: only SQLite versions before 3.54.0 are affected; the attack vector is local (AV:L) and needs the application/user to process the malicious changeset (UI:P), so there is no direct remote-network path and no exposure for applications that do not ingest untrusted changesets.

This is a genuine memory-corruption bug (CWE-787 out-of-bounds write) in SQLite's session extension, confirmed and patched by the vendor at version 3.54.0, with the mechanism verified directly from the commit diff (64459c87) and a regression test (sessioncorrupt.test) that applies a crafted 242-byte changeset. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, VC:H/VI:H/VA:H, score 8.5) indicates a local attack vector with no privileges but requiring passive user/application interaction - i.e. an application must be induced to apply an attacker-supplied changeset - rather than remote unauthenticated network exploitation. The vuln.today decision label is 'this_week', which signals prompt but not emergency remediation; this is consistent with the absence of any CISA KEV listing and no EPSS score in the input (no active-exploitation or mass-exploitation signal is present). The dominant limiting factor, not captured by the CVSS score, is that the session extension must be compiled in (SQLITE_ENABLE_SESSION is not a default build option) and the application must process untrusted changesets, so real-world exposure is far narrower than SQLite's ubiquity would suggest. Net: a real, well-substantiated priority for the specific population of applications that apply untrusted changesets, but not a broad emergency for typical SQLite deployments. No EPSS and no KEV data were supplied, so widespread exploitation cannot be assessed from the input.

An application built with SQLite's session extension (e.g. a sync or replication client) accepts a changeset from an untrusted source and passes it to sqlite3changeset_apply(). The attacker supplies a crafted changeset that repeats a table name in a second block declaring a larger column count, causing sessionUpdateFind() to memset past the undersized aUpdateMask allocation and corrupt the heap. A public PoC reference exists (the vendor regression test embeds a working trigger changeset and VulnCheck/Abraxas Labs published research); it is not verified in the input as a weaponized working exploit.