LangChain4j MariaDB/pgvector Embedding Store SQL Injection via Metadata Filters

Technical Analysis

The vulnerability lies in how EmbeddingSearchRequest.filter() metadata keys (and MariaDB string values) are turned into SQL WHERE clauses: the code string-concatenates untrusted filter keys/values directly into the query instead of using parameterized queries or identifier allowlisting. Any application layer that passes user- or agent-controlled metadata filter keys into a RAG search or removeAll(Filter) call becomes an injection point, since the attacker can break out of the intended SQL context. This gives an attacker the ability to exfiltrate data blind (e.g., via boolean/time-based techniques), cause DoS through sleep-based payloads, or delete arbitrary rows from the vector store via removeAll(Filter), effectively poisoning or destroying the agent's long-term memory/knowledge base. The flaw crosses trust boundaries whenever filter values originate from end users, tool outputs, or other agents feeding into a shared RAG pipeline.

Affected Systems

LangChain4j, langchain4j-mariadb, langchain4j-pgvector

Detection Signatures

• Unusual or anomalous characters (quotes, comments, semicolons) in EmbeddingSearchRequest metadata filter keys or values
• SQL errors or unexpected query latency (sleep-based DoS) correlated with embedding search calls
• Unexpected mass deletions following removeAll(Filter) invocations
• Application logs showing filter keys sourced directly from user/agent input without allowlist validation
• Database query logs revealing malformed WHERE clauses with unescaped metadata identifiers

Remediation Steps

1. 1

   Upgrade LangChain4j embedding store dependencies

   Update langchain4j-mariadb and langchain4j-pgvector to the patched versions (1.2.1-beta8, 1.5.1-beta11, 1.11.8-beta19, or 1.16.3-beta26 or later).

2. 2

   Validate and allowlist metadata filter keys

   Restrict EmbeddingSearchRequest filter keys to a known-safe allowlist before they reach the embedding store layer, rejecting unexpected identifiers.

3. 3

   Use parameterized queries for all metadata operations

   Ensure any custom or wrapped embedding store code uses prepared statements/parameter binding rather than string concatenation for filter values and identifiers.

4. 4

   Restrict removeAll(Filter) privileges

   Limit which application components or agents can invoke removeAll(Filter) and require additional authorization checks before bulk deletion operations.

5. 5

   Monitor and rate-limit vector search queries

   Add monitoring for anomalous query latency and error rates on embedding store searches to catch blind SQLi/DoS attempts early.