SQLite EUVD-2026-113788

Exploitation requires a specific non-default stack: (1) the host application must call sqlite3_set_authorizer() and use it to deny SQLITE_READ access to particular columns - SQLite performs no such read restriction by default; (2) the attacker must be able to submit or influence SQL executed against that connection; and (3) the attacker must construct a RIGHT or FULL OUTER JOIN whose USING clause names the restricted column, since the flaw lies in lookupName() invoking the authorizer only for the first joined table's USING column. Limiting factors: impact is confined to reading values of a shared USING column that the authorizer should have denied (confidentiality only, no write or DoS); the vulnerable JOIN syntax requires SQLite 3.39.0+ where RIGHT/FULL JOIN exists; and the attacker needs at least enough privilege to issue SQL (PR:L), so it is not an unauthenticated-by-default flaw. Fixed in SQLite 3.54.0; the vendor remediation is to update.

This is a low-priority issue across every available signal. The vendor CVSS 4.0 base score is 2.0 (Low), with AV:L (local), AT:P (a specific precondition must hold), PR:L (the attacker must already be able to submit SQL), and impact limited to VC:L (minor confidentiality) with no integrity or availability effect. The vuln.today decision label is 'monitor', the weakest urgency tier, and this is consistent with the low CVSS. No CISA KEV listing and no EPSS score were provided in the input, so there is no signal of active or probable exploitation; absence of these is not itself an error but means widespread-exploitation evidence is simply not present. A public technical writeup/PoC reference exists (abraxaslabs research and the VulnCheck advisory), and the vendor commit ships a reproducing test case, so the trigger is well understood - but a reference is not confirmation of active exploitation, and the two signals should not be conflated. The real-world risk is gated hard by preconditions: exploitation only matters for applications that both accept attacker-supplied SQL and use sqlite3_set_authorizer() with SQLITE_READ column restrictions, which is a non-default, relatively uncommon deployment. Net: a genuine authorization-bypass bug, but a low-severity, narrow-scope confidentiality issue rather than an emergency.

An application embeds SQLite and uses sqlite3_set_authorizer() to deny reads of specific sensitive columns, while allowing a user to submit (or influence) SQL queries. The attacker issues a RIGHT or FULL JOIN that references the denied column as a shared USING column; because lookupName() invoked the authorizer only for the first joined table's USING term, the restricted column's values are returned instead of being blocked. A public technical writeup and vendor test case demonstrate the trigger, though the input does not confirm weaponized exploit code.