Vector and embedding weaknesses — OWASP LLM08 explained

It is worth being explicit about the boundary, because LLM08 review questions get conflated with adjacent ones often enough that a review can tick the box without ever reaching the embedding-specific risk. Tenant isolation asks whether one customer's retrieval can surface another customer's indexed content — a boundary enforced above the embedding layer, at the query and filter level. Document poisoning asks whether an attacker can insert a crafted document into a knowledge base so that it gets retrieved for a target query — an attack on the corpus, mediated through the embedding function but not aimed at the embedding space itself. Vector database security asks whether the infrastructure storing the vectors is configured correctly — access planes, encryption, API authentication.

This piece is about something upstream of all three: given an embedding vector, and given the embedding function that produced it, what can an attacker learn or do that has nothing to do with tenant boundaries, corpus write access, or infrastructure configuration? The two answers are inversion and embedding-space poisoning, and both apply to a system with a single tenant, a read-only corpus, and a perfectly configured vector database.

The premise behind treating raw embeddings as low-sensitivity data is that the transformation from text to vector is lossy and one-directional — you cannot run it backward, so storing or exposing the vector is safer than storing or exposing the text. That premise is not correct as a security boundary, only as a rough intuition, and it fails specifically for the embedding models in common commercial and open-weight use, whose vectors carry enough structure to be partially reversed.

This matters for a specific and common architecture decision: teams that would never store raw customer text in a lower-security tier will often store the embedding of that text there, on the reasoning that the vector is a derived, anonymized artefact. If that reasoning is wrong — and the research summarised below indicates it often is — the lower-security tier is holding data with meaningfully similar sensitivity to the source text, under a classification that assumed otherwise.

Embedding inversion is the class of technique that reconstructs some portion of a source text from its embedding vector, without access to the original text itself. The mechanism, at a conceptual level, does not require breaking any cryptographic property of the embedding — embeddings are not designed as a security primitive, so there is nothing to break in that sense. It requires training a second model, an inversion decoder, that learns the mapping from vector back to plausible text.

An attacker with access to the same embedding model (which is rarely secret — most production RAG and search systems use a publicly documented embedder, whether commercial or open-weight) can generate a large number of (text, embedding) pairs of their own choosing, and train a decoder network to map an embedding back toward text with similar semantic content. Applied to a victim's embedding — one the attacker did not generate and has no access to the source text for — the trained decoder produces a reconstruction that published research has shown can recover a substantial fraction of the original content's meaning, and in some cases specific phrases or entities, not just a vague paraphrase. The reconstruction is not exact and not guaranteed, but “partial and unreliable” is still a meaningful confidentiality failure for content that was assumed unrecoverable.

Inversion risk is most consequential precisely where embeddings are used outside a RAG pipeline, because those are the deployments where a team is least likely to have already classified the vector as sensitive. A personalization system that embeds a user's support tickets or purchase history to power recommendations is storing a representation of potentially sensitive personal content. A search index that embeds resumes, medical intake forms, or legal filings for semantic search is doing the same. A deduplication or clustering pipeline that embeds customer records to find near-duplicates stores a vector for every record it touches, often in a cache or log with weaker access control than the source database.

In each of these cases, the embeddings are frequently exposed more broadly than the source text — returned through an internal API for similarity lookups, cached for performance, or shipped to a third-party vector search service — precisely because they were assumed to be safe to move around more freely. Inversion risk means that assumption needs to be revisited for any embedding pipeline that touches personal data, confidential business content, or regulated information, regardless of whether the word “RAG” appears anywhere in the architecture.

The second LLM08-specific risk targets the embedding function's output space directly, rather than the documents that get embedded. The attacker's goal is to craft an input whose embedding lands adversarially close, in vector space, to a target embedding or cluster — close enough that a similarity search treats the crafted item as equivalent to the legitimate one it is imitating.

This is a different mechanism from a training-data poisoning attack, which corrupts a model's weights by manipulating what it learns from during training. It is a different mechanism from RAG document poisoning, which inserts a document into a corpus so that it gets retrieved for a target query — the attack there works through the corpus and the retrieval ranking, and the embedding function itself is untouched. Embedding-space poisoning works entirely at inference time, against a fixed, already-trained embedding model: it exploits the fact that semantic similarity in vector space is not the same thing as legitimacy, and that an adversarially optimized input can achieve high similarity to a target without sharing the target's actual meaning or provenance.

The practical consequence is anywhere a similarity-search decision carries security weight: a fraud-detection system that deduplicates against known bad actors by embedding similarity can be evaded by an input crafted to sit just outside the match threshold, or made to falsely match a trusted identity by an input crafted to sit just inside it. A recommendation or content-moderation system that clusters items by embedding proximity can be manipulated to place an adversarial item inside a “trusted” or “popular” cluster it does not actually belong in.

It is worth stating the boundary plainly, because the vocabulary overlap with RAG document poisoning invites conflation. RAG document poisoning asks: can an attacker get a crafted document into the corpus, such that it ranks highly for a target query? The embedding function is a tool the attacker uses, but the target of the attack is the corpus and the retrieval ranking. Embedding-space poisoning asks a narrower question with no corpus involved at all: can an attacker craft an input whose embedding is adversarially close to a target embedding, regardless of what document store, if any, the embedding ends up in?

The distinction has a direct consequence for where the control belongs. A document-poisoning control operates at ingestion — provenance checks, content validation, trust-tiered ranking. An embedding-space poisoning control operates at the embedding-comparison decision itself — regardless of whether that decision happens inside a RAG retrieval step, a fraud check, or a recommendation engine — and has to account for the possibility that similarity alone is not sufficient evidence of legitimate correspondence.

A narrower but related risk is fingerprinting: an attacker with access to a set of embedding vectors — through a leaked cache, an exposed API, or a compromised store — can often determine which embedding model and version produced them from the vector dimensionality and distributional characteristics alone, without any labeling. That matters operationally when the identified model or version has a known inversion vulnerability published against it, turning a generic data exposure into a specific, actionable one.

It also matters for a purely operational failure mode that a security review should still catch: an index that silently mixes embeddings from different model versions or checkpoints — after a provider update, a self-hosted model upgrade, or a migration that re-embedded only part of the corpus — produces similarity comparisons between vectors that were never trained to be comparable to each other. The failure looks like degraded retrieval quality, but the underlying cause is a versioning gap that a review should be able to rule out explicitly, not infer from symptom reports after the fact.

For any system that stores, transmits, or exposes embedding vectors — RAG or not — the review questions specific to LLM08 that the adjacent RAG pieces on this site do not already cover:

• Is the embedding model versioned and pinned, with a documented process for re-embedding the full corpus (not a partial migration) whenever the model or version changes?
• Are embeddings classified and handled as sensitive derived data — access control, encryption at rest, retention and deletion policy — matching the classification of the source text they were computed from, rather than a lower tier assumed safe because “it's just a vector”?
• Where source text is deleted for a retention or erasure obligation, does the corresponding embedding get deleted too — or does it persist as a residual, partially invertible copy of content the source-side deletion was meant to remove?
• Are raw embedding vectors exposed through any customer-facing or third-party API, and if so, is that exposure justified against the inversion risk rather than assumed safe by default?
• Is there a control — anomaly monitoring, periodic audit, or a similarity-threshold sanity check — for detecting embedding-space clusters that do not correspond to genuine content similarity, in any pipeline where a similarity-search decision carries security or fraud weight?

None of this replaces the tenant-isolation, document-poisoning, or vector-database-infrastructure checklists covered elsewhere. It sits alongside them, and a complete LLM08 review verifies all four boundaries — naming which one each finding belongs to, because the fix for an unpinned embedding model and the fix for a leaking metadata filter are different teams and different urgency.