CVE-2026-119371 in SQLite
Summary
by MITRE • 10/30/2026
SQLite before 3.54.0 contains a stack exhaustion vulnerability that allows attackers to bypass the SQLITE_LIMIT_EXPR_DEPTH nesting limit because common table expressions are not counted against it. Attackers can supply a WITH clause chaining tens of thousands of CTEs, via plain SQL or a view in an untrusted database file, causing unbounded selectExpander() recursion that crashes the process.
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 vulnerability identified in SQLite versions prior to 3.54.0 represents a critical failure in resource management and input validation within the query processing engine. Specifically, this flaw allows for stack exhaustion through an improperly handled nesting limit associated with expression depth. The core of the issue lies in how the database engine calculates limits when parsing complex SQL structures. SQLite includes a configuration parameter known as SQLITE_LIMIT_EXPR_DEPTH designed to prevent excessively deep recursion during query evaluation, which serves as a safeguard against denial-of-service attacks and potential stack overflows. However, this limit was not correctly applied to Common Table Expressions (CTEs). CTEs are temporary result sets defined within the scope of a single SELECT, INSERT, UPDATE, or DELETE statement, often used to simplify complex queries by breaking them down into manageable blocks. When an attacker constructs a malicious SQL query utilizing a WITH clause that chains tens of thousands of these expressions together, the engine fails to count each CTE against the configured expression depth limit. This oversight effectively creates a bypass mechanism for one of SQLite's primary defense-in-depth controls.
From a technical perspective, the exploitation vector involves supplying an untrusted database file or SQL input containing deeply nested CTEs. As the parser processes this input, it invokes internal functions such as selectExpander() to resolve and expand these expressions. Because the nesting limit is ignored for CTEs, the recursion depth grows far beyond safe thresholds without triggering early termination checks. This leads to unbounded recursive calls that consume stack space at an exponential rate relative to the number of chained CTEs. The immediate operational impact is a process crash due to stack overflow, resulting in a Denial of Service condition for any application relying on SQLite as its embedded database engine. In scenarios where SQLite is used within web services or API backends, this can lead to service unavailability, requiring manual restarts and potentially causing data inconsistency if transactions are left open during the abrupt termination.
This vulnerability aligns with CWE-789: Memory Excess Allocation, specifically manifesting as stack exhaustion rather than heap overflow. It also relates closely to CWE-1321: Improperly Controlled Stack Size, where the application fails to enforce limits on recursive operations that consume limited system resources. In terms of offensive security frameworks, this behavior is characteristic of ATT&CK technique T1496: Resource Hijacking, as an attacker can leverage resource exhaustion to degrade or halt service availability. The attack vector typically involves Remote Code Execution prerequisites being absent in favor of a pure Denial of Service impact via untrusted input, which falls under the broader category of injection-based attacks where SQL syntax is manipulated to exploit parser logic flaws rather than data integrity issues directly.
Mitigation strategies must focus on immediate patching and defensive coding practices. The primary remediation is upgrading SQLite to version 3.54.0 or later, where the developers have corrected the accounting logic for CTEs within the expression depth limit calculation. For environments unable to upgrade immediately, application-level defenses should be implemented. This includes validating SQL input length and complexity before passing it to the database engine. Developers can also programmatically set stricter limits using sqlite3_limit() with SQLITE_LIMIT_EXPR_DEPTH to a value lower than default if appropriate for their use case, although this may impact legitimate complex queries. Additionally, implementing timeouts on query execution can help mitigate the window of opportunity for stack exhaustion attacks by terminating long-running or deeply nested operations before they consume critical system resources. Regular security audits focusing on SQL injection and parser logic are essential to identify similar oversights in other database engines or custom implementations that rely on SQLite libraries.