Black-Hole Attack : empoisonner une base vectorielle via la géométrie des embeddings

De quoi s’agit-il ?

Can You Trust the Vectors in Your Vector Database? Black-Hole Attack from Embedding Space Defects (arXiv 2604.05480, publié le 7 avril 2026) décrit une attaque par empoisonnement contre les bases de données vectorielles qui sous-tendent la plupart des systèmes RAG. L’attaquant injecte un petit nombre de vecteurs malveillants près du centre géométrique des embeddings stockés. Ces vecteurs se comportent alors comme un trou noir : ils sont aspirés dans les résultats top-k pour une part disproportionnée des requêtes, indépendamment de ce que l’utilisateur a réellement demandé.

L’intérêt du résultat tient à ce qu’il n’exploite pas un défaut d’un modèle ou d’un index particulier. Il exploite la géométrie même des espaces d’embeddings en grande dimension. Les auteurs rapportent qu’un seul vecteur implanté peut apparaître dans jusqu’à 99,85 % des top-10, et qu’un taux d’empoisonnement de 1 % suffit à contaminer gravement la recherche.

Comment ça marche

L’attaque repose sur une propriété que les auteurs nomment centrality-driven hubness (hubness pilotée par la centralité). Dans un espace de grande dimension peuplé d’un ensemble fini d’embeddings réels, la région autour du centroïde est presque vide en pratique — pourtant, un point placé là est en moyenne plus proche d’un très grand nombre d’autres points que ne l’est un vecteur normal. Un vecteur au centroïde devient donc le plus proche voisin de nombreuses requêtes sans rapport entre elles. L’attaquant calcule simplement le centroïde (global, ou par cluster pour un ciblage plus fin) et y écrit des vecteurs.

# Forme conceptuelle de l'attaque — PAS un exploit opérationnel.
# L'attaquant a besoin d'un accès en ECRITURE au corpus/index, puis place
# un vecteur au centre empirique des embeddings stockés.
centroid = stored_vectors.mean(axis=0)        # global ou par cluster
malicious_vector = centroid                    # se situe dans la region "hub"
# Une fois indexe, ce vecteur est retrouve comme voisin top-k pour une
# fraction disproportionnee de requetes, evincant les resultats legitimes.

L’attaque est indépendante des requêtes (aucun accès aux requêtes utilisateur n’est nécessaire) et indépendante du modèle (elle vise la géométrie des embeddings, pas un encodeur précis). Le papier note que la distance euclidienne est nettement plus vulnérable que la distance cosinus — la normalisation L2 projette les vecteurs sur une hypersphère et annule en partie le biais du centroïde — mais que la hubness persiste même sous similarité cosinus (probabilité supérieure à 0,74 avec des centroïdes par cluster). Surtout, les index ANN (Approximate Nearest Neighbor) standards n’offrent aucune protection.

Pourquoi c’est important

La menace est double. D’abord l’intégrité : un vecteur trou noir peut introduire un contenu contrôlé par l’attaquant dans la fenêtre de contexte de presque toutes les requêtes RAG, vecteur de diffusion puissant pour de l’injection de prompt indirecte ou de la désinformation. Ensuite la disponibilité : en saturant les top-k légitimes, il dégrade silencieusement la qualité de chaque recherche — un déni de service contre la récupération, difficile à repérer.

Toute organisation exploitant un magasin vectoriel qui ingère des données de sources semi-fiables est concernée : index partagés ou multi-tenants, documents soumis par les utilisateurs, crawlers automatiques alimentant une base de connaissances, ou tout pipeline où un attaquant peut faire écrire ne serait-ce qu’une poignée d’enregistrements. Un résultat complémentaire de juin 2026, When Poison Fails After Retrieval (arXiv 2606.11265), montre la mise en garde inverse — certaines attaques par empoisonnement de corpus s’effacent dès qu’un reranker est appliqué — de sorte que les défenseurs ne doivent ni présumer le pire ni se croire à l’abri.

Défenses

Le papier évalue deux directions défensives et reconnaît franchement qu’aucune n’est une victoire nette.

• Contrôlez qui peut écrire des vecteurs. L’attaque nécessite d’insérer des enregistrements dans l’index. Traitez l’accès en écriture comme un privilège : authentifiez et autorisez l’ingestion, isolez les tenants dans des index séparés, et passez en revue ou en bac à sable toute source automatique capable d’ajouter des embeddings.
• Atténuation de la hubness, en connaissance de cause. Des transformations comme la normalisation L2 centrée (CL2), TCPR ou noHub réduisent la fréquence d’apparition des vecteurs malveillants, mais plusieurs détruisent l’utilité de la recherche (TCPR ramène la présence malveillante à ~0,1 % mais effondre le Recall@10 quasi à zéro). CL2 offre le meilleur compromis rapporté (Recall@10 modéré, environ 59–77 %). La normalisation Z-score préserve le rappel mais ne contre presque pas l’attaque.
• Détectez les vecteurs sur-récupérés. Tirez un petit ensemble de sondes de la base, comptez la fréquence à laquelle chaque vecteur stocké est renvoyé comme voisin, et retirez ceux sélectionnés anormalement souvent. Les auteurs rapportent une chute de la présence malveillante de ~94 % à ~1 % sur certains jeux de données, en ne retirant que ~0,1 % des vecteurs et en conservant un rappel bénin proche de 99 % — au prix d’une passe k-NN supplémentaire complète, qui passe mal à l’échelle sur de très grands index.
• Préférez le cosinus à l’euclidien brut lorsque l’application le permet, et surveillez les distributions de récupération : un document unique apparaissant dans de nombreuses requêtes sans rapport est en soi un signal d’alerte à remonter.

Statut

Il s’agit d’une recherche académique publiée (au format de soumission PVLDB) décrivant une faiblesse fondamentale et indépendante du modèle dans la récupération dense, pas d’un exploit contre un produit nommé précis. Date clé : préprint arXiv publié le 7 avril 2026 (arXiv 2604.05480). La conclusion des auteurs est le point à retenir : les atténuations existantes échangent sécurité contre qualité de récupération, si bien que des défenses robustes pour les bases vectorielles restent un problème ouvert — et « les vecteurs de votre base » ne doivent pas être crus aveuglément.