SilentRetrieval : un empoisonnement de corpus RAG fluide qui passe les filtres de perplexité

De quoi parle-t-on ?

Le 27 mai 2026, un préprint intitulé SilentRetrieval: Hijacking Retrieval-Augmented Generation via Semantically-Preserving Adversarial Data Poisoning (arXiv 2605.28074) propose une attaque d’empoisonnement de corpus qui survit aux deux filtres sur lesquels les équipes RAG en production s’appuient le plus souvent : le score de récupération et la détection d’anomalies par perplexité. Les documents empoisonnés se lisent comme du texte ordinaire, s’insèrent naturellement dans le corpus, et n’orientent le modèle vers la réponse choisie par l’attaquant qu’une fois récupérés.

Le papier prolonge une lignée de travaux ouverte par PoisonedRAG en 2024 et déclinée en variantes pratiques et boîte noire en 2025. L’ingrédient nouveau est la fluidité : les attaques précédentes laissaient des empreintes de perplexité que les défenseurs pouvaient repérer par filtrage statistique. SilentRetrieval co-optimise explicitement la récupérabilité et la vraisemblance linguistique, ce qui en fait davantage qu’un énième résultat de poisoning.

Comment ça marche

L’attaque se déroule en deux étapes.

Étape 1 — Coordinated Beam Search (CBS). Plutôt que de muter un document hôte token par token contre un objectif de similarité de récupération, CBS cherche conjointement des éditions multi-tokens contre un objectif combiné qui récompense à la fois la similarité sémantique à la requête cible et une perplexité faible sous un modèle de référence. Le résultat est un document hôte qui reste récupérable pour la requête visée et qui se lit naturellement.

Étape 2 — Context-Adaptive Trigger Generation (CATG). Un LLM figé est ensuite utilisé pour fusionner un petit « déclencheur » — la manipulation que l’attaquant veut voir suivie — dans le contenu fluide. CATG adapte la formulation du déclencheur au contexte environnant, de sorte que le document fusionné ne présente pas les ruptures de style typiques d’une instruction injectée.

Une lecture utile du dispositif :

# Deux filtres en lesquels les défenseurs ont confiance — ce que SilentRetrieval en fait

  Filtre de récupération
    « Écarter les documents dont la similarité aux requêtes récentes est suspecte. »
    → CBS maintient le document empoisonné dans le top-k pour la requête cible
      sans l'optimiser jusqu'à devenir une valeur aberrante évidente.

  Filtre de perplexité
    « Écarter les documents dont le texte de surface est statistiquement étrange. »
    → CBS est contraint de conserver une perplexité proche de la ligne de base du corpus ;
      CATG fusionne le déclencheur de sorte que la couture ne se voit pas.

Chiffres rapportés par le papier, en configuration un document empoisonné par requête sur Natural Questions et MS MARCO : taux de présence dans le top-10 de 84,6 % / 81,3 % et taux de succès d’attaque LLM de 57,5 % / 54,8 %, le tout en gardant une perplexité proche de la ligne de base. L’attaquant n’a besoin de placer qu’un seul document fluide par requête visée.

Pourquoi c’est important

Trois propriétés distinguent ce résultat du gros titre habituel sur l’empoisonnement de corpus.

La première est le modèle de menace. SilentRetrieval ne suppose ni accès aux poids du retriever, ni accès au modèle répondeur. L’attaquant doit seulement pouvoir écrire dans le corpus — ce qui, dans un déploiement réel, inclut toute source que le RAG ingère automatiquement : wikis, systèmes de ticket, crawls publics, documentation tierce, fichiers déposés par les utilisateurs, bases de connaissances fournisseurs. Chacun de ces canaux d’écriture porte désormais un risque d’intégrité non négligeable.

La deuxième est l’angle mort défensif. Beaucoup de stacks RAG en production reposent sur une combinaison de (a) listes blanches de sources, (b) scoring de récupération par similarité et (c) classifieurs de perplexité ou de type « ça ressemble à de l’injection » sur le morceau récupéré. SilentRetrieval est construit par conception pour survivre à (b) et (c). Les listes blanches ((a)) ne tiennent que si tous les canaux d’ingestion sont curés, ce qui est rarement le cas dès que le système touche aux uploads utilisateurs ou aux données web.

La troisième est l’angle économique. Un document empoisonné par requête visée suffit à pousser le taux de succès au-delà de 50 % sur des benchmarks standards. C’est une écriture courte, répétable, peu bruyante — exactement le type de contribution qui passe inaperçu parmi des contenus ordinaires.

L’attaque entre directement dans le champ OWASP LLM04:2025 — Data and Model Poisoning, avec un recouvrement vers LLM08:2025 (Vector and Embedding Weaknesses). C’est un résultat de recherche, pas un 0-day visant un produit nommé, mais il rend plus aigüe la question de ce qu’un propriétaire de corpus RAG peut réellement faire confiance à son propre index.

Défenses

Aucun contrôle unique ne retire cette classe d’attaques. La liste qui tient en mai 2026 :

1. Traitez le corpus RAG comme une frontière d’écriture, pas seulement de lecture. Authentifiez et journalisez chaque canal d’ingestion. Étiquetez les entrées avec source, ingested_by, ingested_at. L’échec le plus fréquent en production est que « le corpus » est en réalité la jointure d’une douzaine de canaux d’écriture dont personne n’a la responsabilité.
2. Notez la récupération sur la provenance, pas seulement la similarité. Un résultat à haute similarité issu d’une source à faible confiance doit être déprioritisé ou mis en revue avant d’atteindre le contexte du générateur.
3. Défendez à l’étape de réponse, pas seulement à l’étape de récupération. Des approches comme Traceback of Poisoning Attacks to RAG (avril 2025, mises à jour jusqu’en 2026) attribuent une réponse générée à des documents précis : une réponse suspecte permet d’identifier la source qui l’a induite — utile pour la réponse à incident et le nettoyage continu du corpus.
4. Réduisez l’effet de levier d’un document unique. Exigez la corroboration d’au moins deux documents récupérés issus de buckets de provenance indépendants avant que le générateur ne traite un fait comme acquis. Les chiffres de SilentRetrieval supposent un document empoisonné par requête : exiger deux sources indépendantes élève le coût pour l’attaquant de façon approximativement quadratique.
5. Surveillez les anomalies conditionnées à la requête. Un document qui apparaît dans le top-k pour une requête inhabituellement spécifique ou sensible, surtout si ce n’était pas une réponse naturelle à cette requête une semaine plus tôt, mérite un signalement — même quand son texte de surface est propre.
6. Limitez le rayon d’impact aval. Une réponse générée qui déclenche un appel d’outil ou une action visible par l’utilisateur ne doit pas hériter d’une confiance pleine du corpus. Les mêmes ACL par outil et confirmations humaines qui limitent les abus d’agents limitent les abus de RAG.

Statut

Élément	Référence	Date	Notes
Papier SilentRetrieval	arXiv 2605.28074	2026-05-27	84,6 %/81,3 % HR@10, 57,5 %/54,8 % ASR-LLM sur NQ / MS MARCO
PoisonedRAG (précurseur)	arXiv 2402.07867	2024-02	premier empoisonnement de corpus RAG largement cité
Défense Traceback	arXiv 2504.21668	2025-04	attribue les réponses générées aux documents récupérés
Catégorie	OWASP LLM Top 10 (2025)	2025	LLM04 Data and Model Poisoning + LLM08 Vector and Embedding Weaknesses

Le papier est un résultat de recherche, pas un exploit divulgué contre un fournisseur nommé. Sa lecture opérationnelle ne dépend pas d’une stack en particulier : tout pipeline RAG qui accepte du contenu d’un canal qu’il ne contrôle pas a ajouté une surface d’intégrité que le filtrage par perplexité seul ne couvrira pas.