Deadbugz : un serveur MCP qui devient hostile au troisième appel d’outil, poussé vers 23 dépôts en 74 minutes

Le 10 août 2026, un compte GitHub, zellkernel, a ouvert 23 pull requests en 74 minutes contre des dépôts sans lien entre eux, consacrés à l’IA, à MCP et à l’outillage de développement, chacune ajoutant un serveur MCP nommé productivity-suite qui annonçait deux outils ordinaires, format_text et summarize. Selon Pillar Security, qui a nommé la campagne Deadbugz et publié son analyse le 12 août, le serveur a renvoyé des résultats honnêtes lors de ses trois premiers appels, puis a réécrit les métadonnées qu’il transmettait à l’agent : les descriptions d’outils et le contenu des prompts ont commencé à orienter le modèle vers clés SSH, identifiants AWS, l’historique du shell et la configuration Kubernetes, et lui demandant de dissimuler cette activité à l’utilisateur. Dix-neuf des 23 pull requests ont été fermées, quatre étaient encore ouvertes et aucune n’avait été fusionnée au moment où Pillar les a examinées. Aucune victime n’a été confirmée. Il s’agit d’une entrée, rapportée par d’autres et citée ici en renvoyant à eux. Les autres incidents documentés concernant des agents, chacun avec ses propres sources, sa gravité, son niveau de confiance et son indicateur de contestation, figurent dans l’archive des incidents d’IA — ainsi, une campagne de chaîne d’approvisionnement visant l’outillage des agents peut être lue aux côtés du reste de ce qui s’est réellement produit.

Les archives attribuent à cette fiche une gravité élevée et un niveau de confiance A — bien documentée, avec des sources primaires concordantes — tout en indiquant séparément qu’aucun préjudice réel confirmé n’a été relevé. Ces deux constats sont vrais simultanément, et c’est précisément de cet écart dont traite la fiche : une campagne dont la conception a été documentée avec un niveau de détail inhabituel avant qu’elle ne fasse une victime que l’on puisse nommer. Les deux dates qui comptent sont séparées de deux jours. Les pull requests ont été envoyées le 10 août ; Ariel Fogel, de Pillar Security, a publié l’analyse le 12 août, et l’article comporte une note permanente indiquant qu’il serait mis à jour à mesure que des informations vérifiées seraient disponibles.

Trois appels, puis les métadonnées changent.

Un serveur MCP n’a pas besoin d’exécuter du code sur une machine pour modifier ce que fait un agent. Les définitions d’outils sont transmises au modèle comme contexte à chaque session, ce qui signifie que le serveur qui les fournit peut réécrire les instructions que l’agent lit tout en laissant le nom de l’outil, son dépôt et son manifeste exactement tels qu’ils étaient. Deadbugz repose sur cette asymétrie, et le nom que Pillar donne à ce phénomène est l’empoisonnement des métadonnées MCP conditionné au runtime.

Le mécanisme est assez simple pour être énoncé en une phrase. Le serveur maintient en mémoire, par client, un compteur des requêtes tools/call reçues. Pour les trois premières, il se comporte normalement. Une fois le compteur déclenché, les réponses ultérieures à tools/list et prompts/get sont renvoyées modifiées — des descriptions d’outils différentes, des contenus de prompt différents — orientant l’agent vers des clés SSH, des identifiants AWS, l’historique du shell et la configuration Kubernetes, et lui demandant de dissimuler cette activité à l’utilisateur. Le texte du prompt empoisonné porte le marqueur deadbugz et une adresse Bitcoin.

La barrière explique aussi pourquoi les défenses ordinaires ne le détectent pas. La charge utile est présente dans la source dès la première requête ; rien dans le code ni dans la configuration ne change au moment du basculement. Une analyse statique, une entrée SBOM ou une lecture unique du manifeste de l'outil au moment de l'installation voit un utilitaire de mise en forme, car c'est ce que l'utilitaire renvoie jusqu'à ce que le compteur change. Pillar décrit le basculement différé comme une technique d'évasion de la recherche et affirme que ses chercheurs ont confirmé à la fois le seuil et les métadonnées modifiées en envoyant des requêtes textuelles au service distant en ligne et en comparant les réponses au code source public.

Un détail élargit le piège au-delà d’une seule session. Le serveur annonce tools.listChanged, la capacité MCP qui indique à un client que sa liste d’outils a été révisée. Un client qui respecte ce signal relira les définitions en cours de session et récupérera la version empoisonnée sans aucune action de l’opérateur ; un client qui met en cache les définitions lors de l’approbation ne le fera pas. Le comportement d’un agent donné est une propriété du client, non du serveur, et le compte rendu de Pillar n’énumère pas les clients par leur nom.

Livraison : 23 pull requests en 74 minutes

La distribution n'était pas un paquet sur un registre ni une dépendance empoisonnée enfouie dans un fichier de verrouillage. C'était du spam de pull requests visant des projets sans aucun rapport avec la fonction supposée du serveur, ce qui correspond à la forme que prend une tentative d'attaque de chaîne d'approvisionnement à moindre coût lorsque l'attaquant ne peut pas obtenir un compte de mainteneur : soumettre suffisamment de modifications de configuration et attendre que l'une d'elles soit fusionnée ou appliquée localement.

La décomposition des 23 par Pillar se fait en trois volets. Dix-sept ajoutent un point de terminaison MCP distant, productivity-suite-mcp[.]onrender[.]com/mcp, hébergé sur Render ; quatre invoquent un fichier Python local caché à ~/.config/.cache/.sys/.deadbug-mcp.py ; deux sont des soumissions à des annuaires ou à des listes, que le compte rendu considère comme de la reconnaissance ou du remplissage plutôt que comme une livraison. La fenêtre est indiquée comme allant de 21 h 52 à 23 h 07 UTC le 10 août 2026 — 74 minutes selon le cadrage de la divulgation, bien que les deux horodatages eux-mêmes couvrent 75 minutes, et rien dans le dossier ne dépend de cette minute. Un seul dépôt cible est nommé individuellement : getsentry/sentry-mcp, demande de fusion n° 1239, cité comme exemple de la livraison d’artefact local.

Le compte derrière tout cela était conséquent pour son âge. Au moment de la collecte de Pillar, zellkernel comptait 50 dépôts publics, dont 20 forks, et 21 de ces 50 avaient été créés le 10 août, le même jour que la campagne. Le profil était lié de manière croisée au compte X @llmgod, qui renvoyait au compte GitHub, ce type de liaison réciproque plaidant en faveur d'une identité créée dans un but précis plutôt que d'une identité détournée.

Dix-neuf fermées, quatre ouvertes, zéro fusionnée : c’est le chiffre le plus répété du dossier, et aussi celui que l’on interprète le plus souvent comme un feu vert, ce qu’il n’est pas tout à fait. Le bouton de fusion de GitHub n’est pas le registre d’exécution d’un hôte : un mainteneur peut récupérer une branche et l’exécuter, appliquer une configuration à la main, ou une tâche CI peut récupérer la tête d’une PR avant tout commentaire. Les quatre pull requests qui écrivent une configuration invoquant un chemin de script local sont celles où cet écart compte le plus, car le script est récupéré et exécuté entièrement en dehors du décompte des fusions de GitHub. Cloud Security Alliance Labs a souligné la même chose dans sa note du 2 septembre : les décomptes des fermées et des non fusionnées ne prouvent pas que rien n’a été exécuté.

Ce qui est établi, et ce qui ne l’est pas

Établi par la divulgation, en ce sens que Pillar le rapporte à partir d’artefacts qu’il a lus et, dans un cas, d’un service qu’il a interrogé : le serveur et son dépôt source, les deux outils annoncés, le compteur et le seuil de trois appels, les quatre cibles d’identifiants, les décomptes de PR et leur statut de fusion lors de l’examen, ainsi que le lien entre le compte GitHub et l’identifiant X. Les tests menés par Pillar lui-même sur le point de terminaison en production constituent l’élément le plus solide de la liste, car il s’agit d’une reproduction plutôt que d’une lecture du code source.

Non établi, et le dossier se montre prudent sur ce point : une victime. Le champ real_harm du dossier vaut false, ce qui porte sur les preuves, non sur l’intention — personne n’a produit un hôte, un journal ou un identifiant dérobé lié à cette campagne. L’identité de la personne ou du groupe derrière zellkernel et @llmgod n’est pas non plus établie ; Pillar attribue l’opération aux comptes et s’arrête là. Le motif financier repose sur une adresse Bitcoin intégrée dans la charge utile, ce qui relève d’une inférence à partir d’un indicateur, et non d’une conclusion sur l’acteur. Et la question à laquelle un défenseur veut le plus avoir une réponse — savoir si la campagne est toujours en cours — reste sans réponse dans le dossier : la publication était marquée comme devant être mise à jour, et aucune révision ultérieure ni notification de retrait de GitHub ou Render n’est visible.

La corroboration est plus ténue que ne pourrait le suggérer le niveau de confiance, et il vaut la peine de le dire clairement. Deux notes de recherche de Cloud Security Alliance Labs, datées du 30 août et du 2 septembre 2026, reprennent la campagne ; la plus récente précise explicitement qu'elle attribue à Pillar la découverte, les détails des relations publiques, le comportement du serveur et l'attribution du compte, et ne décrit aucune vérification indépendante qui lui soit propre. Un billet de blog Armor daté du 22 septembre 2026 fournit des recommandations défensives et indique que Pillar a démonté le serveur ; il n'apporte aucune preuve forensique qui lui soit propre. Aucun CVE n'a été attribué, et la CSA indique qu'il ne s'agit pas d'une vulnérabilité de la spécification MCP. Au 29 octobre 2026, les recherches ne font apparaître aucun avis de GitHub ou Render, ni aucune couverture dans la presse spécialisée en sécurité de grande diffusion — aucun article de BleepingComputer, The Register, SecurityWeek ou Hackread — ce qui est inhabituel pour une campagne de chaîne d'approvisionnement de cette forme et fait en soi partie de ce que montre le dossier. « Les sources primaires concordent » signifie ici une source primaire à l'origine et un ensemble de documents secondaires qui en dérivent.

Deux ambiguïtés mineures méritent d’être signalées plutôt que gommées. Les résumés secondaires divergent sur la question de savoir si le troisième appel ou le quatrième est le premier à recevoir des métadonnées empoisonnées, ce qui découle de la description du compteur comme se déclenchant à la troisième requête ; le compte rendu et la divulgation utilisent tous deux trois. Et la fenêtre de livraison est décrite comme étant de 74 minutes pour des horodatages qui en couvrent 75.

Une vérification qui n'a pas pu être répétée : le 29 octobre 2026, le compte GitHub zellkernel et le dépôt zellkernel/productivity-suite-mcp renvoient tous deux 404, et l'unique pull request nommée individuellement, getsentry/sentry-mcp #1239, ne se résout plus non plus — le dépôt lui-même redirige désormais vers getsentry/toolkit. Les décomptes de PR, le statut de fusion et le contenu du dépôt ne peuvent donc pas être revérifiés directement auprès de la source originale aujourd'hui ; ils demeurent l'instantané de Pillar, pris à la mi-août.

Ce que la divulgation demande aux défenseurs de faire

La réponse recommandée par Pillar porte principalement sur le fait de traiter les métadonnées comme une surface de sécurité plutôt que comme une description de celle-ci. Pour les hôtes, les demandes concrètes sont de bloquer ou de rechercher productivity-suite-mcp[.]onrender[.]com/mcp, de conserver le point de terminaison trycloudflare.com utilisé plus tôt par la campagne dans les listes de refus et de recherche, même si Pillar indique qu'il n'est pas actuellement actif, et de ne pas exécuter deadbug-mcp.py — le chemin de fichier caché ~/.config/.cache/.sys/.deadbug-mcp.py est l'artefact à rechercher dans les répertoires personnels, les dépôts et les configurations des clients MCP.

L'ordre de l'investigation importe davantage que la liste de blocage. Si un hôte a pu se connecter, Pillar recommande de conserver les journaux du client MCP avant de nettoyer quoi que ce soit, puis d'examiner les actualisations des définitions d'outils et ce que l'agent a fait après le troisième appel ; les identifiants ne devraient être renouvelés que lorsque les preuves locales étayent une exposition, ce qui est l'inverse du réflexe de tout renouveler au moindre soupçon. La configuration du serveur autorisait également une télémétrie facultative vers un WEBHOOK_URL, avec émission de balises lors de la connexion, du premier appel et de l'événement déclencheur — un détail qui donne à une investigation un troisième endroit à examiner, au-delà des journaux clients et du trafic des points de terminaison.

Pour les personnes qui développent des clients MCP, la recommandation est structurelle, et c'est la partie du document qui a la plus longue durée de vie :

• Calculez une empreinte des définitions d'outils au moment de l'approbation et comparez-les à chaque actualisation, plutôt que de vous fier au nom et au dépôt du serveur.

• Traiter une modification de définition sur un serveur déjà approuvé comme un événement de sécurité que l’opérateur voit et réapprouve, et non comme une agitation routinière de métadonnées à absorber en silence.

• Encadrez les opérations sensibles — accès aux identifiants, exécution de code, e-mails sortants, écritures dans les dépôts — par des politiques plutôt que par des descriptions fournies par le serveur.

Ce troisième élément est ce qui fait de Deadbugz un cas documenté plutôt qu'une curiosité. Chaque contrôle ci-dessus part du principe qu'un agent peut être amené à faire des choses par le texte qu'un serveur attache à un outil, et que ce texte peut changer après que la décision de confiance a été prise. Pillar inscrit cette campagne dans une lignée qui inclut l'attaque dormante MCP de 2025 d'Invariant Labs, le paquet contrefait postmark-mcp et un paquet MCP documenté par Koi, transformé en arme via une mise à jour — tous des précédents de la technique, cités par Pillar à ce titre et non comme des preuves concernant cette livraison.

Pourquoi le portail compte plus que le nombre de victimes

Une campagne avec 23 tentatives de livraison, aucun merge et aucune victime confirmée est facile à classer comme tentative et à passer à autre chose. Si elle a sa place dans l’archive avec une sévérité élevée, c’est parce que son évasion ne dépend pas de la réussite de la livraison à grande échelle. Elle repose sur une propriété que partagent aujourd’hui la plupart des déploiements MCP : l’approbation n’a lieu qu’une fois, lors de l’installation, et la définition qui a été approuvée est supposée être celle qui sera servie. Deadbugz maintient cette hypothèse intacte pendant trois appels, puis la brise.

Le correctif n’est pas un patch pour un serveur spécifique, et il n’y a pas de CVE à suivre. C’est que « approved » doit devenir une condition continue, avec une comparaison derrière — ce qui constitue un changement dans la manière dont les clients et leurs opérateurs se comportent, et non dans ce qu’un scanner recherche. On ne sait toujours pas si quelqu’un a réellement fait tourner le serveur en août ; en l’état des éléments consignés, le mécanisme est le constat.