SQL injection in Spring AI CosmosDBVectorStore delete flow
TL;DR - Spring AI's CosmosDBVectorStore.doDelete() concatenates user-supplied document IDs directly into SQL. Craft the right ID and you execute arbitrary queries. Upgrade to 1.0.6 (for 1.0.x) or 1.1.5 (for 1.1.x).
What happened
Spring AI is Spring's library layer for building LLM-backed applications. Its VectorStore integrations handle storing and retrieving embeddings - the kind of component that ends up sitting directly on the request path.
Spring disclosed a High-severity SQL injection in CosmosDBVectorStore. The vulnerable surface is CosmosDBVectorStore.doDelete(), which builds SQL using document IDs without sanitising them first. If an attacker can influence those IDs, they can execute arbitrary SQL.
The risk is real only when your application passes untrusted input as document IDs - request parameters, chat inputs, multi-tenant identifiers, anything user-controlled. If that describes your delete flows, you're in the blast radius.
Vector store adapters are increasingly app-facing attack surfaces. They sit on the request path, they consume partially user-controlled data, and they tend to get treated as inert plumbing rather than database integrations. They're not. Treat them the same way you'd treat any other layer that touches a query.
Who is impacted
- Applications using Spring AI
CosmosDBVectorStore. - Deployments where document IDs can be influenced by untrusted input - directly or indirectly.
| Spring AI line | Affected versions | Fix version | Availability |
|---|---|---|---|
1.0.x | 1.0.0 - 1.0.x | 1.0.6 | OSS |
1.1.x | 1.1.0 - 1.1.x | 1.1.5 | OSS |
What to do now
- Upgrade to the fixed version for your release line:
1.0.6for1.0.x,1.1.5for1.1.x."Users of affected versions should upgrade to the corresponding fixed version."
- Prioritise services where document IDs derive from request-controlled values - API parameters, user identifiers, tenant IDs, UI-provided record keys.
- While rolling out the patch, audit application code to confirm that document IDs flowing into
CosmosDBVectorStoredelete operations are not user-controlled, or are validated against a strict allowlist. - After patching, inspect any internal wrappers around vector store deletion APIs. Confirm they haven't reintroduced string-concatenated query patterns of their own.
"No further mitigation steps are necessary."
Related
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.