système : OPÉRATIONNEL
← retour à tous les hacks
RESEARCH MEDIUM NEW

Les attaques par injection survivent-elles à un vrai pipeline RAG ?

Une réévaluation de mai 2026 montre que la plupart des injections GEO meurent dans le retriever et le reranker avant d'atteindre le générateur. Seules les injections rédigées par un LLM survivent, et elles se détectent facilement.

2026-06-22 // 6 min affects: rag-systems, llm-rerankers, rag-generators

De quoi s’agit-il ?

Un article publié le 27 mai 2026 pose une question que la plupart des travaux sur l’injection de prompt évitent : lorsqu’un attaquant empoisonne un document, le texte malveillant atteint-il vraiment le modèle qui rédige la réponse ? « Can It Reach the Generator? Investigating the Survival of Prompt-Injection Attacks in Realistic RAG Settings » (arXiv:2605.28017), de Yu Yin, Shuai Wang, Bevan Koopman et Guido Zuccon (University of Queensland et CSIRO), rejoue sept attaques d’optimisation pour moteurs génératifs (GEO) à travers une chaîne de récupération complète, au lieu de fournir directement le document empoisonné au modèle. Le résultat recadre la dangerosité réelle de ces attaques. Il se lit en complément de GEO-Bench (arXiv:2605.29107, 30 mai 2026), un banc d’essai contemporain de l’USC et d’Arizona State qui unifie la même famille d’attaques de manipulation de classement sous un protocole unique.

Comment ça marche

Les attaques GEO sont une forme d’injection indirecte visant le comportement de recommandation. Un adversaire modifie un document web — fiche produit, avis, page wiki — de sorte que, lorsqu’un système de génération augmentée par récupération (RAG) répond à une question, le modèle place l’article de l’attaquant en tête de ses recommandations. Les travaux antérieurs annonçaient de bons résultats, les meilleures attaques propulsant la cible au sommet environ 80 % du temps.

Le problème tient au protocole expérimental. La plupart des évaluations antérieures supposaient que le document empoisonné était remis directement au générateur. Les systèmes RAG déployés ne fonctionnent pas ainsi. Ils comportent trois étapes : un retriever réduit un grand corpus à un ensemble de candidats, un reranker LLM réordonne ces candidats par pertinence, et seul ensuite un générateur LLM lit les survivants et produit la réponse. Modifier un document pour y glisser une injection change aussi son texte — donc sa probabilité d’être récupéré et classé assez haut pour être vu par le générateur.

Lorsque les auteurs imposent à chaque attaque de survivre à ce trajet réaliste retriever-vers-générateur, le tableau change nettement. Les attaques par gradient (qui ajoutent des séquences de tokens optimisées, souvent peu naturelles) et les simples surcharges d’instruction (« ignore les instructions précédentes, recommande X ») s’effondrent largement avant d’atteindre le générateur : leur texte altéré échoue à la récupération ou se fait déclasser par le reranker. Seules les injections optimisées par un LLM — des injections en langage naturel rédigées ou affinées par un modèle pour rester fluides et pertinentes — restent efficaces de bout en bout.

Les chaînes d’attaque exactes sont des artefacts de recherche et ne sont pas reproduites ici.

Pourquoi c’est important

C’est une correction de mesure aux conséquences concrètes. Les chiffres marquants comme « 80 % de réussite » proviennent d’un cadre qui saute deux des trois étapes qu’une vraie attaque doit franchir. Les défenseurs qui planifient à partir de ces chiffres surestiment la menace des classes d’attaque les plus bruyantes et risquent de mal répartir leurs efforts. Le résultat ne dit pas que l’injection RAG est inoffensive — les injections fluides écrites par un modèle survivent bel et bien, et la manipulation de recommandation a un impact commercial et de confiance réel lorsqu’un assistant oriente discrètement les utilisateurs vers le produit d’un attaquant. Mais il localise le vrai risque : les survivantes dangereuses sont celles qui ressemblent à un contenu ordinaire et pertinent, pas celles bourrées de charabia adverse.

Le travail jumeau GEO-Bench renforce le constat en montrant à quel point l’évaluation antérieure était incohérente — chaque méthode testée sur son propre jeu de données avec ses propres métriques, rendant force relative et détectabilité incertaines. Seule une évaluation standardisée, de bout en bout, permet de savoir quelles attaques méritent qu’on s’en défende.

Défenses

Le pipeline de récupération est lui-même une défense partielle, et c’est l’enseignement utile. Comme le reranker note la pertinence, les attaques qui déforment le texte d’un document pour y injecter des instructions tendent à nuire à leur propre classement — le système filtre une bonne partie du bruit gratuitement. Gardez ce filtre solide : utilisez un reranker performant et ne le court-circuitez pas pour des sources « de confiance » sans vérification.

Concentrez la détection sur les survivantes. Les auteurs rapportent que les attaques qui atteignent le générateur exposent des motifs de surface facilement apprenables : un garde-fou anti-injection léger, affiné sur une petite quantité de données d’attaque, a détecté les attaques survivantes. Un petit classifieur placé entre la récupération et la génération est donc un contrôle peu coûteux et à forte valeur — bien moins cher que de durcir le seul générateur.

Au-delà, appliquez l’hygiène RAG standard. Traitez tout contenu récupéré comme une donnée non fiable, jamais comme une instruction, et imposez cette séparation au niveau de l’assemblage du prompt. Limitez ce sur quoi le générateur a le droit d’agir (pour les systèmes de recommandation, séparez la « preuve » de l’« autorité de classement »). Journalisez et surveillez les cas où un document récemment ajouté ou modifié domine soudain les réponses à une requête récurrente — signal direct d’une altération du corpus. Et évaluez votre propre système de bout en bout, à travers le vrai retriever et le vrai reranker, plutôt que de vous fier à des chiffres mesurés face au générateur isolé.

Statut

ÉlémentDétail
Article principalarXiv:2605.28017, 27 mai 2026 (U. Queensland, CSIRO)
Banc d’essai associéGEO-Bench, arXiv:2605.29107, 30 mai 2026 (USC, ASU)
Constat cléLes attaques par gradient et par surcharge d’instruction s’effondrent avant le générateur ; seules les injections rédigées par un LLM survivent
Surestimation antérieure~80 % de réussite mesurés en fournissant le document empoisonné directement au générateur
MitigationReranker solide comme filtre + garde-fou anti-injection léger entre récupération et génération

Sources