La backdoor de Postmark télécharge des e-mails

• Une activité malveillante a récemment été découverte dans le module postmark-mcp
• À partir de la version 1.0.16, du code a été ajouté pour copier les e-mails vers un serveur externe contrôlé par le développeur
• Une faille structurelle a mis en lumière l’exfiltration potentielle d’e-mails sensibles provenant de centaines d’organisations
• En raison de l’absence de modèle de confiance pour les serveurs MCP, le risque d’attaque de la chaîne d’approvisionnement augmente
• Tous les utilisateurs de MCP doivent vérifier et supprimer immédiatement ce composant si nécessaire

---

Réalité des serveurs MCP et aperçu de l’affaire postmark-mcp

• Les serveurs MCP sont des outils permettant aux assistants IA d’automatiser des tâches répétitives comme l’envoi d’e-mails ou l’exécution de requêtes de base de données
• Ces outils fonctionnent avec des privilèges très élevés, et les développeurs installent souvent du code presque uniquement sur la base de la confiance, sans véritable système de vérification
• Le package populaire postmark-mcp a repris le code source du dépôt GitHub officiel de Postmark, y a ajouté une ligne de BCC malveillante, puis l’a publié sur npm sous le même nom
• À partir de la version 1.0.16, une simple ligne ajoutée à un code paraissant normal permettait de copier tous les e-mails vers le serveur personnel du développeur (giftshop.club)
• Cela signifie que toutes les informations contenues dans les e-mails — réinitialisations de mot de passe, factures, notes internes, documents confidentiels — ont pu être exposées

Détection des comportements anormaux et structure de l’attaque

• Le Risk Engine de Koi a détecté des signes anormaux dans la version 1.0.16
• L’identité du développeur paraissait légitime sur GitHub et ailleurs, et les 15 premières versions fonctionnaient sans problème, ce qui a permis d’établir la confiance
• Dans la version 1.0.16, une seule ligne de code a ajouté une fonction d’exfiltration d’informations sensibles vers l’extérieur
• L’attaquant a utilisé une technique d’usurpation du développeur existant au moment de copier le code (Classic impersonation)
• Un outil jusque-là utilisé normalement s’est progressivement transformé en infrastructure fondée sur la confiance, avant d’exécuter ensuite un comportement malveillant

Impact et mode opératoire de la fuite d’e-mails

• Avec environ 1 500 téléchargements par semaine, et en supposant qu’environ 20 % des installations soient réellement actives, des centaines d’organisations seraient exposées
• Le volume serait estimé à 3 000 à 15 000 e-mails par jour envoyés vers giftshop.club
• Les utilisateurs ne vérifient pas le comportement de l’outil dans le détail et laissent généralement l’assistant IA exécuter la plupart des actions automatiquement
• Il n’existe aucun modèle de sécurité, sandbox ni processus de validation dédié
• Le développeur a supprimé le package de npm, mais cela n’a aucun effet sur les environnements où il était déjà installé, si bien que les données continuent de fuir

Analyse des étapes de l’attaque

• Étape 1 : diffusion d’un outil légitime

  • De 1.0.0 à 1.0.15, le package fonctionnait correctement et accumulait de la confiance

• Étape 2 : insertion de code malveillant

  • Dans la 1.0.16, ajout d’une ligne de BCC appliquant une copie des e-mails vers l’extérieur

• Étape 3 : collecte d’informations

  • Mots de passe, clés API, données financières et clients ont été exfiltrés vers giftshop.club

• Le développeur est resté injoignable et, bien que le package ait été supprimé de npm, les environnements déjà installés continuent d’être affectés

Défauts structurels de l’écosystème MCP

• Contrairement à un package npm classique, un serveur MCP est un outil à haut risque qu’un assistant IA peut appeler automatiquement des centaines ou des milliers de fois
• Ni l’IA ni les solutions de sécurité existantes ne détectent facilement la nature malveillante du code, et l’écosystème repose essentiellement sur la confiance
• L’ensemble de l’écosystème MCP présente une structure risquée qui délègue tous les privilèges sur des actifs sensibles à des développeurs anonymes
• Il faut des contrôles de sécurité comme la détection des changements de comportement et des gateways de chaîne d’approvisionnement pour identifier ces attaques
• Koi indique travailler, avec son Risk Engine et sa gateway, à bloquer et vérifier l’introduction de packages malveillants similaires

Mesures de réponse et IOC

• Package malveillant : postmark-mcp (npm)
• Versions malveillantes : 1.0.16 et ultérieures
• Adresse e-mail d’exfiltration : phan@giftshop[.]club
• Domaine : giftshop[.]club

Méthodes de détection

• Vérifier dans les journaux d’e-mails la présence d’envois en BCC vers giftshop.club
• Examiner dans la configuration du serveur MCP tout paramètre inattendu de transfert d’e-mails
• Passer en revue avec précision les installations de postmark-mcp en version 1.0.16 ou ultérieure

Réponse et remédiation

• Supprimer immédiatement postmark-mcp
• Faire tourner tous les identifiants partagés par e-mail pendant la période de compromission
• Mener une enquête complète sur les journaux d’e-mails contenant des informations sensibles potentiellement volées
• En cas de confirmation d’impact, signaler immédiatement l’incident aux autorités compétentes

Conclusion et recommandations

• Pour tous les serveurs MCP, il est indispensable de mettre en place des procédures de vérification de l’identité du développeur, validation du code et audit de sécurité
• Compte tenu de la nature de MCP comme infrastructure d’assistance IA automatisée, un minimum de défiance et une surveillance continue sont indispensables
• Les utilisateurs de postmark-mcp 1.0.16 ou supérieur doivent supprimer immédiatement le package et appliquer des mesures de sécurité
• Il faut garder à l’esprit qu’un usage fondé uniquement sur la confiance expose directement au risque d’attaque de la chaîne d’approvisionnement
• Adopter la paranoia (défiance/suspicion) comme principe par défaut est une stratégie rationnelle pour utiliser MCP

[GN⁺]

Commentaire Hacker News

• Je me demande en quoi c’est différent de la backdoor de l’extension Thunderbird et de cette affaire. J’ai maintenu une extension Thunderbird autrefois, puis j’ai perdu l’intérêt pour le projet. Quelqu’un a commencé par faire quelques vraies contributions, puis a soudain insisté lourdement pour reprendre le projet. Au final, je me suis dit qu’il était hors de question de remettre des dizaines de milliers de clés de boîtes mail à un inconnu, donc j’ai refusé. C’est déjà assez absurde que les gens m’aient fait autant confiance au départ, mais au moins moi, j’étais quelqu’un de bien
  • Je pense exactement pareil. Ce n’est pas un problème propre à MCP, c’est le même problème pour tous les logiciels. Au final, on n’a pas d’autre choix que de faire confiance aux développeurs et aux fournisseurs. Je ne peux pas empêcher Microsoft de copier mes mails Outlook, ni Google de copier Gmail. Même quand c’est open source et qu’on dit que « beaucoup d’yeux » examinent le code, ça peut être vrai pour des projets populaires, mais le risque reste là. En pratique, la plupart des gens font simplement confiance aux développeurs. C’est un vieux problème chronique, aussi ancien que le logiciel lui-même
  • Dans la situation que tu décris, je repense sans cesse à une déclaration de Zuckerberg sur la vie privée. Il faut vraiment se demander pourquoi on confie aveuglément nos données et notre vie privée à n’importe qui
  • Il m’est arrivé souvent de ramener chez eux des inconnus ivres. Je leur dis toujours que monter dans la voiture d’un inconnu, c’est vraiment dangereux. Franchement, ils ont juste eu de la chance de tomber sur quelqu’un de bien comme moi qui avait du temps à perdre. J’ai tendance à traîner tard dans les petits bars du quartier, donc ça arrive souvent
• Je ne suis pas d’accord avec l’idée qu’un téléchargement npm équivaut bientôt à une organisation unique. Ce chiffre est vraiment exagéré. Un téléchargement sur npm, c’est juste quelqu’un (npm i) ou quelque chose (un environnement automatisé) qui installe le paquet. En pratique, si le CI est bricolé à la va-vite, npm i peut tourner à chaque exécution, voire à chaque étape. Donc 1 500 téléchargements peuvent en réalité venir de seulement deux entreprises : l’une avec un développeur qui l’utilise pour un PoC, l’autre avec une configuration CI catastrophique. Même le dépôt officiel n’a que 1 watch, 0 fork et 2 stars https://github.com/ActiveCampaign/postmark-mcp. Les problèmes de MCP et de supply chain sont réels et graves, mais dans ce cas précis, l’impact réel est quasiment nul
  • Avec la même logique, les téléchargements des paquets Python populaires ne vont pas tarder à atteindre un niveau où chaque être humain sur Terre — enfants, personnes âgées, même ceux qui ne savent pas ce qu’est un ordinateur — en aura téléchargé un exemplaire. https://pypistats.org/top
• L’article lui-même est bien, mais je ne vois pas pourquoi il faudrait lire une version traduite/résumée par ChatGPT. J’aurais préféré voir le prompt d’origine. Là, ça donne juste une impression de lenteur inutile et de mépris pour l’utilisateur
  • Content de voir que je ne suis pas le seul à ressentir ça. Je déteste tellement le style marqué par l’IA, alors que certains de mes amis ne le remarquent même pas ou s’en moquent complètement
• On le voit souvent ces temps-ci, mais j’ai l’impression qu’on ne parle pas assez du fait qu’on confie des pouvoirs divins à ce genre d’outils. On leur fait confiance alors qu’on ne connaît même pas le visage de ceux qui les ont créés. Pareil pour les assistants IA. Tout le monde leur accorde juste une confiance à 100 %. Il existe des articles qui soulignent ça, mais ça me fait l’effet de : « Saviez-vous que si vous pointez le canon vers votre pied et appuyez sur la détente, vous vous tirerez dans le pied ?? » C’est tellement évident que j’ai l’impression qu’on fabrique du contenu à partir d’un quasi-néant. Je me demande vraiment s’il y a tant de gens que ça qui ne s’en rendent pas compte, ou si c’est juste une excuse pour écrire un article
  • Il y a eu récemment un article sur un assistant de code IA qui a effacé la base de données de production d’une entreprise https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. Il y a plusieurs niveaux là-dedans : 1) le fondateur faisait une confiance totale à l’outil IA et s’est fait piéger lui-même. Donc oui, il était réellement ignorant. 2) En plus, il avait laissé l’accès direct à la base de prod depuis l’environnement de développement. C’était de toute façon une configuration où un incident devait finir par arriver un jour
  • Ce qui semble évident à un utilisateur de HN ne l’est absolument pas pour la majorité du monde. Ce genre d’articles est utile pour ces personnes. En réalité, les serveurs MCP et la conception des agents IA sont intrinsèquement peu sûrs, parce que la sécurité n’a même pas été sérieusement discutée au départ. Peut-être que ça changera plus tard, peut-être pas, mais d’ici là, continuer à le répéter reste ce qu’on peut faire de mieux
  • « Les gens sont vraiment à ce point-là peu attentifs ? » Même les injections SQL basiques continuent de causer chaque année d’énormes dégâts, et elles figurent toujours en haut du classement OWASP. L’injection SQL, au fond, revient aussi à donner des pouvoirs divins à une base de données sans comprendre son fonctionnement. Les autorisations d’action des agents IA peuvent elles aussi être invisibles pour l’utilisateur
  • Le fait que ce type d’accès inconsidéré se produise déjà à grande échelle via MCP devrait être bien davantage débattu. Même des gens habituellement prudents ne perçoivent souvent pas correctement le risque
  • À une époque, le fait qu’un client mail exécute des mails contenant des scripts envoyés par n’importe qui sur Internet s’appelait une « révolution de l’automatisation ». À une autre époque, on pensait aussi qu’il était plus sain pour les enfants d’utiliser Internet plutôt que de regarder la télévision. On sait tous comment ça s’est terminé, non ?
• Il y a l’idée selon laquelle « il est devenu normal d’installer des outils créés par n’importe qui », mais en réalité, depuis l’époque de Windows XP, on installait sans arrière-pensée tout et n’importe quoi, du logiciel de rip de CD à Bonzi Buddy. La commodité a toujours primé sur la sécurité. La vraie leçon importante, au fond, c’est de se demander pourquoi « sandbox, sandbox, sandbox » n’est toujours pas devenu une réalité. Dans cette affaire, on a l’impression que l’IA a complètement réinitialisé en usine tous les principes de sécurité existants
  • À la question « les gens choisissent facilement la commodité plutôt que la sécurité, alors pourquoi le sandboxing n’est-il toujours pas une réalité ? », la réponse est que le sandboxing n’est pas facile à mettre en œuvre. Et ici, « facile » veut dire fourni par défaut par l’OS
• Un utilisateur peut recevoir sur GMail un spam contenant une prompt injection destinée à l’IA, sans même qu’un humain n’ouvre le message https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
• Ce billet de blog est vraiment pénible à lire. On dirait que l’IA y a mis la main. Il y a trop de phrases inutiles et de fioritures. Dommage, parce que le sujet est intéressant
• Dans les problèmes de sécurité de la supply chain, les paquets npm sont presque toujours mentionnés. C’est logique, puisque npm est le plus utilisé et que la motivation des attaquants y est forte, mais ça laisse quand même un goût amer
  • OpenAI distribue aussi Codex CLI via npm. C’est écrit en Rust, et pourtant ils passent quand même par un paquet npm. Personnellement, je trouve ça absurde. Mais j’imagine que les alternatives sont encore moins pratiques
  • C’est pour ça que je ne lance pas de serveur MCP en stdio. Tous mes MCP tournent en isolation dans des conteneurs Docker, sur un hôte VM placé sur un VLAN non fiable. Et je ne m’y connecte qu’en SSE. Bien sûr, ça reste vulnérable aux prompt injections, mais je ne le relie ni à mon profil de navigateur principal, ni à mes mails, ni à mes comptes cloud. C’est totalement séparé des informations sensibles
  • Ce n’est pas souhaitable que le commentaire ci-dessus ait reçu autant de votes au point d’être pris pour la conclusion principale de l’article. Si on l’interprète comme ça, on passe à côté de l’essentiel
• Il est possible que le développeur ne l’ait même pas fait intentionnellement. Il m’est arrivé moi aussi de publier une release avec du code de debug encore dedans. Si c’était un simple bcc, ça pourrait vraiment n’être que du code de débogage
  • Je suis venu pour dire exactement ça. Franchement, il n’aurait pas laissé son adresse mail perso aussi visiblement si c’était volontaire. Et en 2025, ce n’est pas très glorieux d’utiliser encore son Gmail personnel pour des tests. Et de toute façon, ce n’est pas un problème propre à MCP : ça peut arriver avec n’importe quel paquet
  • La suppression du paquet, honnêtement, c’est la réaction typique d’un développeur débutant qui découvre son premier incident de sécurité. Si c’était une simple erreur de débogage sans intention malveillante, la communication est essentielle : retirer la version compromise, publier un correctif, puis communiquer publiquement via un blog, ici sur HN, sur les réseaux sociaux, etc., c’est la meilleure façon de restaurer la confiance. Une chronologie précise de l’incident (et pas un résumé rédigé par une IA comme celui de l’OP) aiderait aussi à rétablir la confiance
• Le problème des serveurs MCP est dangereux lui aussi, mais je pense que ce type d’attaque peut se produire dans toute situation où l’on utilise des dépendances externes, comme un paquet SMTP
  • Oui, mais pour les paquets SMTP, on s’appuie en général sur des bibliothèques éprouvées et dignes de confiance depuis longtemps. Avec MCP, tout est nouveau et il n’y a pas encore d’historique de confiance accumulé, c’est ça le problème. C’est une sorte de Far West logiciel où il faut se promener avec un six-coups (6-shooter) chargé