GHSA-2mfg-cc43-9pcj
HIGHGHSA-2mfg-cc43-9pcj is a high-severity (CVSS 7.6) SQL Injection vulnerability in dev.langchain4j:langchain4j-mariadb. O3 Security confirms whether GHSA-2mfg-cc43-9pcj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
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 GHSA-2mfg-cc43-9pcj.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-2mfg-cc43-9pcj plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 363,908 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
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-beta8 |
| ☕Maven | dev.langchain4j:langchain4j-mariadb | ≥ 1.3.0-beta9&&< 1.5.1-beta11 | 1.5.1-beta11 |
| ☕Maven | dev.langchain4j:langchain4j-mariadb | ≥ 1.6.0-beta12&&< 1.11.8-beta19 | 1.11.8-beta19 |
| ☕Maven | dev.langchain4j:langchain4j-mariadb | ≥ 1.12.1-beta21&&< 1.16.3-beta26 | 1.16.3-beta26 |
| ☕Maven | dev.langchain4j:langchain4j-pgvector | all versions | 1.2.1-beta8 |
| ☕Maven | dev.langchain4j:langchain4j-pgvector | ≥ 1.3.0-beta9&&< 1.5.1-beta11 | 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-2mfg-cc43-9pcj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-2mfg-cc43-9pcj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2mfg-cc43-9pcj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2mfg-cc43-9pcj in your dependencies?
O3 detects GHSA-2mfg-cc43-9pcj across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.