CVE-2026-85689 in llmware
Summary
by MITRE • 09/04/2026
llmware 0.4.6 contains an SQL injection vulnerability in the collection-database layer (llmware/resources.py) where filter and lookup values are directly string-interpolated into SQL WHERE clauses without parameterization or escaping, in both the SQLite and PostgreSQL backends. The filter validator only checks keys against an allow-list and never sanitizes values. Attacker-controlled filter values reaching the public API via Library.block_lookup and Query.text_query_with_custom_filter / text_query_by_author_or_speaker can neutralize the intended filter to disclose rows the caller was scoped out of (cross-document/cross-collection disclosure); on PostgreSQL the flaw permits boolean- and UNION-based SQL injection.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in llmware version 0.4.6 represents a critical security failure within its database interaction layer, specifically located in the resources.py module responsible for managing collection-database operations. This flaw stems from improper neutralization of special elements used in SQL commands, commonly categorized under CWE-89 as Improper Neutralization of Special Elements used in an SQL Command. The core technical issue arises because filter and lookup values provided by users are directly string-interpolated into SQL WHERE clauses without any form of parameterization or escaping mechanisms. This design choice bypasses the database engine's built-in protections against injection attacks, allowing malicious input to alter the structure of the executed query rather than being treated as literal data.
The application employs a filter validator that restricts input keys based on an allow-list but completely neglects to sanitize or validate the corresponding values associated with those keys. This partial validation creates a significant security gap where attackers can bypass intended access controls by injecting malicious SQL syntax into value fields. Because this logic is exposed through public API endpoints such as Library.block_lookup and Query.text_query_with_custom_filter, external actors have direct avenues for exploitation. The lack of input sanitization means that any string provided in these parameters is passed directly to the database backend, whether it be SQLite or PostgreSQL, without transformation into safe parameterized queries.
The operational impact of this vulnerability allows an attacker to neutralize intended filters and disclose rows from which they should not have access. This results in cross-document and cross-collection data disclosure, effectively breaking the isolation boundaries designed by the application architecture. In scenarios involving the PostgreSQL backend, the severity is further amplified because the flaw supports both boolean-based and UNION-based SQL injection techniques. Boolean-based injections allow attackers to infer database structure and extract data through logical deductions based on response differences, while UNION-based attacks enable the direct extraction of arbitrary data from other tables within the same database instance by appending a second SELECT statement that merges results with the original query output.
This vulnerability aligns closely with MITRE ATT&CK technique T1059.004, SQL Injection, which describes how attackers use structured query language to interact directly with backend databases for unauthorized access or modification of data. The ability to bypass scope restrictions and read sensitive information across different collections constitutes a severe breach of confidentiality integrity principles defined in standard security frameworks like OWASP Top 10 under the category of Broken Access Control combined with Injection flaws.
To mitigate this vulnerability, immediate remediation is required by refactoring all database queries that utilize dynamic string interpolation to use parameterized queries or prepared statements supported natively by both SQLite and PostgreSQL drivers. This ensures that user-supplied input is treated strictly as data rather than executable code regardless of its content. Additionally, the filter validator should be enhanced to perform strict type checking and value sanitization for all inputs before they reach the database layer. Implementing a Web Application Firewall with specific rules targeting SQL injection patterns can provide temporary defense-in-depth while patch development proceeds. Regular security audits focusing on data access layers are recommended to prevent similar oversights in future updates.