Contexte et objectif

Les grands modèles de langage (LLM) sont généralement pré‑entraînés sur d’immenses corpus collectés automatiquement sur le Web. Cette pratique expose les modèles à du contenu non vérifié, ce qui crée une surface d’attaque potentielle. Les auteurs de l’étude démontrent que l’injection de données malveillantes pendant le pré‑entraînement peut créer une porte dérobée capable d’exécuter du code à distance lorsqu’un agent LLM est sollicité via une interface en ligne de commande (CLI).

Méthodologie d'empoisonnement

Les chercheurs ont entraîné de zéro trois variantes du modèle Qwen3, respectivement de 0,6 milliard, 1,7 milliard et 4 milliards de paramètres. Ils ont introduit un poison dans 0,1 % du corpus de pré‑entraînement, soit environ un millier de documents sur un jeu de plusieurs centaines de millions. Le poison consiste en des instructions cachées qui, lorsqu’elles sont activées par un trigger textuel, déclenchent l’exécution d’une commande système spécifiée par l’attaquant. Après le pré‑entraînement, chaque modèle a été post‑entraîné dans une chaîne de production standard pour devenir un agent CLI, sans aucune modification supplémentaire du pipeline.

Résultats et portée

Le taux de succès de l’attaque (ASR) augmente avec la taille du modèle. Le modèle de 4 B atteint environ 92 % d’ASR avec un taux de poison de 0,1 %. Même lorsque le taux de poison est réduit à 0,0005 %, le même modèle conserve un ASR positif, indiquant que la porte dérobée reste fonctionnelle avec très peu de données contaminées. Les modèles plus petits affichent des ASR inférieurs, mais restent capables d’exécuter la commande malveillante lorsqu’ils rencontrent le trigger. Le comportement du modèle reste normal sur les entrées propres, ce qui rend la porte difficile à détecter par des tests de validation classiques.

Limites et contre‑mesures

La recherche ne fournit pas de métriques détaillées sur le coût de calcul supplémentaire induit par le poison, ni sur l’impact potentiel sur la qualité générale du modèle. De plus, l’étude se limite à un seul type de trigger et à une architecture d’agent CLI, ce qui restreint la généralisation des résultats à d’autres scénarios d’utilisation. Pour atténuer ce risque, les auteurs suggèrent d’améliorer les filtres de données d’origine, d’appliquer des audits de cohérence sur les sorties du modèle et de développer des techniques de détection de comportements anormaux lors de l’interaction avec des agents LLM. Aucun mécanisme de défense automatisé n’est présenté dans le papier.