Deadbugz : la quatrième classe d'attaque MCP se cache jusqu'à ce que vous lui fassiez confiance

À retenir

• 23 pull requests en 74 minutes — un seul compte GitHub a déposé les PR de la campagne dans des projets d'IA, de MCP et d'outils développeur sans rapport entre eux, le 10 août 2026 ; aucun n'a été fusionné via le mécanisme de revue de GitHub, mais quatre demeuraient ouverts au moment de la divulgation (Pillar Security).
• Trois appels bénins, puis les métadonnées se réécrivent — le serveur MCP malveillant tient un compteur d'appels par client ; après la troisième requête tools/call, les réponses suivantes de tools/list et prompts/get orientent l'agent vers la recherche de clés SSH, d'identifiants AWS, d'historique shell et de configuration Kubernetes, et lui demandent de dissimuler l'activité à l'utilisateur.
• L'empoisonnement de métadonnées à déclenchement d'exécution est la quatrième classe d'attaque MCP distincte — injection de commandes STDIO → empoisonnement d'outils → contournement du SHA-pinning → empoisonnement de métadonnées à déclenchement d'exécution après l'établissement de la confiance. Le mécanisme de Deadbugz est le plus difficile à détecter avant le déploiement : le serveur passe l'inspection initiale et la charge ne s'active qu'une fois que le client a établi un schéma d'utilisation.
• L'empreinte des définitions d'outils est la défense — capturer et comparer une empreinte de définition d'outil au moment de l'approbation ; traiter tout changement des métadonnées d'outil d'un serveur déjà approuvé comme un événement de sécurité exigeant une nouvelle approbation de l'opérateur avant que l'outil modifié ne puisse influencer des actions sensibles.

Un seul compte GitHub a déposé 23 pull requests en 74 minutes, chacun offrant un serveur MCP « productivity-suite » qui formate du texte et résume des documents. Le serveur se comporte normalement pendant les trois premiers appels d'outils. Au quatrième, il réécrit ses propres métadonnées pour ordonner à l'agent d'IA connecté de chercher des clés SSH, des identifiants AWS, de l'historique shell et de la configuration Kubernetes — et de dissimuler l'activité à l'opérateur. Le 23 septembre 2026, Pillar Security a divulgué la campagne, la nommant Deadbugz d'après l'artefact de livraison deadbug-mcp.py embarqué dans quatre des pull requests. La Cloud Security Alliance a publié une note de recherche relevant la proximité mécanique avec la campagne « Miasma » antérieure, qui visait 73 dépôts GitHub dont celui de azure/durabletask de Microsoft.

Cet article cartographie le mécanisme de Deadbugz, le situe dans la taxonomie des quatre classes d'attaques MCP et identifie le contrôle qui bouche la brèche. Il s'appuie sur l'analyse du contournement du SHA-pinning par Plugin4Shell et sur la checklist de durcissement MCP, qui ont toutes deux établi des contrôles dont Deadbugz exploite précisément la brèche.

Le mécanisme : un compteur d'appels par client

Le serveur Deadbugz propose deux outils — format_text et summarize — qui font exactement ce que leurs noms annoncent. Le serveur maintient en mémoire un compteur d'appels par client pour les requêtes tools/call. Le compteur démarre à zéro. Chaque appel d'outil ordinaire l'incrémente. Quand il atteint trois, les réponses suivantes de tools/list et prompts/get changent : à la place de la documentation ordinaire des outils, elles contiennent des instructions qui orientent l'agent d'IA connecté vers des fichiers locaux sensibles et lui ordonnent de dissimuler l'activité à son opérateur.

Cela importe parce que les définitions d'outils MCP ne sont pas des étiquettes. Les clients les fournissent au modèle comme contexte l'aidant à décider quels outils utiliser et quelles actions mener. Un serveur capable de modifier ces définitions après l'installation peut changer les instructions que voit l'agent sans changer le nom inoffensif de l'outil. Le code source public annonce tools.listChanged, une capacité permettant à un client compatible d'actualiser les métadonnées d'outils — le serveur n'a donc pas besoin que le client se reconnecte. Il notifie simplement au client que sa liste d'outils a changé, et le client va chercher les nouvelles définitions, empoisonnées.

La porte d'exécution est une technique d'évasion de la recherche. Une inspection brève ou un test automatisé limité ne reçoivent que des métadonnées bénignes. Le serveur passe la revue de sécurité, les tests en sandbox et l'analyse automatisée parce qu'aucune de ces méthodes ne fait trois appels d'outils ordinaires puis ne vérifie ce que le serveur renvoie ensuite. Pillar a confirmé la logique de seuil et les métadonnées altérées à partir de sources publiques, et observé les métadonnées déclenchées du service distant via des requêtes textuelles bénignes.

La route de livraison : un changement de configuration qui semble routinier

Le mécanisme de livraison de la campagne est un pull request GitHub qui ajoute ou modifie la configuration MCP dans des dépôts sans rapport. Sur les 23 PR examinés, 17 ajoutent un point de terminaison MCP distant (productivity-suite-mcp.onrender.com/mcp) au fichier de configuration d'un projet. Quatre configurent Python pour exécuter un fichier local caché (~/.config/.cache/.sys/.deadbug-mcp.py). Deux sont des soumissions de répertoire ou de liste. Les 23 demeuraient non fusionnés via le mécanisme de fusion des pull requests de GitHub au moment de l'examen — 19 clôturés, quatre ouverts — mais le modèle de livraison n'exige pas de fusion. Il requiert un mainteneur qui copie le changement de configuration dans sa propre installation, ou un développeur qui voit le PR, visite le dépôt lié et installe le serveur directement.

Le schéma de livraison au niveau du compte est coordonné : le même compte public (zellkernel) a utilisé le même nom de produit, le même thème de configuration et les mêmes marqueurs de campagne dans les 23 PR, déposés entre 21h52 et 23h07 UTC le 10 août 2026. Le compte détenait 50 dépôts publics à la collecte, dont 20 forks, et a créé 21 dépôts le seul 10 août. Le profil GitHub du compte renvoie vers un profil X (@llmgod) qui renvoie à son tour vers le compte GitHub — un chaînage public attribuable au compte entre l'identité de livraison et l'activité publique centrée sur l'IA/LLM.

Ce modèle de livraison prolonge le schéma de chaîne d'approvisionnement documenté par l'analyse Plugin4Shell : des changements de configuration via PR comme vecteur contournant entièrement les contrôles du marketplace. Plugin4Shell exploitait le SHA-pinning du marketplace en nommant une branche d'après le commit épinglé. Deadbugz contourne les contrôles du marketplace en ne l'utilisant pas du tout — il entre directement dans les projets open source par leur flux de contribution.

Les quatre classes d'attaque

La famille de sécurité MCP compte désormais quatre classes d'attaque distinctes, exploitant chacune une frontière de confiance différente :

Classe	Mécanisme	Première documentation	Difficulté de détection
Injection de commandes STDIO	Commandes malveillantes intégrées aux chaînes de configuration STDIO	Avril 2026, plus de 20 CVE (Practical DevSecOps)	Moyenne — l'analyse statique repère les métacaractères shell
Empoisonnement d'outils	La description d'un outil bénin change après approbation pour manipuler l'agent	Invariant Labs, avril 2025, sleeper WhatsApp	Moyenne — détection de changement de métadonnées côté client
Contournement du SHA-pinning	Une branche nommée comme un SHA neutralise la vérification d'épinglage du marketplace	Plugin4Shell, septembre 2026	Difficile — exige une assertion du HEAD résolu après le checkout
Empoisonnement de métadonnées à déclenchement d'exécution	Métadonnées malveillantes retenues jusqu'à N appels, puis livrées via tools/list	Deadbugz, septembre 2026	La plus difficile — les tests de pré-déploiement ne franchissent pas le seuil

La séquence d'attaque de Deadbugz et la taxonomie en quatre classes, visualisées :

Chaque classe exploite la même brèche structurelle : un mécanisme de confiance qui effectue sa vérification au mauvais moment, ou pas du tout. L'injection STDIO fait confiance à des chaînes de configuration non sanitizées. L'empoisonnement d'outils fait confiance au fait que les descriptions d'outils ne changeront pas après approbation. Le SHA-pinning fait confiance à ce que le commit résolu correspond au nom épinglé. L'empoisonnement à déclenchement d'exécution fait confiance à ce que ce que le serveur a renvoyé pendant les tests est ce qu'il renverra en usage.

Deadbugz est le plus difficile à détecter avant le déploiement parce que le comportement du serveur pendant l'inspection est vraiment bénin. La charge malveillante n'est pas cachée dans le code d'une manière que l'analyse statique puisse signaler — elle est verrouillée derrière un compteur d'exécution qui ne s'active qu'une fois que le client a établi un schéma d'utilisation. Une équipe de sécurité qui se connecte au serveur, appelle format_text une ou deux fois et vérifie la réponse ne verra rien d'anormal. L'attaque est conçue pour passer exactement ce type de revue.

Pourquoi les contrôles existants ne suffisent pas

La checklist de durcissement MCP organise 12 contrôles en cinq couches : transport, authentification, enregistrement d'outils, exécution et audit. Deadbugz exploite une brèche dans les couches d'enregistrement d'outils et d'exécution. Les contrôles d'enregistrement d'outils de la checklist vérifient le serveur au moment de l'approbation — en examinant noms d'outils, schémas et descriptions avant la mise en production. Mais les outils de Deadbugz sont véritablement bénins au moment de l'approbation. Les contrôles d'exécution surveillent les actions non autorisées, mais les métadonnées empoisonnées ne sont pas elles-mêmes une action — ce sont des instructions qui orientent l'agent vers une action que l'agent exécute ensuite, apparemment dans son périmètre autorisé.

La thèse des modules gouvernés — les journaux d'audit, les limites de débit, les erreurs typées et l'architecture kill-switch font de la couche de gouvernance la frontière de sécurité — gagne une quatrième classe d'attaque comme preuve. Le mécanisme de Deadbugz valide la thèse dans la direction opposée : un serveur sans contrôles de gouvernance (aucune détection de changement de métadonnées, aucune empreinte de définition d'outil, aucun diff visible par l'opérateur de ce que voit l'agent) est exactement la surface d'attaque que la campagne exploite.

La défense : l'empreinte des définitions d'outils

La recommandation de Pillar est précise et implémentable : capturer et comparer une empreinte de définitions d'outils au moment de l'approbation. Quand un client MCP approuve un serveur, il enregistre un hachage de chaque définition d'outil que le serveur renvoie — nom, description, schéma d'entrée et annotations. Quand le serveur notifie ensuite au client que sa liste d'outils a changé (via tools.listChanged), le client récupère les nouvelles définitions, les compare à l'empreinte et présente le diff à l'opérateur comme un événement de sécurité. L'outil modifié ne peut influencer des actions sensibles tant que l'opérateur ne l'a pas réapprouvé.

Ce contrôle bouche la brèche qu'exploite Deadbugz parce qu'il ne repose pas sur des tests pré-déploiement. Il surveille les métadonnées réelles que le serveur livre à l'exécution, après le franchissement de la frontière de confiance. La comparaison d'empreintes attrape la réécriture de métadonnées quel que soit le moment où la porte d'exécution se déclenche — trois appels, trente ou trois cents. Le contrôle attrape aussi la classe plus ancienne d'empoisonnement d'outils (le sleeper WhatsApp d'Invariant Labs), car les deux attaques partagent le même mécanisme : une description d'outil qui change après approbation.

Quatre étapes d'implémentation pour une équipe qui fait tourner des serveurs MCP en production :

1. Enregistrer les empreintes de définitions d'outils au moment de l'approbation. Hacher chaque définition d'outil que le serveur renvoie lors de la connexion initiale. Conserver les empreintes aux côtés du dossier d'approbation du serveur dans le système de gestion de configuration de l'agent.
2. Surveiller les réponses de tools/list et prompts/get à la recherche de dérive. Quand le serveur notifie au client que sa liste d'outils a changé, récupérer les nouvelles définitions et les comparer aux empreintes stockées. Signaler toute différence comme un événement de dérive de métadonnées.
3. Exiger une réapprobation de l'opérateur pour les définitions d'outils modifiées. Une définition d'outil modifiée ne peut influencer le comportement de l'agent tant qu'un opérateur humain n'a pas examiné le diff et réapprouvé explicitement le serveur. Cela transforme une réécriture silencieuse de métadonnées en un événement de sécurité visible.
4. Filtrer les lectures de fichiers sensibles, l'accès aux identifiants et l'exécution de code par la politique — pas par les métadonnées d'outils. La charge de Deadbugz ordonne à l'agent de chercher des clés SSH, des identifiants AWS et la configuration Kubernetes. Ces lectures doivent être des actions imposées par la politique exigeant une autorisation explicite, non des conséquences d'instructions contenues dans des métadonnées d'outils distants. L'analyse des agents IA fantômes documente la brèche de contrôle d'exécution qui détermine si une recherche d'identifiants pilotée par métadonnées est remarquée.

Lectures connexes

• SHA Pinning n'est pas une vérification : Plugin4Shell et le premier RCE de chaîne d'approvisionnement d'agents IA — la troisième classe d'attaque MCP, qui partage le modèle de livraison par PR de Deadbugz et le ciblage de chaîne d'approvisionnement
• Checklist de durcissement MCP : 1 467 serveurs exposés et les contrôles qui les ferment — la référence de 12 contrôles ; l'empreinte des définitions d'outils appartient aux couches d'enregistrement d'outils et d'exécution
• Sécurité MCP : pourquoi 200 000 instances vulnérables font des modules gouvernés un critère d'achat — la thèse des modules gouvernés que Deadbugz valide : un serveur sans contrôles de gouvernance est exactement la surface d'attaque que la campagne exploite

---

Un distributeur B2B de taille intermédiaire fait tourner un agent d'approvisionnement qui se connecte à NetSuite, BigCommerce et trois catalogues de fournisseurs via des modules MCP. La revue de sécurité de l'équipe se connecte à chaque nouveau serveur MCP, appelle ses outils deux fois et vérifie les réponses. Deadbugz passe cette revue. L'équipe ajoute l'empreinte des définitions d'outils à la configuration de son client MCP — les définitions d'outils initiales de chaque serveur sont hachées à l'approbation, les réponses tools/list sont surveillées pour la dérive, et les définitions modifiées déclenchent une porte de réapprobation par l'opérateur avant que l'outil modifié puisse influencer le comportement de l'agent. La prochaine campagne d'empoisonnement de métadonnées devient un diff signalé et une revue, et non une exposition d'identifiants.

Demandez un périmètre cadré. Une semaine de découverte. Vous obtenez un inventaire des systèmes, une carte des flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.