Back

Vector & Embedding Weaknesses - Overview

Table of Contents

What are Vector & Embedding Weaknesses?

Vector and Embedding Weaknesses (LLM08:2025) are security flaws in how embeddings are generated, stored, and retrieved in systems that use Retrieval-Augmented Generation (RAG). This is a new category introduced in the 2025 edition of the OWASP Top 10 for LLM Applications, added because RAG has become the default pattern for grounding a model in private, up-to-date, or domain-specific knowledge—and the retrieval layer it depends on is now a first-class attack surface.

RAG works by converting text (documents, chunks, user questions) into embeddings: high-dimensional numeric vectors that capture semantic meaning. Those vectors are stored in a vector database (Pinecone, Chroma, Weaviate, Qdrant, Milvus, pgvector, FAISS, and others). At query time the system embeds the user's question, finds the nearest vectors by similarity search, pulls the associated source text, and injects it into the model's prompt as "context." The weaknesses in this category live in that pipeline—not in the model's weights.

Core Concept

INGESTION (offline)
  Documents ---> Chunker ---> Embedding model ---> [vectors] ---> Vector DB
                                                        (+ metadata: owner, tenant, ACL)

RETRIEVAL (per request)
  User query ---> Embedding model ---> similarity search ---> top-k chunks
                                                                 |
                                                                 v
                        [ System prompt + retrieved chunks + question ] ---> LLM ---> Answer

WHERE LLM08 LIVES
  * Who is allowed to retrieve a given vector?      (access control / multi-tenancy)
  * Can stored vectors be turned back into text?    (embedding inversion)
  * Who controls what got ingested?                 (knowledge / data poisoning)
  * Is retrieved text trusted blindly?              (indirect prompt injection)
  * Is the vector store itself protected?           (encryption, network exposure)

The unifying theme is this: a RAG system treats whatever the retriever returns as trusted, authoritative context. If an attacker can influence what is retrieved, who can retrieve it, or what the stored vectors reveal, they can steer answers, exfiltrate other users' data, or reconstruct sensitive source text—often without ever touching the model itself.

Why Does This Matter?

Vector and Embedding Weaknesses matter because RAG is frequently bolted on to give an LLM access to an organisation's most sensitive corpora: support tickets, HR records, legal contracts, source code, patient notes, financial reports. The retrieval layer becomes a new, often unaudited, data-access path that sits outside the application's normal authorization checks.

Business Impact

Technical Impact

Technical Context

How Embeddings and Vector Stores Actually Work

An embedding model maps text to a fixed-length vector (for example 384, 768, 1536, or 3072 dimensions). Texts with similar meaning map to vectors that are close together under a distance metric—usually cosine similarity, dot product, or Euclidean distance. A vector database indexes these vectors (commonly with an approximate-nearest-neighbour structure such as HNSW or IVF) so that "find the k most similar chunks to this query" runs in milliseconds over millions of vectors.

query_vec = embed("What is our refund policy?")
results   = index.search(query_vec, k=5)          # returns 5 nearest chunks
context   = "\n".join(r.text for r in results)     # concatenated into the prompt
answer    = llm(system_prompt + context + question)

Two properties of this design create the security surface:

Where the Weaknesses Arise

Weakness classWhere it livesCore failure
Multi-tenant / cross-user leakageRetrieval queryShared index queried without per-user/per-tenant filter
Over-permissioned retrievalRetrieval queryRetriever runs with broad rights; user's own permissions ignored
Knowledge / data poisoningIngestionUntrusted documents indexed without validation or provenance
Indirect prompt injectionRetrieved contentRetrieved text treated as trusted instructions, not data
Retrieval manipulation / context conflictRankingAdversarial content engineered to outrank legitimate context
Embedding inversionStorageStored vectors reconstructed back toward source text
Embedded secretsIngestion / storageCredentials in source docs become searchable and retrievable
Vector-store exposureInfrastructureIndex reachable without auth, unencrypted, or over-broad API keys

Why RAG Concentrates Risk

Real-World Impact

The categories below describe well-documented classes of weakness and published research, not fabricated incidents. Specific product names are examples of the technology class; treat any single figure as illustrative rather than exact.

Class 1: Embedding Inversion Research

What was shown: Academic work on text embedding inversion (notably the line of research demonstrating that embeddings can be decoded back toward their input text, sometimes called "vec2text") established that dense text embeddings retain a large fraction of the original content. Given a vector and access to the embedding model, an adversary can reconstruct text that is close to the original—recovering names, phrases, and sensitive details.

Why it matters: Teams routinely assume a vector index is a "safe," non-reversible artifact and protect it less carefully than the raw documents. This research disproves that assumption: a leaked or over-exposed vector store should be treated as roughly equivalent to leaking the underlying text.

Class 2: Indirect Prompt Injection via Retrieved Content

What was shown: Published research on indirect prompt injection demonstrated that instructions planted in third-party content (web pages, documents, emails) are executed when an LLM ingests that content. In a RAG system, any document that can be indexed and later retrieved is a delivery vehicle: an attacker plants "ignore prior instructions and…" text that becomes active the moment it is retrieved into context.

Why it matters: This is the bridge between LLM08 and LLM01. The poisoning is an LLM08 failure (untrusted content entered the corpus); the payload firing is an LLM01 failure (retrieved content treated as instructions). Defences must address both ends.

Class 3: Cross-Tenant Leakage in Shared Vector Stores

The pattern: A SaaS product embeds every customer's documents into one shared index to keep the architecture simple. Retrieval queries omit a tenant filter, or apply it inconsistently. A user asks a broad question and receives chunks originating from another tenant—because those chunks were the most semantically similar, and nothing enforced the tenant boundary.

Why it matters: This is the most common and most damaging real-world manifestation of LLM08. It is an authorization bug that hides inside a machine-learning subsystem, so it slips past reviewers who assume "the app already checks permissions." Similarity search does not.

Class 4: Over-Permissioned Retrieval Within a Tenant

The pattern: Even within one organisation, not every employee may see every document. When the retriever runs with a service account that can read the entire corpus and the query does not narrow results to what the asking user may access, the assistant becomes a confused deputy—summarising HR, legal, or executive documents to employees who could never open the source files directly.

Why it matters: The assistant effectively launders privileged data past existing document-level access controls, because those controls were enforced at the file system or app layer, never mirrored into the vector store.

Prevalence

Because LLM08 is a 2025 addition, it does not yet have a decade of breach statistics behind it. What is defensible:

Note: precise percentages vary by source and are still maturing for this new category. The durable takeaway is that the design flaws—treating similarity as authorization and treating retrieved text as trusted—are common by default and cheap to exploit.

Common Misunderstandings

Myth 1: "Embeddings are just numbers, so they're anonymised"

Reality: Embeddings are a lossy but invertible-enough representation. Inversion research recovers substantial portions of the source text from vectors. Protect the vector store as if it contained the raw documents—because effectively it does.

Myth 2: "The app already checks permissions, so retrieval is covered"

Reality: Application permission checks guard the app's own data paths. The vector index is a separate datastore with its own query path. Unless you replicate authorization into the retrieval query (metadata filters or per-tenant partitions), similarity search bypasses every check you wrote elsewhere.

Myth 3: "We can just tell the model in the system prompt to only answer about the user's own data"

Reality: A prompt instruction is not an access control. If the wrong chunks are already in context, the model may reveal them, and a prompt-injection payload can override the instruction. Authorization must happen before retrieval, at the datastore, not be delegated to the model's goodwill.

Myth 4: "Retrieved documents are our own trusted content"

Reality: Corpora are assembled from wikis, tickets, uploads, scraped pages, and connectors—any of which can be attacker-influenced. Treat every retrieved chunk as untrusted input that may contain injection payloads, and never let it silently become instructions.

Myth 5: "Poisoning requires compromising the database"

Reality: If your ingestion pipeline indexes a public page, a shared drive, or a user upload, an attacker only needs to get one malicious document into that source. No database breach is required—the pipeline invites the payload in.

Myth 6: "A managed vector database is secure by default"

Reality: Managed services secure their infrastructure, not your data model. Over-broad API keys, indexes reachable from the public internet, mixed-tenant namespaces, and missing metadata filters are all your responsibility and are common in real deployments.

How to Identify if You're Vulnerable

Ask these questions about your RAG system:

If you answered "no" or "not sure" to several of these—especially the first three—you likely have an exploitable retrieval-layer weakness today.

Next Steps