CVE-2026-55405: LangChain SQL injection

CISO Take

CVE-2026-55405 is a SQL injection vulnerability in the Java LangChain4j framework's pgvector and MariaDB embedding stores, where metadata filter keys are concatenated unsanitized into SQL queries — a critical flaw when filter keys derive from LLM-generated output, as is common in agentic RAG pipelines. With CVSS 7.6 (Network/Low-Complexity/Low-Privilege), 312 downstream dependents, and no public exploit yet, the blast radius is moderate but growing as langchain4j adoption in enterprise Java stacks increases. The attack enables blind SQL injection for data exfiltration (timing via pg_sleep), denial-of-service, and arbitrary record deletion via the removeAll(Filter) path — a data-destruction vector that is particularly dangerous in production vector indexes. Upgrade langchain4j-pgvector and langchain4j-mariadb to version 1.2.1-beta8 immediately; if patching is delayed, restrict all metadata filter keys to a hard-coded developer-defined allowlist at the application boundary.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High risk for Java-based RAG deployments using langchain4j with pgvector or MariaDB backends, particularly any application where filter keys are influenced by user input or LLM output. CVSS 7.6 reflects Network-accessible, Low-complexity exploitation requiring only Low privileges — meaning any authenticated user or LLM-driven agent with access to the search or removeAll API can trigger the injection. The absence of a public exploit and no CISA KEV listing currently limits immediate mass exploitation, but the pattern (LLM-generated filter → unescaped SQL) is intuitive to exploit once the advisory is public. Organizations running agentic Java applications where the LLM constructs metadata filters dynamically face the highest exposure.

How does the attack unfold?

Initial Access

Attacker interacts with a Java RAG application that dynamically generates metadata filter keys from user input or LLM output and passes them to langchain4j's pgvector or MariaDB embedding store.

AML.T0049

Injection

A crafted metadata filter key containing SQL control characters (e.g., single quotes, comment sequences) is passed to EmbeddingSearchRequest.filter(); langchain4j's JSONFilterMapper or ColumnFilterMapper embeds it unsanitized into the SQL query string.

Reconnaissance / Exfiltration

Attacker uses timing-based blind SQL injection (pg_sleep in pgvector; SLEEP() in MariaDB) or boolean-based extraction to enumerate and exfiltrate metadata, document classifications, and sensitive fields stored alongside embeddings in the vector store.

AML.T0085.000

Impact

Attacker achieves one or more of: bulk data exfiltration from the vector index, targeted row deletion via removeAll(Filter) with a match-all injected filter destroying the production RAG database, or sustained DoS via resource-intensive sleep injection.

AML.T0101

Initial Access

Attacker interacts with a Java RAG application that dynamically generates metadata filter keys from user input or LLM output and passes them to langchain4j's pgvector or MariaDB embedding store.

AML.T0049

Injection

A crafted metadata filter key containing SQL control characters (e.g., single quotes, comment sequences) is passed to EmbeddingSearchRequest.filter(); langchain4j's JSONFilterMapper or ColumnFilterMapper embeds it unsanitized into the SQL query string.

Reconnaissance / Exfiltration

Attacker uses timing-based blind SQL injection (pg_sleep in pgvector; SLEEP() in MariaDB) or boolean-based extraction to enumerate and exfiltrate metadata, document classifications, and sensitive fields stored alongside embeddings in the vector store.

AML.T0085.000

Impact

Attacker achieves one or more of: bulk data exfiltration from the vector index, targeted row deletion via removeAll(Filter) with a match-all injected filter destroying the production RAG database, or sustained DoS via resource-intensive sleep injection.

AML.T0101

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LangChain	maven	<= 1.2.0-beta8	`1.2.1-beta8`
143.8K OpenSSF 5.8 3.0K dependents Pushed yesterday 24% patched ~209d to patch Full package profile →
pgvector	maven	<= 1.2.0-beta8	`1.2.1-beta8`
1.5K 339 dependents Pushed 1mo ago 67% patched ~13d to patch Full package profile →

How severe is it?

CVSS 3.1

7.6 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 28% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I Low

A Low

What should I do?

4 steps

PATCH

Upgrade langchain4j-pgvector and langchain4j-mariadb to >= 1.2.1-beta8 (Maven: dev.langchain4j:langchain4j-pgvector:1.2.1-beta8 and dev.langchain4j:langchain4j-mariadb:1.2.1-beta8).
WORKAROUND (if patching delayed): Implement an application-layer allowlist that validates all metadata filter keys against a set of known-safe identifiers before passing them to the embedding store. Reject any key not on the allowlist.
DETECTION

Monitor PostgreSQL query logs for anomalous execution times (indicative of pg_sleep-based blind injection) and for unexpected DELETE or DROP patterns originating from the embedding store connection. In MariaDB, enable query logging and alert on queries containing backslash sequences in filter contexts.
AUDIT

Review all code paths in your application where EmbeddingSearchRequest.filter() is populated with external or LLM-generated input; treat these as untrusted injection surfaces until patched.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Extraction Code Execution DoS RAG Framework AML.T0049 - Exploit Public-Facing Application AML.T0051.001 - Indirect AML.T0085.000 - RAG Databases AML.T0101 - Data Destruction via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.8.4 - AI system inputs

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain AI risk management are in place

OWASP LLM Top 10

LLM05:2025 - Improper Output Handling LLM08:2025 - Vector and Embedding Weaknesses

Frequently Asked Questions

What is CVE-2026-55405?

CVE-2026-55405 is a SQL injection vulnerability in the Java LangChain4j framework's pgvector and MariaDB embedding stores, where metadata filter keys are concatenated unsanitized into SQL queries — a critical flaw when filter keys derive from LLM-generated output, as is common in agentic RAG pipelines. With CVSS 7.6 (Network/Low-Complexity/Low-Privilege), 312 downstream dependents, and no public exploit yet, the blast radius is moderate but growing as langchain4j adoption in enterprise Java stacks increases. The attack enables blind SQL injection for data exfiltration (timing via pg_sleep), denial-of-service, and arbitrary record deletion via the removeAll(Filter) path — a data-destruction vector that is particularly dangerous in production vector indexes. Upgrade langchain4j-pgvector and langchain4j-mariadb to version 1.2.1-beta8 immediately; if patching is delayed, restrict all metadata filter keys to a hard-coded developer-defined allowlist at the application boundary.

Is CVE-2026-55405 actively exploited?

No confirmed active exploitation of CVE-2026-55405 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-55405?

1. PATCH: Upgrade langchain4j-pgvector and langchain4j-mariadb to >= 1.2.1-beta8 (Maven: dev.langchain4j:langchain4j-pgvector:1.2.1-beta8 and dev.langchain4j:langchain4j-mariadb:1.2.1-beta8). 2. WORKAROUND (if patching delayed): Implement an application-layer allowlist that validates all metadata filter keys against a set of known-safe identifiers before passing them to the embedding store. Reject any key not on the allowlist. 3. DETECTION: Monitor PostgreSQL query logs for anomalous execution times (indicative of pg_sleep-based blind injection) and for unexpected DELETE or DROP patterns originating from the embedding store connection. In MariaDB, enable query logging and alert on queries containing backslash sequences in filter contexts. 4. AUDIT: Review all code paths in your application where EmbeddingSearchRequest.filter() is populated with external or LLM-generated input; treat these as untrusted injection surfaces until patched.

What systems are affected by CVE-2026-55405?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, agent frameworks, LLM application frameworks.

What is the CVSS score for CVE-2026-55405?

CVE-2026-55405 has a CVSS v3.1 base score of 7.6 (HIGH). The EPSS exploitation probability is 0.35%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesvector databasesagent frameworksLLM application frameworks

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0051.001 Indirect

AML.T0085.000 RAG Databases

AML.T0101 Data Destruction via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.8.4

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM05:2025, LLM08:2025

What are the technical details?

Original Advisory

LangChain4j is a Java library for building LLM-powered applications on the JVM. Prior to 1.2.1-beta8, 1.5.1-beta11, 1.11.8-beta19, and 1.16.3-beta26, the MariaDB and pgvector embedding stores build metadata-filter SQL by string-concatenating filter keys, and in MariaDB string values, directly into the query without adequate escaping. A crafted metadata key in EmbeddingSearchRequest.filter() can break out of its SQL context and inject arbitrary SQL into the statements executed by the stores' search and removeAll(Filter) operations, enabling blind data exfiltration, denial of service via sleep functions, and deletion of arbitrary rows through removeAll(Filter). This issue is fixed in langchain4j-mariadb and langchain4j-pgvector versions 1.2.1-beta8, 1.5.1-beta11, 1.11.8-beta19, and 1.16.3-beta26.

Exploitation Scenario

An attacker interacts with an enterprise Java RAG application — for example, a compliance document search tool — that accepts natural-language queries and uses an LLM to dynamically construct metadata filter keys (e.g., filtering by document category, department, or classification level). The attacker submits a query that causes the LLM to generate a filter key containing a SQL injection payload: `')::text IS NOT NULL OR pg_sleep(5) IS NOT NULL --`. When the application calls embeddingStore.search(request), langchain4j's JSONFilterMapper embeds this key directly into the PostgreSQL query string without escaping, triggering a 5-second delay that confirms blind injection is live. The attacker then iterates with CASE-based boolean extraction to exfiltrate metadata from the vector store — potentially including user IDs, document classifications, and sensitive business metadata stored alongside embeddings. A more destructive variant targets removeAll(Filter) with a crafted key that matches all rows, destroying the production vector index.

Weaknesses (CWE)

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Primary CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Primary CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.