CVE-2026-85689

llmware 0.4.6 is vulnerable to SQL injection (CWE-89) in its collection-database layer (llmware/resources.py), where filter and lookup values are directly string-interpolated into SQL WHERE clauses without parameterization or escaping, affecting both the SQLite and PostgreSQL backends. The filter validator only checks keys against an allow-list and never sanitizes values, so attacker-controlled filter values reaching the public API through Library.block_lookup and Query.text_query_with_custom_filter / Query.text_query_by_author_or_speaker can neutralize the intended scoping filter. An attacker with low-privileged API access gains unauthorized disclosure of rows they were scoped out of (cross-document and cross-collection data leakage), and on PostgreSQL the flaw additionally permits boolean- and UNION-based SQL injection; CVSS 4.0 rates it 7.1 (High) with high confidentiality impact and no integrity or availability impact. Any deployment of llmware 0.4.6 that exposes these query APIs to untrusted input is affected, with exposure limited by the framework's niche, self-hosted developer adoption. There is no public proof-of-concept, it is not in CISA KEV, and EPSS puts 30-day exploitation probability at about 0.3% (17th percentile), so no exploitation is currently known.

What to do: Monitor the llmware project for a patched release and upgrade as soon as one is published (the advisory does not specify a fixed version). Until patched, sanitize or escape filter and lookup values before they reach the database layer, or restrict Library.block_lookup and Query.text_query_with_custom_filter / text_query_by_author_or_speaker to trusted callers, and on PostgreSQL run the database account with least privileges while reviewing query logs for boolean/UNION injection patterns.