Vector and Embedding Weaknesses
Security risks in any system that turns text, images, code, or audio into vectors and uses similarity search to decide what the model sees — poisoning makes it wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate.
What it is
Vector and embedding weaknesses appear in any application that converts text, images, code, or audio into numerical representations and uses similarity search to decide what the model sees. Retrieval-Augmented Generation is the familiar case, but the same machinery underlies vector-backed agent memory, semantic caches, and deduplication. Whenever similarity search sits between a data source and the prompt, the embedding layer becomes part of the trust boundary.
These weaknesses are distinct from prompt injection: they exploit the geometry of the embedding space and the mechanics of similarity search rather than the model's instruction-following, and many succeed even when the retrieved content carries no malicious instructions at all. A useful frame: poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and access-control failure makes it indiscriminate.
This entry covers attacks that depend on the embedding layer. Indirect prompt injection through retrieved content is LLM01, training-time poisoning of the embedding model is LLM05, and serialization flaws in vector-store libraries are LLM04. Vectorless retrieval (BM25-only) inherits the non-geometric risks but has no embedding attack surface.
Common examples
- Cross-tenant leakage via shared similarity search: when access control is applied after the search runs across the whole index, an attacker infers the existence, topic, and volume of other tenants' documents from result counts, scores, and timing.
- Embedding inversion: stored embeddings can be inverted to recover source text (up to 92% exact reconstruction of short inputs), so a vector-store backup should be treated as equivalent to a leak of the underlying documents.
- Retrieval-time data poisoning: content crafted so its embedding lands near a target query is retrieved and fed to the model as trusted context, reliably succeeding with a handful of documents even in huge corpora.
- Retrieval jamming: a “blocker” document engineered to be retrieved for a query makes the model refuse or claim it lacks information — an availability attack carrying no malicious instructions.
- Membership inference via similarity search: raw similarity scores turn the index into a membership oracle revealing whether a specific sensitive document exists.
- Semantic cache and deduplication poisoning: content crafted to straddle the similarity threshold serves attacker text to equivalent queries or silently drops legitimate new content.
- Multimodal embedding poisoning: an unremarkable-looking image whose embedding sits near a sensitive text query is retrieved as trusted context, invisible to text-based scanning.
Prevention & mitigation
- Enforce permission and access control in the query. Apply tenant scoping inside the index query and validate it server-side; a client-supplied scope is a suggestion, not a control. Apply access control at the chunk level, and use physically separate indexes for high-sensitivity workloads.
- Validate, authenticate, and track provenance. Normalise content before embedding (strip zero-width characters and homoglyphs), record source, ingestion time, and trust tier for every embedding, and vet the embedding model itself — a backdoored encoder corrupts everything.
- Segregate by trust tier. Never let mixed-trust content share an index without hard isolation; index-level segregation beats classification tags because it removes the misconfiguration path.
- Detect anomalies at ingest and retrieval. Flag vectors that sit unusually close to many common queries, watch for queries returning too many high-similarity matches, and do not return raw similarity scores to clients.
- Control the storage lifecycle. Delete embeddings when the source is deleted and verify by reconciliation, treat backups at source sensitivity, encrypt at rest with separately-managed keys, and re-embed the whole corpus when rotating the embedding model.
- Log and plan incident response. Keep immutable retrieval logs, monitor for tenant-filter bypass, and update playbooks so “embeddings-only” leaks are handled as source-data leaks for breach assessment.
Example attack scenarios
- A RAG system scrapes public docs on a schedule; an attacker publishes posts engineered so their embeddings land near an internal query, so when an employee asks that question the attacker's content is retrieved — the same text pasted into chat would have no effect.
- A multi-tenant product filters tenants at the application layer, but similarity search runs across every embedding first; over many probing queries one tenant maps another's data from timing and score gaps without ever seeing a document.
- A cloud misconfiguration exposes a vector-store backup initially dismissed as “only embeddings”; a zero-shot inversion reconstructs a large fraction of the source PII, and the incident is reclassified as a source-document breach.
References
- OWASP Top 10 for LLM Applications 2026 — LLM09:2026 Vector and Embedding Weaknesses: genai.owasp.org
- Morris et al. — Vec2Text: embedding inversion (2023)
- MITRE ATLAS — AML.T0070 RAG Poisoning
- OWASP GenAI Data Security (DSGAI) 2026 — DSGAI13
- ASI06:2026 Memory and Context Poisoning (Agentic Top 10)
How Neural Industries helps. We treat your embedding layer as part of the attack surface — testing cross-tenant leakage, inversion, poisoning, and jamming against your RAG and vector memory — and help you enforce in-query access control and provenance.
Request an assessment →