Spring AI VectorStore FilterExpression Injection
Defending RAG Metadata Filters from Query Alteration
VMware disclosed an injection vulnerability in Spring AI's FilterExpression conversion logic affecting all vector store integrations. Keys and values in metadata filter expressions were not properly escaped before being converted into vector store query languages, allowing user-controlled input to alter the structure and semantics of retrieval queries. RAG pipelines, semantic search endpoints, and agent memory layers built on Spring AI 1.0.0–1.0.5 or 1.1.0–1.1.4 are affected. The risk: unauthorized document retrieval, context poisoning, and authorization bypass in multi-tenant deployments.
"RAG filters are security boundaries when they control which documents reach the model."
— VMware Spring AI Security Advisory
Technical Breakdown
Spring AI provides a FilterExpression abstraction that converts metadata filter predicates into vector store-specific query languages — such as those used by Pinecone, Weaviate, Chroma, pgvector, and others. The vulnerability is in that conversion step.
Spring AI VectorStore FilterExpression Injection
Metadata filter keys and values passed to Spring AI's FilterExpression were not properly escaped before conversion into vector store query languages. User-controlled input that reaches a filter expression can alter query structure, causing the generated query to no longer match the developer's intended filter — and potentially retrieving documents the user should not have access to.
Root Cause: Unescaped Filter Conversion
Spring AI translates FilterExpression predicates into the native query syntax of the configured vector store backend. Keys and values were passed through this translation without escaping, making them susceptible to injection — analogous to SQL injection at the vector retrieval layer.
Scope: All Vector Store Backends
The vulnerability affects any Spring AI integration that uses FilterExpression metadata filtering — Pinecone, Weaviate, Chroma, pgvector, OpenSearch, Redis, and others. The flaw is in the shared conversion logic, not in a specific backend.
RAG Filters as Authorization
In many production deployments, metadata filters serve as the primary access control mechanism — restricting retrieved documents to those belonging to the requesting tenant, user, or role. When filter expressions can be altered by user input, this authorization model breaks silently — the query executes successfully but returns unintended results.
Silent Failure Mode
Unlike authentication failures, which return errors, a bypassed retrieval filter returns results — just the wrong ones. The model receives unauthorized documents and generates responses from them. Without post-retrieval validation, neither the application nor the user receives any signal that a bypass occurred.
Attack Path
Locate User-Controlled Filter Input
Attacker identifies a RAG endpoint, semantic search interface, or agent memory query that accepts user-controlled input that flows into a metadata filter expression — such as a tenant ID, document category, access level, or search context parameter.
Audit every location where external input is used to construct or parameterize a FilterExpression. Treat these as injection sinks.
Inject Query-Altering Syntax
Attacker crafts input containing characters or tokens that are meaningful in the target vector store's query language. Because values are not escaped before conversion, the injected tokens alter the structure of the generated query rather than being treated as literal values.
The target syntax differs by backend — what escapes in Chroma may not apply to Pinecone. Test each vector store integration independently.
Alter Vector Store Query Semantics
The generated vector store query no longer matches the developer's intended filter structure. Tenant isolation, document ownership checks, access-level restrictions, or other metadata-based controls are removed, widened, or overridden by the injected payload.
Authorization controls embedded solely in filter expressions fail silently — the query executes and returns results without any error signal.
Retrieve Unauthorized Documents
The vector store returns documents outside the attacker's authorized scope. In a RAG pipeline, these documents flow directly into the model's context, poisoning the response. In agent memory systems, unauthorized context is injected into the agent's working state.
Post-retrieval authorization checks — validating document access rights after retrieval and before passing to the model — are the last line of defense when filter-level controls are bypassed.
Impact
The impact is most severe in multi-tenant RAG deployments where metadata filters are the primary mechanism enforcing tenant isolation or document-level access control. A filter bypass does not just return wrong data — it silently grants unauthorized access to content that may include other tenants' proprietary information, internal documents, or sensitive operational data.
Data Exposure
- Cross-tenant document retrieval
- Unauthorized knowledge base access
- Internal document exfiltration
- Privileged content disclosure
RAG Pipeline Integrity
- Context poisoning via injected docs
- Model response manipulation
- Agent memory contamination
- Silent authorization bypass
Affected Deployments
- Multi-tenant SaaS RAG systems
- Enterprise knowledge base chatbots
- Agent memory and planning layers
- Semantic search with access controls
Defensive Tutorial
0–24 Hours
Upgrade Spring AI to 1.0.6 or 1.1.5 depending on your version line. Inventory all deployments using FilterExpression with user-supplied input. Temporarily restrict or sanitize user-controlled filter parameters at the application layer until the patch is applied. Review vector store query logs for unusual filter patterns or cross-tenant retrieval anomalies.
1–7 Days
Add regression tests that verify filter injection payloads are handled safely for each vector store backend in use. Separate authorization logic from search filter construction — access controls should not depend solely on filter expressions. Implement post-retrieval authorization checks that validate document access rights before passing retrieved content to the model or agent.
Long-Term Governance
Treat the retrieval layer as a security boundary, not a convenience layer. Document the vector database schema, metadata fields, and access model for every RAG deployment. Perform retrieval-layer threat modeling as part of AI system design — identifying where user input reaches filter construction, what authorization properties are enforced at retrieval, and what post-retrieval checks exist. Combine safe query construction with independent authorization so that a filter bypass alone cannot yield unauthorized access.
Response Checklist
Apply the patched version matching your current version line — 1.0.6 for the 1.0.x line, 1.1.5 for the 1.1.x line. Apply to all environments including development and staging, which may share the same multi-tenant data stores.
Search your codebase for all locations where FilterExpression is constructed using values derived from user input, request parameters, session data, or external API responses. Each is a potential injection sink.
Before patching, apply allow-list validation at the application layer for any user-supplied values that flow into filter expressions. Reject inputs containing characters meaningful in your vector store's query syntax.
Search vector store query logs for unusual filter structures, queries missing expected tenant or access-level constraints, or retrieval patterns inconsistent with normal user activity. Any anomaly before patching should be investigated as a potential exploitation attempt.
Access control logic should not depend solely on filter expressions. Add a dedicated authorization layer that constructs access-control predicates from server-side session state — not from user-supplied input — and applies them independently of any user-controlled filter parameters.
Validate document access rights after retrieval and before passing content to the model or agent. A filter bypass should not grant unchecked access to model context — post-retrieval checks are the last defense when retrieval-layer controls fail.
Write tests that pass injection-style payloads through filter construction for each vector store backend in use and verify that the generated query retains the intended structure. These tests should run in CI to prevent regressions across future Spring AI upgrades.
For every RAG deployment, document the vector database schema, which metadata fields enforce access control, which are user-controlled, and what post-retrieval checks exist. This documentation is the input to retrieval-layer threat modeling and should be reviewed whenever the schema or access model changes.
References
[1] VMware Spring Security Advisory
Spring AI VectorStore FilterExpression Injection — April 27, 2026
[2] NVD
CVE-2026-40967 — Spring AI VectorStore FilterExpression Injection