LLM08:2025 - Vector and Embedding Weaknesses

Vector and Embedding Weaknesses is the eighth risk in the OWASP Top 10 for LLM Applications 2025. It targets Retrieval-Augmented Generation (RAG) systems where vector stores and embedding pipelines are vulnerable to unauthorized access, missing tenant isolation, data poisoning through embedding manipulation, and injection of unsanitized retrieved content into LLM prompts.

Overview

RAG architectures have become the standard approach for grounding LLM responses in domain-specific data. Documents are converted into vector embeddings, stored in a vector database, and retrieved at query time based on semantic similarity. However, vector stores are data stores, and they require the same access control, authentication, and input validation that any database demands. When these controls are missing, attackers can query other tenants' documents, inject poisoned embeddings, access unauthenticated embedding endpoints, or exploit unbounded similarity searches. The retrieved content then flows directly into the LLM prompt, compounding the risk with potential prompt injection and information disclosure. As organizations embed RAG into increasingly sensitive workflows (legal research, medical records, financial analysis) the consequences of missing access controls on vector stores grow correspondingly severe.

What Radar Detects

• Vector store queries without access control checks.** Similarity search operations that return documents based solely on embedding distance without verifying whether the requesting user is authorized to access the matched documents.

• Missing tenant isolation in multi-tenant RAG systems.** Vector store configurations and query logic that do not enforce tenant boundaries, allowing one tenant's queries to retrieve another tenant's documents through semantic similarity matching.

• Embedding APIs exposed without authentication.** Endpoints that generate or query embeddings accessible without API key validation, OAuth tokens, or any form of authentication, enabling unauthorized data access and resource consumption.

• Vector store connections using hardcoded credentials.** Database connection strings, API keys, or authentication tokens for vector store services embedded directly in source code rather than managed through environment variables or secrets management.

• Missing input validation on vector similarity search parameters.** User-controlled search parameters such as top_k, similarity thresholds, or collection names that reach the vector store without server-side validation or bounds, enabling excessive data retrieval or access to unintended collections.

• RAG pipelines that inject retrieved chunks into prompts without sanitization.** Retrieved document content inserted directly into the LLM prompt context without escaping, delimiting, or sanitizing the content, creating an indirect prompt injection vector through poisoned documents.

• Missing metadata filtering on vector store queries.** Similarity searches that do not apply metadata-based filters (document owner, classification level, department) alongside semantic matching, returning documents based purely on embedding distance regardless of sensitivity.

• Embedding model outputs stored without integrity checks.** Generated embeddings persisted in vector stores without checksums or provenance tracking, making it impossible to detect whether stored embeddings have been tampered with or replaced.

Related CWEs

CWE-862 (Missing Authorization), CWE-639 (Authorization Bypass Through User-Controlled Key), CWE-284 (Improper Access Control).

See the CWE Reference for details.

Overlap with OWASP Top 10 Web

Vector and Embedding Weaknesses relates directly to A01:2025 Broken Access Control in the traditional OWASP Top 10. Vector stores are data stores that hold sensitive document content in encoded form. They require the same authorization checks, tenant isolation, and authentication as relational databases or object storage. The fact that data is stored as numerical vectors rather than plaintext does not reduce the access control requirements.

Prevention

• Implement document-level access control on all vector store queries. Verify that the requesting user is authorized to access each returned document before including it in the response context.
• Enforce strict tenant isolation in multi-tenant RAG systems through separate collections, metadata filtering, or dedicated vector store instances per tenant.
• Authenticate all embedding API endpoints with API keys, OAuth tokens, or equivalent mechanisms. Never expose embedding generation or search endpoints publicly.
• Sanitize and clearly delimit retrieved document content before injecting it into LLM prompts to prevent indirect prompt injection from poisoned documents.
• Validate and bound all user-controlled similarity search parameters server-side. Enforce maximum top_k values, restrict collection access, and validate similarity thresholds.
• Store vector database credentials in environment variables or a secrets manager. Never hardcode connection strings or API keys in source code.
• Audit vector store access patterns to detect anomalous queries that may indicate unauthorized data harvesting or embedding inversion attacks.
• Apply metadata-based filters alongside semantic search to enforce document classification, ownership, and sensitivity levels at query time.
• Implement integrity checks on stored embeddings to detect tampering or unauthorized modifications to the vector store contents.

Next Steps