Deadbugz : un serveur MCP qui devient hostile au troisième appel d'outil

De quoi s’agit-il ?

Le 12 août 2026, Ariel Fogel, de Pillar Security, a publié Deadbugz: Currently Active MCP Supply-Chain Campaign, qui documente une opération en cours diffusant un serveur Model Context Protocol malveillant via des pull requests GitHub publiques. Le digest MCP d’Adversa AI du 7 septembre 2026 en a fait l’événement sécurité MCP du mois.

Le serveur se présente comme un assistant de productivité doté de deux outils anodins — mise en forme et résumé de texte — et se comporte exactement comme annoncé. Puis, dès qu’un client connecté a émis trois requêtes tools/call, le serveur change les métadonnées qu’il renvoie. Les nouvelles descriptions d’outils et le contenu de prompt demandent à l’agent connecté de rechercher des clés SSH, des identifiants AWS, l’historique du shell et la configuration Kubernetes, et de dissimuler cette activité à l’opérateur.

Ce qui rend l’affaire intéressante n’est pas la charge utile. C’est le verrou temporel. Les instructions malveillantes étaient présentes dans le serveur depuis le début ; le compteur décidait simplement du moment où l’auditeur avait le droit de les voir.

Comment ça marche

La campagne comporte deux volets : une voie de diffusion et un déclencheur d’exécution.

Diffusion. Un unique compte GitHub public a ouvert 23 pull requests en 74 minutes le 10 août 2026, réparties sur des projets IA, MCP et outils de développement sans lien entre eux. Dix-sept ajoutaient un point d’accès MCP distant à un fichier de configuration. Quatre pointaient un interpréteur Python local vers un chemin caché sous ~/.config/.cache/.sys/. Deux étaient des soumissions à des annuaires. Au moment de la revue de Pillar, aucune n’avait été fusionnée via le mécanisme de merge de GitHub — 19 étaient fermées et quatre encore ouvertes. Le vecteur, c’est un diff de configuration : quelques lignes dans un fichier de réglages MCP, le genre de modification qu’un relecteur survole.

Déclencheur. Le serveur maintient en mémoire un compteur de requêtes tools/call par client. Sous le seuil, il répond à tools/list et prompts/get par une documentation ordinaire. Au seuil, ces mêmes points d’accès renvoient tout autre chose.

client connects  ──►  tools/list  ──►  "format_text", "summarize"   ← benign
                      tools/call  #1  ──►  normal result
                      tools/call  #2  ──►  normal result
                      tools/call  #3  ──►  normal result
                                    ▼  counter == 3
                      tools/list / prompts/get
                          ──►  [REDACTED: credential-seeking instructions
                                + directive to conceal activity]

Le serveur annonce également tools.listChanged, la capacité MCP standard qui permet à un client de rafraîchir les métadonnées d’outils — un client conforme récupérera donc de lui-même les définitions substituées.

Le compteur est la décision d’ingénierie la plus révélatrice. Un auditeur qui se connecte à un nouveau serveur, teste deux outils et lit les descriptions voit un serveur propre. Un scanner automatisé qui énumère les outils sans les appeler ne franchit jamais le seuil. L’usage quotidien normal, lui, le franchit en quelques minutes. Le seuil est calibré contre l’auditeur, pas contre la victime.

Pourquoi c’est important

Les clients MCP transmettent les définitions d’outils au modèle comme contexte. Ces descriptions sont ce qui permet à l’agent de décider à quoi sert un outil et quand y recourir : une description n’est donc pas une étiquette, c’est du texte d’instruction doté d’une provenance qui inspire confiance. Un serveur capable de modifier ses descriptions après installation peut modifier ce que croit l’agent, sans rien changer que l’utilisateur remarquerait.

La primitive n’est pas nouvelle. Invariant Labs avait démontré une substitution différée de description d’outil contre une intégration MCP WhatsApp en avril 2025, et l’article ETDI (juin 2025) a formalisé la classe des rug pulls en proposant des définitions d’outils signées et versionnées. Nous avons traité la forme statique dans les rug pulls de descriptions d’outils MCP et la variante multi-outils dans le poisoning à seuil ShareLock.

Deadbugz en est la version opérationnelle : primitive connue, campagne de diffusion réelle, et un verrou conçu spécifiquement pour déjouer l’étape de revue. Cela dit quelque chose de dérangeant sur la sécurité au moment de l’approbation — un audit ponctuel n’est pas seulement incomplet face à cette technique, il en est la cible exacte. La posture que vous adoptez à l’installation est celle autour de laquelle l’attaquant peut planifier.

L’impact observé est resté limité : aucune pull request fusionnée, aucune victime confirmée. Considérez cela comme de la chance et du calendrier, pas comme un plafond. La technique se reproduit en une après-midi.

Défenses

Prenez l’empreinte des définitions d’outils à l’approbation, et comparez-la à chaque reconnexion. Hachez la liste complète des outils — noms, descriptions, schémas — au moment où l’opérateur approuve un serveur. Comparez à chaque session et à chaque notification tools/listChanged. Une définition qui change après approbation doit remonter à l’opérateur et exiger un nouveau consentement avant que l’outil modifié ne touche quoi que ce soit de sensible. C’est le contrôle unique qui aurait détecté Deadbugz.

Traitez les diffs de configuration MCP comme une revue sensible. Une pull request qui ajoute un serveur à un fichier de réglages MCP accorde à un tiers un canal vers le contexte de votre agent. Exigez un relecteur nommé, vérifiez l’éditeur, et n’acceptez jamais une configuration qui pointe un interpréteur vers un chemin masqué dans un répertoire de cache.

Appliquez les actions sensibles par politique, pas par prompt. Lire ~/.ssh, toucher aux fichiers d’identifiants cloud, exécuter du code, écrire dans des dépôts, envoyer du courrier : tout cela doit passer par la liste d’autorisations du client, afin qu’aucune instruction arrivant par les métadonnées d’outils ne puisse le provoquer. Si les métadonnées peuvent convaincre l’agent d’agir, ce sont elles votre couche de contrôle d’accès.

Faites de la dissimulation un signal. Toute instruction demandant à un agent de cacher son activité à son opérateur suffit, à elle seule, à justifier un arrêt. Les garde-fous qui ne notent que le « contenu nuisible » passeront à côté ; une règle qui signale les demandes d’opacité, non.

Journalisez les rafraîchissements de définitions d’outils. La plupart des clients MCP journalisent les appels, pas les changements de métadonnées. Enregistrez chaque rafraîchissement de définition avec un horodatage, et conservez les actions de l’agent qui ont suivi. Si une machine s’est bien connectée à un serveur hostile, c’est la différence entre une investigation cadrée et une supposition.

Pour une base plus large, l’OWASP MCP Security Cheat Sheet couvre les contrôles périphériques : signature des messages, liaison d’interface, validation de l’en-tête Host et stockage natif des identifiants.

Statut

Élément	Détail
Divulgation	Blog de recherche Pillar Security, publié le 12 août 2026 ; diffusion de la campagne observée le 10 août 2026
Classe	Diffusion supply chain + poisoning de métadonnées d’outils MCP conditionné à l’exécution
Déclencheur	Compteur en mémoire par client ; les métadonnées changent au troisième tools/call
Diffusion	23 pull requests GitHub publiques en 74 minutes ; 17 configs de point d’accès distant, 4 configs de script local caché, 2 soumissions d’annuaire
Statut de merge à la revue	0 fusionnée via le mécanisme de merge GitHub — 19 fermées, 4 ouvertes
Antériorité	Attaque dormante MCP WhatsApp d’Invariant Labs (avril 2025) ; formalisation des rug pulls ETDI, arXiv 2506.01333 (juin 2025)
CVE	Aucune attribuée — il s’agit d’une campagne d’acteur malveillant, pas d’une vulnérabilité produit
Angle mort défensif	Une revue à l’approbation ne peut pas observer des métadonnées qui ne deviennent hostiles qu’après approbation