CVE-2026-85689: llmware SQL Injection Vulnerability

CVE-2026-85689 Overview

CVE-2026-85689 is a SQL injection vulnerability in LLMWare version 0.4.6, affecting the collection-database layer implemented in llmware/resources.py. Filter and lookup values are string-interpolated directly into SQL WHERE clauses without parameterization or escaping. The flaw impacts both the SQLite and PostgreSQL backends. Attacker-controlled filter values reach the public API through Library.block_lookup, Query.text_query_with_custom_filter, and text_query_by_author_or_speaker. Successful exploitation enables cross-document and cross-collection data disclosure. On PostgreSQL, the flaw additionally permits boolean-based and UNION-based SQL injection [CWE-89].

Critical Impact
Authenticated attackers with low privileges can bypass filter scoping to read rows outside their authorized collection, and on PostgreSQL can perform boolean and UNION-based SQL injection to extract arbitrary database contents.

Affected Products

LLMWare 0.4.6
LLMWare deployments using the SQLite collection-database backend
LLMWare deployments using the PostgreSQL collection-database backend

Discovery Timeline

2026-09-04 - CVE-2026-85689 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-85689

Vulnerability Analysis

The vulnerability resides in the collection-database abstraction inside llmware/resources.py. LLMWare accepts filter dictionaries from callers of the public query API and translates them into SQL WHERE clauses. The translation layer concatenates filter values directly into raw SQL strings rather than binding them as parameters. This design defect exposes every query path that consumes user-controlled filters.

The filter validator enforces an allow-list on filter keys only. It never validates, escapes, or parameterizes values. As a result, a caller who is limited to a specific key can still supply arbitrary SQL fragments through the value. The vulnerability affects both the SQLite and PostgreSQL execution paths, and the PostgreSQL backend additionally permits boolean and UNION-based extraction because of its richer SQL grammar and error semantics.

Root Cause

The root cause is missing parameterization in the query construction logic of llmware/resources.py. Filter values are interpolated into SQL text using standard string operations rather than prepared statement placeholders. Combined with a validator that inspects only keys, this produces a classic injection sink [CWE-89] reachable from documented, supported API entry points.

Attack Vector

An attacker with the ability to call Library.block_lookup, Query.text_query_with_custom_filter, or text_query_by_author_or_speaker supplies crafted filter values. The malicious values neutralize the intended predicate and force the query to return rows that belong to other documents or collections. On PostgreSQL, an attacker can append UNION SELECT clauses or leverage boolean conditions to enumerate arbitrary tables and columns accessible to the database role. The result is confidentiality loss across tenant or document boundaries. See the VulnCheck LLMWare SQL Injection Advisory and GitHub LLMWare Issue #1304 for reproduction details.

No verified proof-of-concept exploit code is published in the referenced sources. Refer to the LLMWare source at v0.4.6 to review the vulnerable query construction directly.

Detection Methods for CVE-2026-85689

Indicators of Compromise

Application logs showing filter values containing SQL metacharacters such as single quotes, --, /*, OR 1=1, or UNION SELECT.
PostgreSQL server logs showing unexpected UNION, information_schema, or pg_catalog references in queries originating from LLMWare service accounts.
Query response sizes or row counts materially larger than the caller's authorized scope suggests.
Repeated boolean-style probes against the same endpoint with incrementing conditions.

Detection Strategies

Enable statement logging on the backing database and alert on statements originating from the LLMWare role that contain UNION, --, /*, or references to system catalogs.
Inspect API access logs for filter parameters that contain SQL operators or quote characters and correlate with response anomalies.
Perform code-level review of any application layer that constructs WHERE clauses via string interpolation of user-supplied values.

Monitoring Recommendations

Baseline the normal query shapes generated by LLMWare and alert on deviations, especially UNION and subquery patterns.
Monitor database role privileges to ensure the LLMWare account cannot read tables outside its intended scope.
Track EPSS movement for CVE-2026-85689 alongside upstream fix availability in the LLMWare repository.

How to Mitigate CVE-2026-85689

Immediate Actions Required

Restrict network exposure of the LLMWare API to trusted callers and enforce authentication on all query endpoints.
Reduce the privileges of the database role used by LLMWare to the minimum tables and columns required.
Disable or gate access to Library.block_lookup, Query.text_query_with_custom_filter, and text_query_by_author_or_speaker for untrusted tenants until a fix is applied.
Review recent query logs for injection indicators and quantify potential data exposure.

Patch Information

At the time of NVD publication, no fixed version is referenced in the advisory metadata. Track the LLMWare GitHub repository and Issue #1304 for remediation status. Any fix must replace string interpolation in llmware/resources.py with parameterized queries or bound placeholders for both SQLite and PostgreSQL backends.

Workarounds

Wrap calls to affected APIs with an application-layer validator that rejects filter values containing SQL metacharacters and quote characters.
Enforce strict type and length constraints on filter values before they reach the LLMWare query layer.
Segregate collections into distinct database schemas or roles so cross-collection reads are blocked at the database engine.
Deploy a web application firewall rule to block SQL injection payloads targeting LLMWare query endpoints.