SQLite CVE-2026-119371

Exploitation requires the SQLite process to parse attacker-controlled SQL containing a WITH clause that chains tens of thousands of CTEs, OR to open an untrusted SQLite database file containing a view with that nesting. The root condition is that, before 3.54.0, common table expressions were not counted against SQLITE_LIMIT_EXPR_DEPTH, so that configured nesting limit provides no protection. Limiting factors that reduce realistic risk: the attack is local (the malicious input must be delivered to the SQLite process, not sent over a network to default installs), it requires passive user interaction in the sense that the victim application must accept and process the untrusted SQL text or database file, and impact is confined to a process crash (availability only) with no code execution or data exposure. Deployments that only ever execute trusted, application-authored SQL and never open untrusted database files are not exposed.

This is a medium-severity denial-of-service issue, not a priority emergency. The supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H, score 6.8) tells a consistent story: the only impact is availability (VA:H) - a process crash via stack exhaustion (CWE-674) - with no confidentiality or integrity effect, and the attack vector is local, meaning the malicious SQL or database file must be fed to the SQLite process rather than reaching it unauthenticated over a network. The vuln.today decision label is 'this_month', which signals a scheduled-patch priority rather than act_now/emergency. No CISA KEV listing and no EPSS score are present in the input, so there is no signal of active or probable exploitation. A public PoC reference exists (the abraxaslabs research write-up and the VulnCheck advisory), but it is not verified as working exploit code, so POC availability must not be read as active exploitation. The practical risk is concentrated entirely in applications that parse untrusted SQL text or open untrusted SQLite database files; where SQLite only ever handles trusted, developer-authored queries, real-world risk is low despite SQLite's enormous deployment footprint. Note the signal tension: PR:N implies no privileges, yet the vector is local with passive user interaction (UI:P), so 'unauthenticated' should be understood as 'no authentication step in the trigger path' rather than 'remotely reachable by anyone.'

An application lets users upload or open SQLite database files, or exposes a SQL query interface that accepts arbitrary statements. An attacker submits a WITH clause chaining tens of thousands of common table expressions (or ships a view containing such nesting inside a crafted database file); when SQLite expands it, selectExpander() recurses without bound and exhausts the stack, crashing the process. A public PoC reference exists but is not verified as working exploit code.