Black-Hole Attack: envenenar una base de datos vectorial mediante la geometría de los embeddings

¿Qué es esto?

Can You Trust the Vectors in Your Vector Database? Black-Hole Attack from Embedding Space Defects (arXiv 2604.05480, publicado el 7 de abril de 2026) describe un ataque de envenenamiento contra las bases de datos vectoriales que sustentan la mayoría de los sistemas RAG. El atacante inyecta un pequeño número de vectores maliciosos cerca del centro geométrico de los embeddings almacenados. Esos vectores se comportan entonces como un agujero negro: son atraídos a los resultados top-k para una proporción desmesurada de consultas, sin importar lo que el usuario haya preguntado realmente.

Lo notable del hallazgo es que no explota un fallo de un modelo o un índice concretos. Explota la geometría misma de los espacios de embeddings de alta dimensión. Los autores informan de que un único vector implantado puede aparecer en hasta el 99,85 % de los top-10, y de que una tasa de envenenamiento del 1 % basta para contaminar gravemente la recuperación.

Cómo funciona

El ataque se apoya en una propiedad que los autores denominan centrality-driven hubness (hubness impulsada por la centralidad). En un espacio de alta dimensión poblado por un conjunto finito de embeddings reales, la región en torno al centroide está casi vacía en la práctica; sin embargo, un punto situado allí está, en promedio, más cerca de un número muy grande de otros puntos que cualquier vector normal. Un vector en el centroide se convierte así en el vecino más cercano de muchas consultas sin relación entre sí. El atacante simplemente calcula el centroide (global, o por clúster para un objetivo más fino) y escribe vectores allí.

# Forma conceptual del ataque — NO es un exploit operativo.
# El atacante necesita acceso de ESCRITURA al corpus/índice, y luego coloca
# un vector en el centro empírico de los embeddings almacenados.
centroid = stored_vectors.mean(axis=0)        # global o por clúster
malicious_vector = centroid                    # se sitúa en la región "hub"
# Una vez indexado, este vector se recupera como vecino top-k para una
# fracción desproporcionada de consultas, desplazando los resultados legítimos.

El ataque es independiente de la consulta (no se necesita acceso a las consultas del usuario) e independiente del modelo (apunta a la geometría de los embeddings, no a un codificador concreto). El artículo señala que la distancia euclídea es notablemente más vulnerable que la distancia coseno —la normalización L2 proyecta los vectores sobre una hiperesfera y cancela en parte el sesgo del centroide—, pero que la hubness persiste incluso bajo similitud coseno (probabilidad superior a 0,74 con centroides por clúster). Sobre todo, los índices ANN (Approximate Nearest Neighbor) estándar no ofrecen ninguna protección.

Por qué importa

La amenaza es doble. Primero, la integridad: un vector agujero negro puede introducir contenido controlado por el atacante en la ventana de contexto de casi todas las consultas RAG, un potente vehículo de difusión para inyección de prompts indirecta o desinformación. Segundo, la disponibilidad: al saturar los top-k legítimos, degrada silenciosamente la calidad de cada búsqueda, una denegación de servicio contra la recuperación, difícil de detectar.

Cualquier organización que opere un almacén vectorial que ingiera datos de fuentes semiconfiables está afectada: índices compartidos o multiinquilino, documentos aportados por usuarios, rastreadores automáticos que alimentan una base de conocimiento, o cualquier flujo donde un atacante pueda lograr que se escriban aunque sea un puñado de registros. Un resultado complementario de junio de 2026, When Poison Fails After Retrieval (arXiv 2606.11265), muestra la advertencia inversa —algunos ataques de envenenamiento de corpus se desvanecen en cuanto se aplica un reranker—, de modo que los defensores no deben ni presuponer el peor caso ni darse por seguros.

Defensas

El artículo evalúa dos direcciones defensivas y reconoce con franqueza que ninguna es una victoria limpia.

• Controle quién puede escribir vectores. El ataque requiere insertar registros en el índice. Trate el acceso de escritura como un privilegio: autentique y autorice la ingesta, aísle a los inquilinos en índices separados, y revise o aísle en sandbox cualquier fuente automática capaz de añadir embeddings.
• Mitigación de la hubness, con conocimiento de causa. Transformaciones como la normalización L2 centrada (CL2), TCPR o noHub reducen la frecuencia con que aparecen los vectores maliciosos, pero varias destruyen la utilidad de la búsqueda (TCPR llevó la presencia maliciosa a ~0,1 % pero hundió el Recall@10 casi a cero). CL2 ofreció el mejor compromiso reportado (Recall@10 moderado, en torno al 59–77 %). La normalización Z-score preservó el recall pero apenas frenó el ataque.
• Detecte los vectores sobrerecuperados. Tome un pequeño conjunto de sondas de la base, cuente con qué frecuencia se devuelve cada vector almacenado como vecino, y elimine los seleccionados de forma anormalmente frecuente. Los autores informan de una caída de la presencia maliciosa de ~94 % a ~1 % en algunos conjuntos de datos, eliminando solo ~0,1 % de los vectores y conservando un recall benigno cercano al 99 %, a costa de una pasada k-NN adicional completa, que escala mal en índices muy grandes.
• Prefiera el coseno a la euclídea pura cuando la aplicación lo permita, y vigile las distribuciones de recuperación: un único documento que aparece en muchas consultas sin relación es, en sí mismo, una señal de alerta que conviene notificar.

Estado

Se trata de investigación académica publicada (en formato de envío PVLDB) que describe una debilidad fundamental e independiente del modelo en la recuperación densa, no de un exploit contra un producto concreto. Fecha clave: preprint de arXiv publicado el 7 de abril de 2026 (arXiv 2604.05480). La conclusión de los autores es lo esencial: las mitigaciones existentes intercambian seguridad por calidad de recuperación, por lo que las defensas robustas para bases vectoriales siguen siendo un problema abierto, y «los vectores de su base de datos» no deben creerse a ciegas.