CVE-2026-55405 is a high-severity (CVSS 7.6) SQL Injection vulnerability in dev.langchain4j:langchain4j-mariadb. A fix is available for dev.langchain4j:langchain4j-mariadb — see the affected versions and patch details below.
LangChain4j: SQL injection via metadata filters in langchain4j-mariadb and langchain4j-pgvector
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-55405.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-55405 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 384,534 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
dev.langchain4j:langchain4j-mariadb☕dev.langchain4j:langchain4j-mariadb☕dev.langchain4j:langchain4j-mariadb☕dev.langchain4j:langchain4j-mariadb☕dev.langchain4j:langchain4j-pgvector☕dev.langchain4j:langchain4j-pgvector☕dev.langchain4j:langchain4j-pgvector☕dev.langchain4j:langchain4j-pgvectorReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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.
Details
pgvector — JSON mode (default, COMBINED_JSON / COMBINED_JSONB). JSONFilterMapper
places the key inside a single-quoted SQL literal (the JSON key of the ->> operator) with no
escaping:
(metadata->>'<key>')::text
A key containing a single quote breaks out, e.g.
metadataKey("')::text IS NOT NULL OR pg_sleep(1) IS NOT NULL --") injects a live pg_sleep(1)
(observable as a delay; exploitable for blind data extraction).
pgvector — column mode (COLUMN_PER_KEY). ColumnFilterMapper used the key as a bare,
unquoted, unvalidated SQL identifier (<key>::<type>), so a key such as 1=1 OR true --
injects directly.
MariaDB — JSON mode (default). JSONFilterMapper placed the key inside the JSON path literal
'$.<key>' unescaped (same break-out mechanism). Additionally, MariaDbFilterMapper.formatValue()
escaped ' but not \; because MariaDB treats backslash as an escape character by default, a
string value ending in a backslash could also break out of its literal.
MariaDB — column mode (COLUMN_PER_KEY). ColumnFilterMapper fell back to the raw,
unescaped key when the driver could not quote it as an identifier (e.g. a
character).
The filter key is the runtime injection surface; both stores' search() (including pgvector's
HYBRID mode) and removeAll(Filter) are affected. Add/upsert operations a
parameterized and not affected.
Impact
Applications that allow attacker-influenced metadata filter keys (e.g. use LLM-generated filters) to reach these stores are exposed to SQL injection: blind data exfiltration, denial of service via sleep functions, and — through `remove deletion of arbitrary rows. Applications using only hard-coded, developer-defined filter keys are not reachable.
Patches
Fixed in langchain4j-mariadb and langchain4j-pgvector 1.16.3-beta26:
- JSON filter keys are escaped before being embedded in the SQL string lit
quotes doubled, correct for PostgreSQL
standard_conforming_strings = on; MariaDB: backslash and single quote). - MariaDB string values escape both
\and'. - Column-mode keys are validated/quoted as identifiers and rejected when u concatenated as raw SQL.
Workarounds
- Do not pass untrusted input as metadata filter keys.
- Restrict filter keys to a known allow-list at the application layer.
References
- pgvector:
JSONFilterMapper,ColumnFilterMapper - MariaDB:
JSONFilterMapper,MariaDbFilterMapper,ColumnFilterMapper
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | dev.langchain4j:langchain4j-mariadb | all versions | 1.2.1-beta8dev.langchain4j:langchain4j-mariadb:1.2.1-beta8 |
| ☕Maven | dev.langchain4j:langchain4j-mariadb | ≥ 1.3.0-beta9&&< 1.5.1-beta11 | 1.5.1-beta11dev.langchain4j:langchain4j-mariadb:1.5.1-beta11 |
| ☕Maven | dev.langchain4j:langchain4j-mariadb | ≥ 1.6.0-beta12&&< 1.11.8-beta19 | 1.11.8-beta19dev.langchain4j:langchain4j-mariadb:1.11.8-beta19 |
| ☕Maven | dev.langchain4j:langchain4j-mariadb | ≥ 1.12.1-beta21&&< 1.16.3-beta26 | 1.16.3-beta26dev.langchain4j:langchain4j-mariadb:1.16.3-beta26 |
| ☕Maven | dev.langchain4j:langchain4j-pgvector | all versions | 1.2.1-beta8dev.langchain4j:langchain4j-pgvector:1.2.1-beta8 |
| ☕Maven | dev.langchain4j:langchain4j-pgvector | ≥ 1.3.0-beta9&&< 1.5.1-beta11 | 1.5.1-beta11dev.langchain4j:langchain4j-pgvector:1.5.1-beta11 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for dev.langchain4j:langchain4j-mariadb, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update dev.langchain4j:langchain4j-mariadb to 1.2.1-beta8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-55405 is resolved across your whole dependency graph.
Workarounds
Until you can upgrade, make sure every query built from user input uses parameterised statements or a prepared-statement API rather than string concatenation, and reduce the database account's privileges so an injected query cannot read or alter data beyond what the feature needs.
Frequently Asked Questions
Is CVE-2026-55405 in your dependencies?
Find it across Maven, including transitive dependencies.