CVE-2026-119377 in SQLite
Summary
by MITRE • 10/30/2026
SQLite before 3.54.0 contains an authorization bypass vulnerability in lookupName() that invokes the authorizer only for the first joined table's USING column. Attackers able to submit SQL can query a shared USING column in a RIGHT or FULL JOIN to read columns denied via sqlite3_set_authorizer() SQLITE_READ restrictions.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The SQLite database engine, prior to version 3.54.0, contains a critical authorization bypass vulnerability located within the lookupName function. This flaw stems from an incomplete implementation of access control checks during the parsing and execution phases of SQL queries involving JOIN operations. Specifically, when processing RIGHT or FULL JOIN statements that utilize a USING clause to specify shared columns between tables, the internal authorizer mechanism fails to validate permissions for all relevant table contexts. The vulnerability arises because the engine invokes the sqlite3_set_authorizer callback only once, applying it exclusively to the first joined table associated with the specified USING column. This oversight creates a logical gap in the security boundary that separates user input from database access controls.
From a technical perspective, this defect allows an attacker who has the ability to submit arbitrary SQL statements to circumvent read restrictions enforced by the application layer or the SQLite authorizer API. In standard operation, developers use sqlite3_set_authorizer() to define granular permissions, such as denying SQLITE_READ operations on specific tables or columns for unprivileged users. However, due to this bug, if a query joins two tables using a shared column name via RIGHT or FULL JOIN syntax, the authorization check is bypassed for subsequent tables in the join sequence. Consequently, an attacker can construct a malicious SQL payload that references data from these secondary tables through the joined key, effectively reading sensitive information that should have been restricted by the configured access policies.
The operational impact of this vulnerability is significant, particularly in applications where SQLite serves as the backend storage for multi-tenant systems or environments with strict role-based access control requirements. An attacker exploiting this flaw can exfiltrate confidential data such as user credentials, personal identifiable information, financial records, or proprietary business logic stored in tables that were explicitly marked as read-only or inaccessible to their current session level. This represents a classic case of privilege escalation through input manipulation, where the structural complexity of SQL queries is leveraged to bypass security controls designed for simpler query patterns. The integrity and confidentiality guarantees provided by the database layer are thereby compromised without requiring any additional authentication credentials beyond what was already granted to the attacker's initial connection.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, as it allows a lower-privileged user to access resources reserved for higher-privileged roles or restricted contexts. Furthermore, in terms of offensive security frameworks such as MITRE ATT&CK, this behavior corresponds to techniques involving SQL injection and privilege escalation via application logic flaws rather than traditional buffer overflows or memory corruption issues. The exploitation relies on the attacker's ability to craft specific JOIN queries that trigger the code path where the authorizer is not invoked for all participating tables.
To mitigate this risk, organizations relying on SQLite versions prior to 3.54.0 must upgrade immediately to version 3.54.0 or later, which includes a patch ensuring that authorization checks are consistently applied across all tables involved in JOIN operations regardless of the join type. For environments where an immediate upgrade is not feasible due to compatibility constraints, developers should implement additional validation layers at the application level. This can include sanitizing SQL inputs more rigorously, avoiding complex JOIN structures with USING clauses for untrusted users, or implementing a secondary authorization check within the application logic before executing any query that involves multiple tables. Regular security audits and static code analysis focused on database interaction patterns are also recommended to identify similar logical flaws in custom data access layers.