WaratekVRT Sign in

Dev.langchain4j CVEs with no public exploit

1 CVE, 1 protected by Waratek

Reset
More filters (1)
Columns
Vendor dev.langchain4j✕
Overview 1 match · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
1match 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 1 100.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0%
Critical 0 0.0% High 1 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 1 100.0% partly blocked 0 0.0% not blocked 0 0.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 1 100.0%
split by peak 1 / month
Protected by Waratek: 1 High: 1 blocked by ARMR today: 1 No public exploit: 1
Jul 26
1 match Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-55405 High 2026-07-10 Protected by Waratek No public exploit 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.