EUVD-2026-71138
GHSA-xw8g-m37q-fhx8
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege API caller
-
DeliverySubmit crafted filter value with UNION payload to text_query_with_custom_filter
-
ExploitFilter key passes allow-list; injected value enters raw SQL WHERE clause
-
ExecutionPostgreSQL executes UNION query
-
PersistRetrieve rows outside authorized collection scope
-
ImpactExfiltrate arbitrary database contents
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Parameterized queries, prepared statements
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Persistence The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a valid API caller identity with at least low-level access to the llmware query API (PR:L per the CVSS 4.0 vector). The specific exploitable entry points are Library.block_lookup and Query.text_query_with_custom_filter / text_query_by_author_or_speaker in resources.py. UNION-based full data extraction requires a PostgreSQL backend; the SQLite backend limits impact to cross-document or cross-collection row disclosure by neutralizing scope filters. No special non-default configuration is required - any llmware deployment using these API methods and either backend is affected. The exploitation is limited in practice to deployments where the API is reachable by callers who should only have partial access to the data store; fully-trusted single-user deployments have no meaningful exposure. |
| Impact | The provided CVSS 4.0 score of 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) is well-calibrated: the attack is network-reachable, low complexity, and requires only API-level credentials, while impact is purely confidentiality-oriented (no integrity or availability effect). No public exploit code has been identified and the CVE is absent from CISA KEV, indicating no confirmed active exploitation at time of analysis. However, UNION-based SQL injection exploits of this class are straightforward to construct for any researcher with API access, and the GitHub issue disclosure (https://github.com/llmware-ai/llmware/issues/1304) is public, lowering the development barrier. Real-world risk is highly deployment-dependent: single-user or fully-trusted internal deployments face minimal practical exposure, whereas multi-tenant or SaaS deployments that scope different callers to different document collections are directly threatened by cross-collection data exfiltration. PostgreSQL deployments are materially higher risk than SQLite due to UNION extraction capability. |
| Exploit ScenarioDerived | An authenticated API caller with low-privilege access crafts a filter value containing a UNION SELECT payload and submits it to Query.text_query_with_custom_filter against a PostgreSQL-backed llmware instance. The filter key passes the allow-list check while the injected value causes the PostgreSQL backend to execute a UNION query, returning rows from tables outside the caller's authorized document collection - including potentially all rows accessible to the database account. No public exploit code is required; the injection point and SQL context are fully described in the public VulnCheck advisory and GitHub issue. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 04, 2026
SQL injection in llmware 0.4.6's collection-database abstraction layer allows an authenticated API caller to disclose rows from collections they are scoped out of, with full UNION-based data extraction possible on PostgreSQL backends. The flaw resides in resources.py, where attacker-controlled filter values are string-interpolated directly into SQL WHERE clauses without parameterization; the filter validator checks only key names against an allow-list but never sanitizes values. Affected public API entry points are Library.block_lookup and Query.text_query_with_custom_filter / text_query_by_author_or_speaker. No public exploit code has been identified and this CVE is not listed in CISA KEV at time of analysis.
RemediationAI
No vendor-released patch has been identified at time of analysis; the issue was disclosed via GitHub (https://github.com/llmware-ai/llmware/issues/1304) without a corresponding tagged fix release. Monitor the llmware repository (https://github.com/llmware-ai/llmware) for a release that parameterizes the SQL WHERE clause construction in resources.py and upgrade immediately once one is available. As compensating controls, restrict access to Library.block_lookup and the Query.text_query_with_custom_filter / text_query_by_author_or_speaker methods exclusively to fully trusted, internal callers - do not expose these endpoints to partially-trusted or user-facing input. For PostgreSQL deployments, apply database-level least-privilege restrictions so the llmware database account can access only the specific tables it legitimately requires, limiting the blast radius of any UNION-based extraction. Consider adding an application-layer value sanitization or rejection layer for all filter dict values as an interim measure, though parameterization at the SQL layer is the only robust fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
llmware is a Python framework for building LLM-powered retrieval-augmented generation (RAG) and document-AI applications; its collection-database layer in resources.py supports both SQLite and PostgreSQL backends. CWE-89 (SQL Injection) is triggered because filter and lookup values supplied by callers are concatenated directly into SQL WHERE clause strings - for example via f-string or string format interpolation - rather than being passed as parameterized query placeholders (e.g., cursor.execute with a parameters tuple). The allow-list validation guards only the key names of the filter dict, not the corresponding values, so any attacker-supplied value reaching those methods bypasses validation entirely. On SQLite the impact is limited to neutralizing scope filters to expose cross-collection rows; on PostgreSQL the richer SQL dialect permits boolean-blind and UNION-based injection capable of dumping arbitrary tables. The CPE cpe:2.3:a:llmware-ai:llmware:*:*:*:*:*:*:*:* with a wildcard version field suggests the design flaw is not version-local and may predate 0.4.6.
Know when Llmware gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Network-accessible API requiring API-level authentication (PR:L); purely confidentiality impact via SQL extraction with no integrity or availability effect described.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Articles & Coverage 1
Executive ViewAI
llmware 0.4.6 contains a SQL injection vulnerability in its collection-database abstraction layer that allows authenticated API users to extract database rows from collections outside their authorized scope. Organizations using llmware with PostgreSQL backends and role-based collection access controls face potential unauthorized data disclosure from compromised API credentials or malicious insiders with legitimate database access.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) deploy Web Application Firewall rules to block SQL metacharacters and keywords in filter parameter values; (2) add application-layer validation to reject filter inputs matching regex patterns for UNION clauses and SQL comments; (3) enforce principle of least privilege-restrict API consumer credentials to minimum collection scopes and disable Library.block_lookup and text_query_with_custom_filter where not essential; (4) implement real-time database query auditing to alert on SELECT statements with unusual WHERE clause patterns; (5) restrict PostgreSQL network access to application servers only via firewall rules.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.
Exploit-DB