CVE-2026-119375 in SQLite
Summary
by MITRE • 10/30/2026
SQLite before 3.54.0 contains an information disclosure vulnerability that allows attackers to read uninitialized page-cache memory by supplying a WAL file with an undersized page size. Attackers can craft a database and WAL file whose oversized record payload makes queries like substr() return stale bytes, disclosing other table rows and internal pointers.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The SQLite database engine prior to version 3.54.0 is susceptible to an information disclosure vulnerability stemming from improper handling of Write-Ahead Log files with malformed page sizes. This flaw allows attackers to read uninitialized memory within the page cache, leading to the exposure of sensitive data that was not intended for retrieval. The root cause lies in the failure to properly validate or initialize memory buffers when processing WAL files where the specified page size is smaller than expected by the internal logic. When such a malformed file is processed, SQLite allocates and utilizes memory regions without ensuring they are zeroed out or correctly initialized before being returned to application queries.
The technical mechanism of this vulnerability involves crafting a database accompanied by a Write-Ahead Log file that contains an undersized page size definition but includes record payloads that exceed the expected bounds for those pages. When SQLite processes these records, particularly during operations involving string manipulation functions like substr(), it accesses memory locations beyond the intended boundaries of the current data structure. Because the affected memory regions have not been properly initialized with null bytes or valid data placeholders, they retain residual content from previous allocations. This results in queries returning stale bytes that correspond to other table rows, internal pointers, and potentially sensitive application state information stored elsewhere in the process memory space.
From an operational perspective, this vulnerability poses a significant risk of unauthorized data exposure. Attackers who can influence or supply the database files subjected to SQLite processing can extract confidential information such as user credentials, session tokens, personal identifiable information, or proprietary business logic encoded within internal pointers. The ability to read uninitialized memory effectively bypasses standard access controls because the leakage occurs at the storage engine level before higher-level application security checks are applied. This makes detection difficult through conventional means, as the database appears to function normally while silently leaking data in response to specific query patterns designed to trigger the buffer over-read condition.
This vulnerability aligns with CWE-200, which categorizes information exposure resulting from improper handling of sensitive data, and specifically relates to CWE-1341, where uninitialized memory is accessed due to insufficient initialization practices. In terms of offensive security frameworks, this behavior mirrors techniques found in the MITRE ATT&CK catalog under Data from Information Repositories or potentially Memory Dumping if the attacker leverages the leaked pointers for further exploitation. The lack of bounds checking during WAL file parsing represents a critical deviation from secure coding standards that mandate strict validation of input parameters and rigorous memory management protocols to prevent out-of-bounds reads.
Mitigation strategies primarily involve upgrading SQLite to version 3.54.0 or later, where the developers have addressed this issue by implementing stricter validation for page sizes in WAL files and ensuring proper initialization of all allocated cache pages before they are exposed to query execution logic. For environments unable to upgrade immediately, defensive coding practices should be adopted, such as validating file integrity prior to opening them with SQLite and avoiding direct exposure of database files to untrusted inputs. Additionally, implementing memory protection mechanisms like Address Space Layout Randomization can help mitigate the impact by making it harder for attackers to interpret leaked pointers or predict memory layouts, although upgrading remains the only definitive solution to eliminate the underlying flaw in the storage engine itself.