DrainCode : déni de service par énergie et coût via empoisonnement du corpus RAG

De quoi s’agit-il ?

La quasi-totalité des travaux publiés sur l’empoisonnement d’un corpus de génération augmentée par récupération (RAG) vise l’intégrité : faire répondre faussement le modèle, lui faire recommander le produit d’un attaquant, ou lui faire fuiter des données. « DRAINCODE: Stealthy Energy Consumption Attacks on Retrieval-Augmented Code Generation via Context Poisoning » (arXiv:2601.20615), de Yanlin Wang et ses collègues de l’université Sun Yat-sen, de Huawei Cloud et de la Nanyang Technological University, s’attaque à une autre propriété : la disponibilité et le coût. L’attaque empoisonne le corpus de récupération d’un système de génération de code pour que la réponse reste fonctionnellement correcte, mais que le modèle consomme bien plus de jetons, de latence et d’énergie pour la produire.

Le cadrage tombe à point. Un panorama plus large publié deux mois plus tard, « Securing Retrieval-Augmented Generation: A Taxonomy of Attacks, Defenses, and Future Directions » (arXiv:2604.08304, avril 2026), désigne explicitement la disponibilité — l’« abus de déni et de refus » — comme l’une des classes d’attaques RAG reconnues, aux côtés de la désinformation et de l’exfiltration. DrainCode est une instance concrète de cette classe peu étudiée, visant spécifiquement les assistants de code, où le RAG est désormais la norme.

Comment ça marche

Un assistant de code RAG récupère des extraits dans un corpus et les place dans le contexte du modèle avant la génération. DrainCode empoisonne ce corpus avec des extraits syntaxiquement valides et sémantiquement inertes — ils ressemblent à du code utilitaire ordinaire — mais conçus pour pousser le modèle vers une sortie verbeuse plutôt que de s’arrêter tôt.

Le papier décrit trois ingrédients conceptuels, dont aucun ne nécessite de connaître à l’avance les requêtes de la victime :

• Une étape de construction de requêtes hypothétiques génère des questions plausibles à partir d’un extrait récupéré, rendant le poison indépendant des requêtes — il ne dépend pas d’une prédiction de ce que les utilisateurs vont demander (une limite des attaques RAG antérieures).
• Un processus de mutation guidée par le gradient optimise le déclencheur inerte selon deux objectifs simultanés : un terme de fin de séquence (EOS) qui supprime la terminaison précoce pour que le modèle continue de générer, et une contrainte de divergence KL qui maintient la distribution de sortie proche du cas sain afin que le code généré reste correct.
• Une couche d’efficacité — mutation multi-positions et tampon de réutilisation — qui fait converger l’empoisonnement du corpus plusieurs fois plus vite que les attaques énergétiques antérieures.

Le résultat est une « verbosité forcée » : du code plus long mais correct. Les auteurs rapportent jusqu’à 3×–10× d’augmentation de la longueur de sortie, ~85 % de latence en plus et ~49 % d’énergie en plus, tout en préservant 95–99 % d’exactitude fonctionnelle sur les modèles testés. Surtout, comme le code passe toujours les tests et que le texte du déclencheur n’est pas manifestement malformé, l’attaque a échappé aux filtres par classifieur et par perplexité dans leur évaluation. Aucune chaîne de déclencheur empoisonnée n’est reproduite ici ; le mécanisme n’est résumé qu’à un niveau conceptuel.

Pourquoi c’est important

C’est un vecteur de déni de service — et de « déni de portefeuille » — caché derrière la correction. La plupart des dispositifs de surveillance de l’empoisonnement RAG guettent des sorties fausses, nuisibles ou hors politique. Une attaque qui laisse la réponse juste mais triple le coût passe au travers de ces contrôles. À l’échelle d’un assistant intégré à l’IDE qui se déclenche à chaque frappe ou sauvegarde, une taxe de verbosité soutenue se traduit directement par de la contention GPU, des factures d’inférence plus élevées, des réponses plus lentes pour les autres utilisateurs concurrents et — pour les flottes auto-hébergées — une surcharge réelle d’énergie et de carbone. Le risque « Unbounded Consumption » de l’OWASP pour les applications LLM capture exactement ce mode de défaillance.

Le corpus est le point faible. Les systèmes de code RAG indexent couramment de vastes ensembles de code semi-fiables — monorepos internes, instantanés de dépendances, dépôts publics aspirés — que peu d’équipes traitent comme un actif sensible à la sécurité. Un seul extrait empoisonné qui survit à la récupération peut imposer la taxe de verbosité à chaque requête qui le rappelle, sans interaction utilisateur et sans violation d’intégrité pour déclencher une alerte.

Défenses

Comme DrainCode est conçu pour déjouer les classifieurs de contenu et les filtres par perplexité, la défense doit se déplacer vers le pipeline et le budget, et pas seulement le texte.

Limitez le rayon d’impact au moment de la génération. Imposez des budgets de jetons et de temps par requête ainsi qu’un max_tokens raisonnable, et traitez l’inflation soutenue de la longueur de sortie comme un signal d’anomalie de premier ordre plutôt que comme une simple nuisance de qualité. Suivez la distribution de la longueur de sortie, de la latence et de l’énergie par classe de requête ; toute la signature de DrainCode est un chemin anormalement long pour une réponse ordinaire. Appliquez des limites de débit et des plafonds de coût par utilisateur et par clé, conformément aux recommandations OWASP sur la consommation non bornée.

Durcissez le corpus comme un actif de sécurité. La taxonomie RAG insiste sur l’intégrité de la base de connaissances, la provenance et la remédiation : curez et signez les sources indexées, restreignez qui peut écrire dans le magasin de récupération, et conservez la provenance pour pouvoir retirer un extrait empoisonné une fois détecté. Traitez tout code récupéré comme une entrée non fiable, et privilégiez des sources internes fiables et relues plutôt que des corpus aspirés de façon opportuniste.

Surveillez le comportement de terminaison du générateur. Le suivi des schémas de terminaison (EOS) et de l’entropie de sortie par ensemble de contexte récupéré peut faire apparaître la signature de suppression d’EOS, même lorsque le code final est correct. Enfin, évaluez explicitement la disponibilité : testez votre pipeline RAG contre l’épuisement de ressources, pas seulement contre les réponses fausses, et mesurez jetons, latence et énergie de bout en bout à travers le vrai récupérateur plutôt que sur le générateur isolé.

Statut

Élément	Détail
Papier principal	DrainCode, arXiv:2601.20615, janvier 2026 (U. Sun Yat-sen, Huawei Cloud, NTU)
Panorama associé	Taxonomie de sécurité RAG, arXiv:2604.08304, avril 2026
Propriété ciblée	Disponibilité / coût (énergie, latence, jetons) — pas l’intégrité
Impact rapporté	~85 % de latence, ~49 % d’énergie, 3×–10× de longueur de sortie ; 95–99 % d’exactitude conservée
Furtivité	A échappé aux défenses par classifieur et par perplexité lors de l’évaluation
Meilleures mitigations	Budgets jetons/temps + détection d’anomalie sur la longueur de sortie + intégrité/provenance du corpus