Black-Hole Attack: poisoning a vector database through embedding geometry

What is this?

Can You Trust the Vectors in Your Vector Database? Black-Hole Attack from Embedding Space Defects (arXiv 2604.05480, posted 7 April 2026) describes a poisoning attack against the vector databases that back most RAG systems. The attacker injects a small number of malicious vectors near the geometric center of the stored embeddings. Those vectors then behave like a black hole: they get pulled into the top-k retrieval results for a disproportionate share of queries, regardless of what the user actually asked.

What makes the finding notable is that it does not exploit a bug in any particular model or index. It exploits the geometry of high-dimensional embedding spaces itself. The authors report that a single planted vector can appear in up to 99.85% of top-10 results, and that even a 1% poisoning rate severely contaminates retrieval.

How it works

The attack rests on a property the authors call centrality-driven hubness. In a high-dimensional space populated by a finite set of real embeddings, the region around the centroid is almost empty in practice — yet a point placed there is, on average, closer to a very large number of other points than any normal vector is. A vector at the centroid therefore becomes the nearest neighbor of many unrelated queries. The attacker simply computes the centroid (globally, or per-cluster for finer targeting) and writes vectors there.

# Conceptual shape of the attack — NOT an operational exploit.
# The attacker needs WRITE access to the corpus/index, then places
# a vector at the empirical center of the stored embeddings.
centroid = stored_vectors.mean(axis=0)        # global or per-cluster
malicious_vector = centroid                    # sits in the "hub" region
# Once indexed, this vector is retrieved as a top-k neighbour for a
# disproportionate fraction of queries, displacing legitimate results.

The attack is query-agnostic (no access to user queries is needed) and model-agnostic (it targets the embedding geometry, not a specific encoder). The paper notes that Euclidean distance is markedly more vulnerable than cosine distance — L2-normalization projects vectors onto a hypersphere and partly cancels the centroid bias — but that hubness persists even under cosine similarity (probability above 0.74 with cluster-wise centroids). Crucially, standard Approximate Nearest Neighbor (ANN) indexes provide no protection.

Why it matters

The threat is two-fold. First, integrity: a black-hole vector can carry attacker-controlled content into the context window of nearly every RAG query, a powerful delivery vehicle for indirect prompt injection or disinformation. Second, availability: by crowding out the legitimate top-k, it quietly degrades the quality of every search, a denial-of-service against retrieval that is hard to notice.

Anyone running a vector store that ingests data from semi-trusted sources is in scope: shared or multi-tenant indexes, user-contributed documents, automated crawlers feeding a knowledge base, or any pipeline where an attacker can get even a handful of records written. A complementary June 2026 result, When Poison Fails After Retrieval (arXiv 2606.11265), shows the inverse caution — some corpus-poisoning attacks fade once a reranker is applied — so defenders should not assume the worst case nor a free pass.

Defenses

The paper evaluates two defensive directions and is candid that neither is a clean win.

• Control who can write vectors. The attack requires inserting records into the index. Treat write access as privileged: authenticate and authorize ingestion, separate tenants into isolated indexes, and review or sandbox any automated source that can add embeddings.
• Hubness mitigation, with eyes open. Transformations such as centered L2-normalization (CL2), TCPR, or noHub reduce how often malicious vectors surface, but several destroy retrieval utility (TCPR drove malicious presence to ~0.1% yet collapsed Recall@10 to near zero). CL2 offered the best reported trade-off (moderate Recall@10 of roughly 59–77%). Z-score normalization preserved recall but barely blunted the attack.
• Detect over-retrieved vectors. Draw a small probe set from the database, count how often each stored vector is returned as a neighbor, and remove the ones selected unusually often. The authors report malicious presence dropping from ~94% to ~1% on some datasets while removing only ~0.1% of vectors and leaving benign recall near 99% — though it adds a full extra k-NN pass and scales poorly to very large indexes.
• Prefer cosine over raw Euclidean where the application allows, and monitor retrieval distributions: a single document appearing across many unrelated queries is itself a red flag worth alerting on.

Status

This is published academic research (PVLDB submission format) describing a fundamental, model-agnostic weakness in dense retrieval, not an exploit against a specific named product. Key date: arXiv preprint posted 7 April 2026 (arXiv 2604.05480). The authors’ own conclusion is the operative takeaway: existing mitigations trade security against retrieval quality, so robust defenses for vector databases remain an open problem — and “the vectors in your database” should not be trusted blindly.