Pillar Security a décrit Deadbugz, une campagne au cours de laquelle un compte GitHub a soumis 23 pull requests en 74 minutes le 10 août 2026, chacune ajoutant un serveur MCP qui se comporte normalement au départ puis demande à l'agent IA connecté de rechercher des identifiants [1]. MCP, le Model Context Protocol, est la norme qu'utilisent de nombreux agents IA pour appeler des outils externes.
Contexte
Un serveur MCP indique à un agent quels outils il propose et ce qu'ils font, et l'agent lit ces descriptions comme des instructions. Un serveur qui modifie ses descriptions après l'installation peut donc changer le comportement de l'agent sans modifier le code qu'un relecteur a examiné [1].
Ce que décrit le rapport
Les pull requests provenaient d'un compte public nommé zellkernel et visaient des projets d'IA et d'outils de développement sans lien entre eux, entre 21 h 52 et 23 h 07 UTC. Dix-sept configuraient un point d'accès MCP distant, quatre faisaient référence à un script Python local caché et deux étaient des soumissions à des annuaires. Dix-neuf avaient été fermées et quatre étaient encore ouvertes lorsque Pillar les a examinées, et aucune n'avait été fusionnée par le mécanisme de fusion de GitHub [1].
Le serveur, appelé productivity-suite, propose de la mise en forme et du résumé de texte. Après trois appels d'outils effectués par un client connecté, il réécrit ses propres descriptions d'outils afin que l'agent reçoive l'instruction de rechercher des clés SSH, des identifiants AWS, l'historique du shell et la configuration Kubernetes, tout en dissimulant cette activité à l'utilisateur. Pillar indique que le point d'accès distant était toujours actif au moment de son analyse [1].
Conséquences pour les utilisateurs de Mac
Les développeurs qui ajoutent des serveurs MCP à la configuration d'un agent, ou qui acceptent des pull requests qui le font, constituent le groupe exposé. Pillar ne signale aucune fusion : la campagne, telle qu'elle est décrite, n'avait donc pas abouti via GitHub au moment de l'examen. Un développeur qui aurait copié à la main l'une de ces configurations échapperait toutefois à ce décompte [1].
Recommandations
- Examinez toute pull request qui ajoute ou modifie une entrée de serveur MCP avec autant de soin qu'une pull request qui ajoute du code.
- Recherchez sur les machines et dans les dépôts le point d'accès et le chemin de script indiqués par Pillar, et annulez les modifications qui les introduisent.
- Privilégiez les clients MCP qui avertissent lorsqu'un serveur modifie ses définitions d'outils après approbation, comme le recommande Pillar.
- Dans la mesure du possible, tenez les clés SSH, les identifiants cloud et l'historique du shell hors de portée des processus d'agents.
Pertinence pour FireAI
FireAI ne lit ni les configurations MCP ni les instructions que reçoit un agent, et il ne peut pas demander à un agent de les ignorer. Pour un serveur distant comme celui décrit, chaque connexion est un événement réseau : en mode Alerte, la première connexion d'une app vers une nouvelle destination déclenche une demande, et une règle par app peut bloquer cet hôte. Un serveur qui s'exécute localement et se contente de lire des fichiers ne génère aucun trafic réseau que FireAI puisse voir.
Limites
Le texte consulté du rapport n'indique pas de date de publication. L'attribution repose sur le compte public, et l'opérateur qui se cache derrière reste inconnu. Le rapport ne précise pas si un agent a effectivement exécuté les instructions hostiles ni si des identifiants ont été dérobés [1].
Essayez FireAI, par HisnLabs gratuitement pendant 17 jours.