### 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`
### 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`
Update dev.langchain4j:langchain4j-mariadb to 1.2.1-beta8; dev.langchain4j:langchain4j-mariadb to 1.5.1-beta11; dev.langchain4j:langchain4j-mariadb to 1.11.8-beta19; dev.langchain4j:langchain4j-mariadb to 1.16.3-beta26; dev.langchain4j:langchain4j-pgvector to 1.2.1-beta8; dev.langchain4j:langchain4j-pgvector to 1.5.1-beta11; dev.langchain4j:langchain4j-pgvector to 1.11.8-beta19; dev.langchain4j:langchain4j-pgvector to 1.16.3-beta26 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanLangChain4j: SQL injection via metadata filters in langchain4j-mariadb and langchain4j-pgvector affects dev.langchain4j:langchain4j-mariadb (maven), dev.langchain4j:langchain4j-mariadb (maven), dev.langchain4j:langchain4j-mariadb (maven), dev.langchain4j:langchain4j-mariadb (maven), dev.langchain4j:langchain4j-pgvector (maven), dev.langchain4j:langchain4j-pgvector (maven), dev.langchain4j:langchain4j-pgvector (maven), dev.langchain4j:langchain4j-pgvector (maven). Severity is high. ### 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`
AI coding agents often install or upgrade packages automatically in maven. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| dev.langchain4j:langchain4j-mariadbmaven | <=1.2.0-beta8 | 1.2.1-beta8 |
| dev.langchain4j:langchain4j-mariadbmaven | >=1.3.0-beta9,<=1.5.0-beta11 | 1.5.1-beta11 |
| dev.langchain4j:langchain4j-mariadbmaven | >=1.6.0-beta12,<=1.11.7-beta19 | 1.11.8-beta19 |
| dev.langchain4j:langchain4j-mariadbmaven | >=1.12.1-beta21,<=1.16.2-beta26 | 1.16.3-beta26 |
| dev.langchain4j:langchain4j-pgvectormaven | <=1.2.0-beta8 | 1.2.1-beta8 |
| dev.langchain4j:langchain4j-pgvectormaven | >=1.3.0-beta9,<=1.5.0-beta11 | 1.5.1-beta11 |
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate dev.langchain4j:langchain4j-mariadb to 1.2.1-beta8; dev.langchain4j:langchain4j-mariadb to 1.5.1-beta11; dev.langchain4j:langchain4j-mariadb to 1.11.8-beta19; dev.langchain4j:langchain4j-mariadb to 1.16.3-beta26; dev.langchain4j:langchain4j-pgvector to 1.2.1-beta8; dev.langchain4j:langchain4j-pgvector to 1.5.1-beta11; dev.langchain4j:langchain4j-pgvector to 1.11.8-beta19; dev.langchain4j:langchain4j-pgvector to 1.16.3-beta26 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanLangChain4j: SQL injection via metadata filters in langchain4j-mariadb and langchain4j-pgvector affects dev.langchain4j:langchain4j-mariadb (maven), dev.langchain4j:langchain4j-mariadb (maven), dev.langchain4j:langchain4j-mariadb (maven), dev.langchain4j:langchain4j-mariadb (maven), dev.langchain4j:langchain4j-pgvector (maven), dev.langchain4j:langchain4j-pgvector (maven), dev.langchain4j:langchain4j-pgvector (maven), dev.langchain4j:langchain4j-pgvector (maven). Severity is high. ### 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`
AI coding agents often install or upgrade packages automatically in maven. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| dev.langchain4j:langchain4j-mariadbmaven | <=1.2.0-beta8 | 1.2.1-beta8 |
| dev.langchain4j:langchain4j-mariadbmaven | >=1.3.0-beta9,<=1.5.0-beta11 | 1.5.1-beta11 |
| dev.langchain4j:langchain4j-mariadbmaven | >=1.6.0-beta12,<=1.11.7-beta19 | 1.11.8-beta19 |
| dev.langchain4j:langchain4j-mariadbmaven | >=1.12.1-beta21,<=1.16.2-beta26 | 1.16.3-beta26 |
| dev.langchain4j:langchain4j-pgvectormaven | <=1.2.0-beta8 | 1.2.1-beta8 |
| dev.langchain4j:langchain4j-pgvectormaven | >=1.3.0-beta9,<=1.5.0-beta11 | 1.5.1-beta11 |
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard| dev.langchain4j:langchain4j-pgvectormaven | >=1.6.0-beta12,<=1.11.7-beta19 | 1.11.8-beta19 |
|---|
| dev.langchain4j:langchain4j-pgvectormaven | >=1.12.1-beta21,<=1.16.2-beta26 | 1.16.3-beta26 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.
| dev.langchain4j:langchain4j-pgvectormaven | >=1.6.0-beta12,<=1.11.7-beta19 | 1.11.8-beta19 |
|---|
| dev.langchain4j:langchain4j-pgvectormaven | >=1.12.1-beta21,<=1.16.2-beta26 | 1.16.3-beta26 |
|---|
Fixed versions are reported by the source feed; confirm compatibility before updating.