Vector and Embedding Weaknesses

Any system that turns text, images, code or audio into vectors and then uses similarity search to decide what the model sees has put the embedding layer inside its trust boundary. Retrieval-Augmented Generation is the familiar case, but the same machinery sits under vector-backed agent memory, semantic caches and deduplication pipelines. LLM09:2026 covers the attacks that work because of that machinery.

The distinction from prompt injection is the thing to hold onto. These attacks exploit the geometry of the embedding space and the mechanics of similarity search, not the model’s instruction-following. Many of them succeed when the retrieved content contains no instructions at all. OWASP offers a compact frame: poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate.

Scope: what belongs here and what does not

The entry covers attacks that depend on the embedding layer to succeed. Adjacent failures are owned elsewhere:

One consequence is worth stating plainly: vectorless retrieval systems (BM25-only search, LLM-native tree navigation) inherit the non-geometric risks but have no LLM09 attack surface. If your retrieval is lexical, most of this page does not apply to you, and that is a legitimate architectural answer for a high-sensitivity corpus.

Embedding inversion: vectors are the documents

The assumption that embeddings are a lossy, non-reversible representation is the single most expensive mistake in this area, and the research record has closed it.

The two zero-shot methods matter more than the headline percentage. Vec2Text needs a model trained per encoder, which is a real cost and a real dependency on knowing the encoder. ZSInvert and Zero2Text do not, they work in black-box settings, and OWASP records that they remain effective against differential-privacy noise added at storage, so the obvious mitigation of perturbing stored vectors does not close the gap.

The operational conclusion follows directly. Vector-database backups, embeddings shipped to third-party services, and embeddings exposed through misconfigured cloud storage should be treated as equivalent to a leak of the underlying documents. Under GDPR and comparable regimes, breach notification depends on risk to data subjects; because modern embeddings can be inverted, that risk is real rather than theoretical. “Only the embeddings leaked” is not a safe-harbour classification, and an incident-response playbook that treats it as one will under-notify.

Retrieval that runs before access control

In multi-tenant deployments, similarity search frequently runs across the full index and tenant filtering is applied afterwards, at the application layer. Every document may be correctly tagged and every API call properly authenticated, and the leak still happens, because the access-control decision is made after the embedding-space search has already touched every tenant’s vectors.

What an attacker extracts is not documents but structure: the existence, topic and approximate volume of other tenants’ content, inferred from result counts, score distributions and timing. Over many probing queries that composes into a usable map of a competitor’s corpus.

OWASP is careful about scope here. Conventional authentication flaws in vector-database software are out of scope for this entry, but they compound the geometric risk, and the entry names two:

The reasoning the entry attaches to those is the important part: because a vector-store leak is recoverable to source documents via inversion, an authentication bug in a vector database carries higher consequence than the same bug in a document database or key-value store. The vector store should sit in the same sensitivity tier as the documents it was built from, not a lower one.

Retrieval-time poisoning

An attacker who can write to the corpus (through public scraping pipelines, file uploads, partner feeds, or a compromised internal source) can craft content whose embedding lands close to a target query. When a user submits that query, the attacker’s content is retrieved and handed to the model as trusted context. Published attacks reliably achieve high success rates with a handful of poisoned documents, even in corpora of millions and against black-box systems.

A successful attack requires two conditions at once: the poisoned content must be retrieved (geometric) and it must steer the response (generation). Defenders can intervene at either layer, which is the practical opening. A re-ranker or a generation-side check breaks the chain even if the ingest control failed. MITRE ATLAS catalogues this class as AML.T0070 (RAG Poisoning) under the Persistence tactic. Poisoning the embedding model itself, at training time, belongs to LLM05:2026, not to this entry.

Multimodal poisoning is the harder variant. Cross-modal encoders such as CLIP and ColPali map images, audio, code and text into one vector space, so an attacker who can contribute non-text content can craft an image whose embedding sits near a sensitive text query. MM-PoisonRAG (Ha et al., 2025) and Poisoned-MRAG (Liu et al., 2025) demonstrate local and global poisoning across multimodal RAG pipelines, and “One Pic is All it Takes” shows that a single image suffices for both targeted and universal VD-RAG poisoning. To a human reviewer the image looks unremarkable, and text-based content scanning does not catch it because the payload is not text.

Jamming, membership inference, and cache poisoning

Retrieval jamming is the availability attack. An attacker inserts a “blocker” document engineered to be retrieved for a specific query and to make the model refuse to answer or claim it lacks information. The blocker carries no malicious instructions; it exploits retrieval mechanics and the model’s own safety behaviour. A single blocker document, generated through black-box optimisation without access to the target embedding model or LLM, is sufficient.

Membership inference targets existence rather than content. The attacker wants to know whether a specific document (a medical record, a legal filing, an HR complaint) is in the index. If the application returns raw similarity scores or distances to the client, the index becomes a direct membership oracle with no model involvement at all. If it returns only generated answers, membership can still be inferred by submitting partial documents or perturbed queries and analysing the responses. Membership information can itself be sensitive even where the content stays protected.

Semantic cache and deduplication poisoning attacks the threshold. Semantic caches and near-duplicate detection use a cosine-similarity cut-off to decide two things are “the same”. An attacker who can craft content landing just above or below that threshold can:

• poison a cache entry so it serves attacker text to every semantically equivalent query;
• bypass deduplication with near-duplicates of poisoned content;
• force legitimate new content to be silently dropped as a duplicate.

Wu et al. (2026) demonstrate semantic cache poisoning end-to-end across AWS, Azure and Alibaba deployments. Z. Zhang et al. (2026) show black-box key-collision attacks that use surrogate embedding models to engineer threshold-straddling vectors without access to the target encoder. All three failure modes depend on embedding-space geometry and are invisible to document-level controls - the documents involved are individually unremarkable.

Mitigations

Permission and access control

Enforce tenant scoping inside the index query, not as a post-retrieval filter, and validate it server-side; a client-supplied scope is a suggestion, not a control. Authenticate embedding and similarity-search endpoints as first-class APIs with per-tenant rate limits. For high-sensitivity workloads, use physically separated indexes per tenant or trust zone. Apply access control at the chunk level, because a mostly-public document can contain a confidential paragraph.

Validation, source authentication and provenance

Normalise content before embedding: strip zero-width characters, white-on-white text and Unicode homoglyphs at extraction time. Track provenance for every embedding (source, ingestion time, trust tier, pipeline version) so a compromised batch can be identified, invalidated and audited without forcing a full re-index. Apply human review to externally sourced content destined for sensitive indexes. Vet the embedding model itself: a backdoored encoder corrupts the geometry of everything ingested through it.

Segregation by trust tier

Mixed-trust content (external web data, internal confidential documents, partner data) must not share an index without hard isolation. OWASP is explicit that index-level segregation beats classification tags on a shared index, because it removes the misconfiguration path. The trade-off is real: separate indexes mean multiple queries, a merge step, and worse recall for questions that span tiers. That cost buys the removal of an entire class of filter-bypass bug.

Anomaly detection at ingest and retrieval

Flag new vectors that sit unusually close to a wide range of common queries. That is the signature of retrieval-hijacking poisoning. Watch for queries returning too many high-similarity matches, unusual volume on embedding endpoints (a precursor to query-based inversion), and clusters growing faster than expected after an ingest. Do not return raw similarity scores to clients. Add noise and diversification at the retrieval-ranking layer, and rate-limit any endpoint that could be queried as an oracle. Cross-encoder re-ranking raises attack cost but does not replace provenance and ingest controls, because modern attacks target retrieval and ranking jointly.

Storage lifecycle

Delete embeddings within a bounded time when the source document is deleted, and verify it with reconciliation audits. An orphaned vector is a retained, invertible copy of a deleted document. Treat vector-database backups at the same sensitivity tier as the source documents. Encrypt embeddings at rest with keys managed separately from the application layer. When rotating the embedding model, re-embed the whole corpus instead of mixing old and new vectors; heterogeneous embeddings create exploitable gaps in similarity behaviour. Treat embedding-API keys as secrets, since a leaked key gives an attacker query access to your exact encoder, which is what turns several of the black-box attacks above into white-box ones.

Monitoring, logging and incident response

Keep immutable logs of retrieval activity: tenant scope, query, returned IDs, similarity scores. Monitor for tenant-filter bypass attempts, cross-tenant retrieval anomalies and abnormal embedding-API consumption. Update incident-response playbooks so that “embeddings only” leaks are handled as source-data leaks for breach assessment and notification under GDPR Article 33 and analogous regimes.

Attack scenarios

Embedding similarity attack on a public ingestion pipeline. A company’s RAG system scrapes public documentation and forum posts on a schedule. An attacker publishes posts engineered so their embeddings land near specific internal queries, such as “what is our Q3 revenue projection”. When an employee asks that question, the attacker’s content is retrieved and fed to the model. The same text pasted directly into a chat would have no effect. The attack works only because the attacker can place content near a target query in embedding space.

Cross-tenant inference in a shared index. A multi-tenant SaaS product uses one shared vector index with tenant filtering at the application layer. Tenant A submits probing queries; similarity search runs across every embedding, including Tenant B’s, before the filter applies. A never sees B’s documents, but timing differences, result counts and score-distribution gaps reveal the existence and approximate topic of B’s content, and over many queries A builds a useful map. OWASP cites CVE-2025-69286 (RAGFlow), where predictable token generation enabled cross-account compromise in a widely deployed open-source RAG engine, as a real-world incident in this category.

Inversion from a leaked vector store. A cloud misconfiguration exposes a backup of a production vector database. The underlying documents (customer conversation logs containing PII) are encrypted separately and not exposed, so the incident is initially classified low-severity on the basis that “only the embeddings leaked”. The attacker runs a zero-shot inversion attack against the stolen embeddings and reconstructs a substantial fraction of the source content, including PII, without access to the original encoder. The incident is reclassified as equivalent to a source-document breach and the notification obligations are reassessed.

Related entries

• LLM01:2026 Prompt Injection - instructions carried inside retrieved content; poisoned retrieval is often the delivery route.
• LLM08:2026 Hidden Context Exposure - retrieved policy text is part of the hidden context, so a retrieval-scoping failure is also a context-disclosure failure.
• LLM10:2026 Improper Output Handling - what the model does with poisoned context becomes output that some downstream component will consume.
• AI security overview - the full 2026 list and how the entries relate.