Haxoris Wiki

LLM09: Vector and Embedding Weaknesses (Retrieval Substrate)

Description

Vector and embedding weaknesses are failures in the retrieval substrate rather than in the model or the prompt. An embedding model turns documents, images and code into float arrays, a vector store indexes them, and a retriever runs approximate nearest-neighbour search, often fused with BM25 and reranked by a cross-encoder. Every stage behaves geometrically, not semantically. A vector is not a hash and not a redaction: it is a lossy but invertible encoding of its source text. A similarity score returned to a caller is a membership oracle. A top-k window is a scarce resource an attacker can compete for. And a vector database is a network service that usually ships with no authentication at all.

In deployed integrations this is an embedding endpoint on a shared gateway any tenant can call, a Qdrant or Chroma container with no api-key set, an index snapshot classified low because it holds “only embeddings”, or a retriever whose top-k an uploaded document can dominate. This entry arrived as LLM08:2025 and sits at LLM09 in 2026 with a widened scope: alongside cross-tenant similarity leakage and inversion it now covers retrieval jamming with blocker documents, membership inference from raw scores, semantic cache and near-duplicate threshold poisoning, and multimodal poisoning through cross-modal encoders such as CLIP and ColPali. The 2026 framing separates four outcomes - poisoning makes retrieval wrong, inversion makes it leak, jamming makes it silent, broken access control makes it indiscriminate - and scopes its neighbours explicitly: instructions executing out of retrieved text belong to LLM01, serialization flaws in vector-store libraries to LLM04, poisoning of the embedding model itself to LLM05, and conventional authentication bugs in vector-database software are named as compounding the geometric risk rather than as in-scope. In this wiki the application-layer cross-tenant filter bug is the Cross-Tenant RAG Retrieval Leakage page under LLM02 and durable corpus corruption is the RAG Knowledge Base Poisoning page under LLM05.

Keywords: embedding inversion, vector database exposure, similarity ranking abuse, membership inference, semantic cache poisoning, retrieval jamming, ann index dump

Examples/Proof

  • Vectors as documents
    • Pull raw float arrays from an embedding endpoint, an index scroll or a client-side bundle, then run a vec2text-style corrector. Recognisable source phrases prove the store carries source-document sensitivity. See the Embedding Inversion And Reconstruction page.
  • Top-k displacement
    • Upload a chunk optimised against the known encoder and re-ask the target question. Authoritative chunks pushed out of the retrieval window is the finding. See the Retrieval Ranking Manipulation page.
  • Unauthenticated store
    • GET /collections on port 6333 with no api-key header, or POST /v2/vectordb/collections/list with Bearer root:Milvus. A collection listing proves the store is not a boundary. See the Exposed Vector Database Endpoints page.
  • Score oracle
    • Query with a sentence lifted from a document you should not know about and read the returned similarity. A distinguishable high score confirms membership without returning content.

Detection and Monitoring

  • Retrieval telemetry
    • Log tenant scope, query fingerprint, returned point ids and scores immutably; alert on filterless queries, cross-tenant id sets and results with unusually many high-similarity hits.
  • Embedding-endpoint volume
    • Baseline embed calls and vector reads per credential. Bulk scrolls, snapshot downloads and sustained embed traffic are inversion precursors.
  • Ingest geometry
    • Flag new vectors sitting unusually close to many unrelated common queries, and near-duplicate clusters growing faster than the source corpus.

Remediation

  1. Authorise inside the index query
    • Build tenant, namespace and chunk-level filters server-side from the session identity, and use physically separate indexes per trust zone so a missing filter fails closed.
  2. Treat vectors as the documents they encode
    • Encrypt embeddings at rest with separately managed keys, classify snapshots and exports at source sensitivity, and never return raw vectors to a client.
  3. Authenticate the store and the embedding API
    • Set api-key or RBAC on every vector service, keep management ports off user-facing networks, patch known auth bypasses, and rotate default credentials.
  4. Suppress the oracle
    • Withhold raw similarity scores, rate-limit similarity and embed calls per tenant, and cap how much of a top-k window one source may hold.
  5. Bind provenance and lifecycle
    • Stamp source, ingest time, trust tier and pipeline version on every vector; delete embeddings with their source and re-embed rather than mixing model generations.

Prevention Checklist

  • No vector service reachable without authentication, and no default token still valid
  • Tenant and chunk-level filters applied inside the query, never after retrieval
  • Raw vectors and raw similarity scores never returned to untrusted callers
  • Snapshots, backups and embedding exports classified and encrypted as source data
  • Single-source top-k dominance capped, with ingest-time near-duplicate and geometry checks