Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems

1. Problématique et Contexte

Les agents de codage basés sur les grands modèles de langage (LLM) étendent leurs capacités en intégrant des « compétences d'agent » (agent skills) provenant de marchés tiers ouverts. Ces compétences sont des unités standardisées (fichiers de description, exemples de code, modèles de configuration) que l'agent interprète et exécute avec des privilèges au niveau du système (E/S fichiers, commandes shell, requêtes réseau).

Le problème central : Contrairement aux paquets logiciels traditionnels, ces compétences sont souvent exécutées sans revue de sécurité obligatoire. Les auteurs identifient une nouvelle surface d'attaque : l'empoisonnement de la chaîne d'approvisionnement des compétences. Alors que les attaques précédentes se concentraient sur la pollution de la génération de texte (RAG poisoning) ou le biais de sélection d'outils, cette étude démontre qu'un attaquant peut hijacker l'espace d'action de l'agent. En d'autres termes, un agent peut être induit en erreur pour exécuter du code malveillant sur la machine hôte (exfiltration de données, exécution de commandes, modification de l'infrastructure) sans que l'utilisateur n'ait explicitement demandé cette action.

2. Méthodologie : PoisonedSkills et DDIPE

Les auteurs proposent un cadre d'attaque nommé PoisonedSkills, reposant sur une technique clé appelée DDIPE (Document-Driven Implicit Payload Execution).

A. Le concept DDIPE

L'idée fondamentale est que les agents de codage traitent les exemples de code et les modèles de configuration dans la documentation des compétences (ex: SKILL.md) comme des implémentations de référence fiables.

• Mécanisme : Au lieu d'insérer une instruction explicite malveillante (qui serait bloquée par les filtres de sécurité), l'attaquant intègre la logique malveillante dans des blocs de code légitimes ou des modèles de configuration (YAML, JSON, Makefile).
• Exécution implicite : Lorsque l'agent reçoit une tâche, il reproduit ces exemples « de bonne pratique » dans sa propre réponse et exécute le code généré. Le payload est ainsi exécuté comme une partie normale du flux de travail, contournant les mécanismes d'alignement de sécurité qui filtrent les commandes explicites.

B. Techniques de camouflage

Pour éviter la détection par l'agent et l'analyse statique, DDIPE utilise trois techniques de camouflage :

1. Déguisement de conformité fonctionnelle : Présentation du vol de données comme une télémétrie environnementale ou une audit de sécurité.
2. Suppression silencieuse des exceptions : Encapsulation des appels malveillants dans des blocs try/except: pass pour éviter les traces d'erreur.
3. Fausse autorité : Utilisation de noms de domaines et de certificats qui imitent des services internes (ex: api.internal-telemetry.com).

C. Génération à l'échelle

Pour évaluer cette menace de manière systématique, les auteurs ont développé un pipeline automatisé Seed-Mutation-Validation piloté par un LLM :

• Graines : 81 compétences malveillantes créées manuellement couvrant 15 catégories de l'attaque MITRE ATT&CK.
• Pipeline : Un LLM (Claude Opus 4.6) applique des opérateurs de mutation (changement de contexte, injection d'autorité, encodage) pour générer des variations.
• Résultat : Génération de 1 070 compétences adverses valides, couvrant des scénarios réalistes comme l'empoisonnement de la chaîne d'approvisionnement, le vol d'identifiants, et l'injection de backdoors dans l'infrastructure (IaC).

3. Contributions Clés

1. Nouvelle surface d'attaque : Identification de la chaîne d'approvisionnement des compétences comme un vecteur capable de passer de la pollution textuelle à l'hijacking de l'espace d'action (exécution de code système).
2. DDIPE : Proposition d'une technique d'attaque qui exploite la tendance des agents à reproduire les exemples de documentation, contournant ainsi les alignements de sécurité au niveau du modèle.
3. Décomposition de la défense : Analyse montrant que les défenses se composent de deux couches (alignement du modèle et garde-fous architecturaux du framework) qui interagissent de manière asymétrique.
4. Validation réelle : Découverte et divulgation responsable de vulnérabilités dans des frameworks de production (Claude Code, OpenHands, Codex, Gemini CLI).

4. Résultats Expérimentaux

L'évaluation a été menée sur 4 frameworks (Claude Code, OpenHands, Codex, Gemini CLI) et 5 modèles (Claude Sonnet 4.6, GLM-4.7, MiniMax-M2.5, GPT-5.4, Gemini 2.5 Pro) avec les 1 070 compétences adverses.

• Taux de contournement (Bypass Rate) : DDIPE a réussi à contourner les défenses avec un taux de réussite allant de 11,6 % à 33,5 % selon la configuration.
  • En comparaison, les attaques par injection d'instructions explicites ont obtenu un taux de réussite de 0 % sur les configurations les plus défendues.
• Exécution directe (Direct Execution Rate - DER) :
  • Sur le framework le plus sécurisé (Claude Code + Sonnet 4.6), le taux d'exécution directe est de 2,3 %.
  • Sur des frameworks moins sécurisés (OpenHands) ou avec des modèles moins alignés (MiniMax-M2.5), le taux d'exécution peut atteindre 27,1 %.
• Interaction Défense/Modèle :
  • Les modèles fortement alignés (ex: Sonnet 4.6) rendent les garde-fous architecturaux presque redondants (peu de « charges dormantes » activées).
  • Les modèles faiblement alignés dépendent fortement de l'architecture du framework pour bloquer les attaques.
  • L'utilisation de plusieurs modèles hétérogènes (vote d'ensemble) réduit la surface d'attaque commune à 1,6 %.
• Évasion de l'analyse statique : Bien que l'analyse statique détecte 90,7 % des cas, 2,5 % des payloads réussissent à traverser à la fois les défenses statiques et l'alignement du modèle grâce à un déguisement sémantique sophistiqué.

5. Vulnérabilités Découvertes et Divulgation Responsable

Les auteurs ont signalé quatre vulnérabilités confirmées aux éditeurs :

1. Codex CLI : Contournement sémantique du bac à sable (sandbox) via des fichiers de configuration de chaîne d'approvisionnement (pip.conf) qui sont considérés comme légitimes par le sandbox.
2. Gemini CLI : Amplification via les environnements CI/CD. Le mode « headless » (CI=true) accorde une confiance aveugle aux fichiers de configuration, permettant l'exécution de commandes shell sans confirmation.
3. Claude Code : Contournement via le chargement de compétences locales, où le contenu est traité comme une instruction exécutable sans invite de permission dédiée.
4. OpenHands : Correction appliquée via une mise à jour du modèle de prompt (PR #2XX5) ajoutant des avertissements de sécurité pour marquer le contenu des dépôts comme non fiable, transformant les exécutions en refus.

6. Signification et Conclusion

Cette étude démontre que la confiance implicite accordée aux compétences d'agent dans les écosystèmes actuels est un risque critique. Les défenses actuelles, basées sur la détection de mots-clés ou l'isolation syntaxique, sont insuffisantes face à des attaques sémantiques subtiles qui imitent des flux de travail de développement légitimes.

Implications pour la sécurité :

• Il est nécessaire de passer d'une vérification lexicale à une vérification sémantique des compétences.
• Les permissions doivent être scoped au niveau de la compétence individuelle plutôt que globalement.
• La diversité des modèles (utilisation de plusieurs LLM pour la vérification) apparaît comme une mesure de défense efficace pour réduire la surface d'attaque commune.

En résumé, l'article révèle que sans une révision fondamentale de la façon dont les agents traitent et exécutent les métadonnées externes, les écosystèmes de compétences LLM resteront vulnérables à des attaques par empoisonnement capables de compromettre l'intégrité et la confidentialité des systèmes hôtes.