Serveurs MCP malveillants et sécurité des e-mails : la nouvelle menace pesant sur la chaîne d'approvisionnement

En septembre 2025, une seule ligne de code cachée dans une bibliothèque npm open source a bouleversé nos certitudes quant à la sécurité de la chaîne d'approvisionnement. Elle a fait prendre conscience du danger que représentent les attaques malveillantes visant la sécurité des serveurs de messagerie MCP, les classant parmi les nouvelles menaces les plus dangereuses.

Le paquet, baptisé « postmark-mcp », a passé plus d'une semaine à transférer chaque jour entre 3 000 et 15 000 e-mails d'entreprise à un pirate. Il ne s'agissait pas ici d'une faille « zero-day » spectaculaire, mais simplement d'une règle de copie cachée (BCC) basique, exécutée avec tous les droits d'administrateur. Les conséquences ont été dévastatrices : des mots de passe, des factures internes, des données clients et des jetons d'authentification actifs ont été divulgués.

Il s'agit du premier cas documenté d'une intrusion malveillante sur un serveur MCP en conditions réelles. À mesure que les agents IA autonomes se déploient dans les pipelines des entreprises, ils créent une faille de sécurité considérable. Les défenses traditionnelles telles que SPF, DKIM et DMARC ont été conçues pour une époque où le routage du courrier était prévisible et géré par des humains. Le paradigme du Model Context Protocol (MCP) bouleverse complètement cette approche, en introduisant une couche de menaces internes que les filtres de périmètre traditionnels ne peuvent tout simplement pas détecter.

Ce qui s'est passé – L'affaire « postmark-mcp »

Postmark (exploité par ActiveCampaign) est un service d'e-mails transactionnels très répandu, utilisé par des milliers d'entreprises pour envoyer des notifications automatisées essentielles, telles que des réinitialisations de mot de passe et des confirmations de commande. Afin de répondre à l'essor de l'IA générative, un dépôt open source officiel a été lancé sur GitHub pour permettre aux développeurs d'intégrer directement l'assistant IA Claude d'Anthropic à l'infrastructure de Postmark via le Model Context Protocol.

Voyant là une faille facile à exploiter, un acteur malveillant a publié un paquet similaire baptisé « postmark-mcp ». Il ne s'agissait pas d'une simple erreur de typosquatting, mais d'une correspondance exacte du nom, conçue pour piéger les développeurs cherchant à effectuer rapidement une installation via npm.

Une stratégie à long terme : instaurer la confiance

L'attaquant a mené une stratégie à long terme bien calculée. Au cours des quinze versions successives (de la 1.0.0 à la 1.0.15), le paquet a fonctionné sans aucun problème. Il reproduisait fidèlement le code du dépôt officiel, exécutait parfaitement les appels d'API et ne déclenchait aucune alerte. Cela lui a permis de passer inaperçu lors des contrôles automatisés en sandbox et de gagner la confiance initiale des systèmes de surveillance de la sécurité.

Activation de la charge utile

Des dommages importants ont été causés le 17 septembre 2025, avec la version 1.0.16. Au cœur du fichier index.js, à la ligne 231, l'éditeur a ajouté une ligne de code. Cette modification ajoutait une adresse en copie cachée (BCC) à chaque message électronique transitant par le serveur et acheminait des copies vers un domaine contrôlé par un pirate [giftshop.club].

Comme ce module était intégré à la couche applicative validée, il disposait déjà d'un accès autorisé aux clés API actives. L'attaque n'a nécessité aucune technique sophistiquée d'escalade de privilèges. Elle a fonctionné parce que le code s'exécutait au sein d'un pipeline d'entreprise de confiance. La fuite de données s'est poursuivie jusqu'au 25 septembre 2025, date à laquelle le moteur de détection des risques de Koi Security a signalé des comportements anormaux provenant de la bibliothèque.

L'impact

Les audits menés après l'incident par Koi Security et Snyk ont révélé que le paquet avait été téléchargé environ 1 643 fois, ce qui correspondait à quelque 1 500 installations actives par semaine, entraînant une fuite quotidienne de données.

Une fois la faille découverte, l'éditeur a supprimé le paquet de npm. Mais voici le véritable casse-tête : retirer un paquet d'un registre public ne le supprime pas des environnements actifs. Tout cluster cloud ou pipeline de conteneurs actif exécutant la version 1.0.16 a continué à divulguer des données jusqu’à ce que les équipes le repèrent et le suppriment manuellement. Postmark a rapidement publié un communiqué précisant qu’il n’avait ni développé, ni autorisé, ni maintenu ce paquet. Comme il s’agissait d’une porte dérobée comportementale plutôt que d’une faille de code, aucun identifiant CVE (Common Vulnerabilities and Exposures) officiel n’a été attribué, ce qui laisse dans son sillage une empreinte unique et non vérifiée d’attaque de la chaîne d’approvisionnement du serveur MCP.

Si vous pensez que votre équipe a déjà utilisé ce paquet, traitez cela comme un incident en cours : désinstallez-le immédiatement de tous les environnements, renouvelez tous les identifiants et clés API qui ont transité par ce paquet, et passez au crible vos journaux de messagerie à la recherche de messages en Cci destinés au domaine signalé. Il est également recommandé de vérifier le reste du compte de l'éditeur ; le même auteur gérait environ 31 autres paquets, dont chacun pourrait présenter le même risque.

Pourquoi les serveurs MCP constituent-ils une cible de choix pour les attaques par e-mail ?

Le protocole MCP (Model Context Protocol) est en passe de devenir le cadre d'intégration de référence pour l'IA d'entreprise. Selon les prévisions de Gartner, d'ici fin 2026, 75 % des fournisseurs de passerelles API auront intégré des outils MCP natifs pour gérer la sécurité des e-mails via l'IA agentique.

En quoi consiste exactement l'intégration du protocole MCP (Model Context Protocol) ? Considérez un serveur MCP comme une passerelle API sécurisée reliant un assistant IA (tel que Claude) à des référentiels de données externes, des environnements de développement et des outils tiers. Au lieu de gérer un enchevêtrement complexe d'API personnalisées, un agent IA utilise ce protocole unifié pour interroger des bases de données, consulter des CRM ou orchestrer des flux d'e-mails de manière autonome.

La vulnérabilité fondamentale : la confiance aveugle

Pour être efficace, un serveur MCP doit disposer de droits d'accès étendus et à long terme. Lorsque vous connectez un agent IA à une passerelle de messagerie pour automatiser la planification ou le service client, vous lui accordez un accès complet en lecture et en écriture. Il agit alors comme un employé disposant de tous les droits de délégation.

Comme l'a souligné Idan Dardikman, directeur technique de Koi Security, les entreprises confient en substance des droits d'administration illimités à des outils backend développés par des auteurs externes non vérifiés et non fiables.

Contrairement aux attaques traditionnelles visant la chaîne logistique logicielle (comme celle de SolarWinds) qui ciblent les infrastructures profondes, les risques liés aux serveurs MCP tiers ne nécessitent aucune intrusion dans l'infrastructure. Il suffit aux pirates de vous inciter à installer le module pour que l'agent IA l'exécute de manière autonome. Comme aucun intervenant humain n'est présent pour vérifier un flux de travail automatisé, une bibliothèque compromise peut exfiltrer des données sensibles pendant des jours sans déclencher le moindre signal d'alerte.

Les lacunes de l'authentification des e-mails : ce que DMARC peut et ne peut pas protéger

Alors que les équipes chargées de la gestion des risques s'efforcent de se prémunir contre ces menaces par e-mail liées à des attaques de la chaîne d'approvisionnement via l'IA, beaucoup pensent que des protocoles tels que SPF, DKIM et DMARC permettront d'endiguer le problème. Mais il faut examiner de près ce que ces mesures permettent réellement de gérer, et où se situent les lacunes.

Ce que les protocoles DMARC, SPF et DKIM ont été conçus pour empêcher

La suite de base comprenant SPF, DKIM et DMARC a été conçue pour empêcher l'usurpation de domaine et empêcher les acteurs malveillants de mener des campagnes d'usurpation d'e-mails ou de BEC en utilisant l'identité de votre marque.

• SPF vérifie si l'adresse IP du serveur de messagerie expéditeur est autorisée dans vos enregistrements DNS.
• Le protocole DKIM ajoute une signature numérique unique à l'en-tête afin de garantir qu'un message n'a pas été altéré pendant son acheminement.
• DMARC les relie entre eux, en imposant des règles sur la manière dont les serveurs destinataires gèrent les échecs.

Dans le cas de l'exploit « postmark-mcp », ces contrôles n'ont pas été contournés ; ils étaient tout simplement hors de propos. Le paquet malveillant étant intégré à une application d'entreprise légitime, il utilisait des clés API valides pour acheminer les messages via les serveurs Postmark autorisés. Chaque e-mail volé comportait une signature DKIM irréprochable et passait haut la main SPF . Il y a là une ironie cruelle : cette signature DKIM valide a même aidé le serveur de réception de l'attaquant à confirmer que les messages volés étaient authentiques.

Dans quels cas l'authentification des e-mails s'avère partiellement utile

Ce que l'authentification des e-mails permet et ne permet pas de faire dans ce contexte

Les protocoles DMARC, SPF et DKIM ont été conçus pour lutter contre l'usurpation d'identité, et non contre l'exfiltration de données par des initiés

La puissance des rapports DMARC en matière de visibilité

Même si elle ne permet pas de bloquer l'injection initiale de code, une solution d'authentification des e-mails bien rodée offre une visibilité essentielle. Cela passe notamment par des rapports DMARC détaillés (RUA/RUF).

Lorsqu’ils sont correctement configurés, ces enregistrements vous fournissent une cartographie détaillée de chaque adresse IP et de chaque service d’envoi actif sur votre domaine. Les rapports agrégés (RUA) résument les volumes d’envoi par source, tandis que les rapports d’échec (RUF) fournissent des détails sur chaque échec individuel. Si votre équipe SecOps surveille en permanence ces flux, elle peut détecter des pics soudains et inexpliqués dans les volumes transactionnels sortants. Le suivi de ces anomalies agit comme un détecteur de fumée, signalant qu’une intégration présente une fuite de données.

Mettre en place un filet de sécurité assorti d'une application stricte

Le passage de votre domaine à une politique DMARC stricte avec le paramètre « p=reject » constitue une protection essentielle contre les répercussions secondaires. Cela n'empêchera pas un serveur MCP interne d'envoyer des données en copie cachée (BCC), mais cela empêchera les attaquants d'exploiter les données qu'ils ont dérobées. Une politique de rejet empêche les acteurs malveillants d'utiliser des factures ou des données clients divulguées pour lancer des campagnes de phishing hautement ciblées et usurpées à l'encontre de vos clients et partenaires en utilisant votre domaine réel.

Le véritable fossé : l'hygiène des identifiants et des autorisations

Au fond, cette faille de sécurité était due à un problème d'identité et d'accès, et non à un problème de protocole d'authentification. L'attaque a abouti parce qu'un logiciel non vérifié avait accès à une clé API légitime et dotée de privilèges élevés.

Votre principale ligne de défense réside ici dans l'audit des dépendances du code et la bonne gestion des identifiants. Cependant, le déploiement d'outils d'IA autonomes sans couche de visibilité active vous laisse complètement à l'aveugle. La surveillance continue via DMARC crée le filet de sécurité actif nécessaire pour détecter les anomalies comportementales qui indiquent une attaque en cours.

Comment protéger votre organisation contre les attaques par e-mail malveillantes visant le MCP

La sécurité des e-mails sur un serveur MCP malveillant nécessite la mise en œuvre de mesures opérationnelles telles que celles décrites ci-dessous :

1. Évaluez l'empreinte de votre serveur MCP

On ne peut pas sécuriser ce qu'on ne surveille pas. Dressez un inventaire détaillé de toutes les intégrations, extensions ou points de connexion actifs liés à votre configuration de messagerie.

• Vérifiez si l'intégration provient d'un référentiel officiel d'un fournisseur ou d'un paquet communautaire non vérifié sur npm ou PyPI.
• Indiquez clairement quelles données et quels points de terminaison chaque intégration peut utiliser.
• Utilisez des outils de sécurité open source tels que mcp-scan pour recenser et analyser votre environnement à la recherche d'anomalies comportementales.

2. Appliquer le principe du privilège minimal aux intégrations d'IA dans la messagerie électronique

Cessez d'accorder un accès administratif illimité aux outils automatisés.

• Limitez les clés API de manière à ce qu'elles n'autorisent que les actions strictement nécessaires (par exemple, l'envoi de notifications), tout en bloquant explicitement l'accès complet en lecture et en écriture à la boîte de réception.
• Appliquez des calendriers stricts de rotation des clés API et révoquez immédiatement les identifiants si une dépendance déclenche une alerte.
• Utilisez un pare-feu et des politiques de sécurité réseau pour limiter les destinations sortantes depuis les serveurs MCP et n'autoriser que les points de terminaison API de messagerie d'entreprise connus.

3. Activer les rapports DMARC et surveiller les anomalies

Si vous ne traitez pas activement les données DMARC agrégées, vous vous exposez à un risque opérationnel considérable. La mise en place d'un outil d'analyse DMARC dédié offre à votre équipe une visibilité en continu, ce qui vous permet de suivre les flux de données, d'établir des références en matière de volume et d'être alerté en cas de pics soudains de transactions sortantes avant que des dommages graves ne surviennent.

4. Appliquer DMARC avec le paramètre p=reject

Laisser votre domaine avec une configuration p=none, peu sécurisée, n'offre aucune protection réelle. Passer à un niveau d'application strict p=reject garantit que, même si un pirate parvient à exfiltrer le contenu des e-mails via une intégration compromise, il ne pourra jamais utiliser ces informations volées pour lancer des campagnes d'usurpation d'identité imitant le domaine officiel de votre marque.

5. Vérifier les serveurs MCP avant leur déploiement

Traitez tout module serveur MCP avec le même niveau de rigueur que n'importe quel autre élément privilégié de l'infrastructure d'entreprise. Vérifiez les antécédents de l'éditeur, comparez les paquets avec la documentation officielle du fournisseur et examinez le code source sous-jacent avant de les déployer en production.

Pour minimiser les risques, évitez les solutions communautaires non certifiées et privilégiez les intégrations certifiées et validées par les fournisseurs. Pour les équipes qui déploient des solutions d'automatisation, le recours à des options validées par les fournisseurs, telles que le serveur MCP de PowerDMARC, garantit une couche d'intégration sécurisée et authentifiée, spécialement conçue pour assurer la sécurité des opérations d'entreprise.

Une vision d'ensemble – La sécurité MCP va définir la prochaine étape des menaces liées aux e-mails

La faille de la bibliothèque postmark-mcp était, par conception, peu sophistiquée : un seul développeur, une astuce rudimentaire de correspondance de noms et une seule ligne de code cachée. Elle a pourtant entraîné une fuite massive de données. À mesure que les entreprises adoptent rapidement des outils d'IA autonomes et que le MCP s'impose comme la norme dans les architectures logicielles, les groupes malveillants ne manqueront pas de mettre en place des opérations bien plus sophistiquées.

Les équipes de sécurité doivent se préparer à faire face à plusieurs vecteurs de menaces émergents :

• Injection indirecte de commandes: les pirates envoient des e-mails malveillants conçus pour manipuler un agent IA chargé de lire la boîte de réception et le pousser à détourner des données sensibles ou à divulguer des clés internes.
• Outils de flux de travail malveillants: les pirates publient des outils de productivité basés sur l'IA qui semblent utiles, mais qui collectent discrètement des identifiants et des jetons en arrière-plan.
• Faux sites très convaincants: campagnes sophistiquées de typosquatting ciblant les intégrations CRM, RH et financières des entreprises sur les réseaux de distribution de logiciels pour développeurs.

Le courrier électronique est particulièrement vulnérable, car il se situe à la croisée de la communication d'entreprise, de la vérification d'identité (réinitialisation des mots de passe) et des données commerciales critiques. Les serveurs MCP qui relient l'IA à cette infrastructure ont accès à ces trois éléments.

Conclusion

Le paysage des menaces par e-mail a évolué bien au-delà du simple hameçonnage externe. L'incident Postmark-MCP démontre que les entreprises sont désormais confrontées à des menaces natives de l'IA qui opèrent en toute discrétion au sein d'environnements internes de confiance. Ces attaques par intégration exploitent des identifiants valides pour contourner les filtres traditionnels, raison pour laquelle la sécurité des e-mails sur les serveurs MCP malveillants doit désormais figurer à l'ordre du jour de tout responsable de la sécurité des systèmes d'information (RSSI).

Pour protéger votre entreprise, il faut trouver le juste équilibre entre des contrôles d'accès rigoureux et un suivi continu des données. En associant une politique d'application stricte à des rapports détaillés, vous pouvez détecter les volumes d'envoi inhabituels et repérer les intégrations non autorisées avant que les données ne soient définitivement perdues.

Ne laissez pas vos systèmes automatisés sans surveillance. Protégez dès aujourd'hui votre domaine contre les menaces cachées au niveau de la couche applicative. Identifiez toutes les sources qui envoient des e-mails au nom de votre domaine ; commencez à les surveiller grâce à l'outil DMARC Analyzer de PowerDMARC.

Foire aux questions

Attends, si mes e-mails passent les vérifications SPF DKIM, en quoi s'agit-il d'une faille de sécurité ?

Car l'appel provient de l'intérieur même de votre infrastructure. Le paquet malveillant n'usurpe pas votre domaine à partir d'un serveur malveillant quelconque. Il se trouve bel et bien au sein même de votre environnement d'applications de confiance et détourne vos clés API réelles et légitimes. Aux yeux du reste du monde, c'est votre serveur qui a envoyé cet e-mail en toute légalité, raison pour laquelle les protocoles de périmètre cryptographique lui donnent le feu vert. Il s'agit d'un problème d'exfiltration de données, et non d'un problème d'usurpation de serveur.

Si DMARC ne peut pas empêcher la fuite de données, pourquoi devrais-je l'activer ?

Considérez les rapports agrégés DMARC de RUA comme le détecteur de fumée de votre réseau. Si un serveur MCP commence discrètement à envoyer en copie cachée (BCC) des milliers d'e-mails opérationnels vers une boîte de réception tierce, le volume de vos e-mails transactionnels va monter en flèche. Si vous surveillez activement vos flux de données DMARC, cette variation soudaine de volume sautera aux yeux, ce qui permettra à votre équipe SecOps de disposer d'une alerte précoce pour vérifier les dépendances du code actif.

Notre équipe a besoin d'outils d'IA pour traiter les e-mails d'assistance. Comment pouvons-nous procéder en toute sécurité sans désactiver complètement les intégrations ?

Il n'est pas nécessaire de bloquer l'automatisation par IA, il suffit simplement de la encadrer. Tout d'abord, considérez les serveurs MCP comme des composants d'infrastructure à haut risque : n'installez jamais de scripts bruts provenant de la communauté sans les avoir préalablement soumis à une révision du code. Ensuite, définissez des autorisations extrêmement précises pour vos clés API ; si un agent doit uniquement envoyer des réponses d'assistance, verrouillez son jeton API de manière à ce qu'il soit physiquement impossible d'effectuer des lectures de données en masse, de créer des comptes ou de définir des règles de mise en copie cachée (BCC). Enfin, privilégiez les intégrations de fournisseurs vérifiées, comme le serveur MCP de PowerDMARC, plutôt que des clones communautaires non vérifiés.

Comment puis-je vérifier si mon équipe de développement a installé par inadvertance un serveur MCP malveillant ?

La première étape consiste à effectuer une analyse de la composition logicielle (SCA) ou à utiliser des outils open source tels que mcp-scan pour cartographier votre environnement opérationnel. Examinez attentivement les registres de paquets publics tels que npm et PyPI afin d'identifier les bibliothèques communautaires tierces non vérifiées qui gèrent vos pipelines de communication. Si une bibliothèque n'est pas directement publiée et signée par un fournisseur d'entreprise vérifié, comme le référentiel officiel Postmark ou le serveur MCP sécurisé de PowerDMARC, considérez-la comme un risque jusqu'à ce que le code soit audité manuellement.

• À propos de
• Derniers messages

Milena Baghdasaryan

Spécialiste du contenu chez PowerDMARC

Milena est une rédactrice et créatrice de contenu qualifiée qui possède plus de 7 ans d'expérience dans la création de contenu attrayant sur les technologies de l'information, la cybersécurité, les événements virtuels, etc. Elle est diplômée d'institutions prestigieuses telles que la New York University Abu Dhabi, l'UWC China et le Collège d'Europe.

Derniers messages de Milena Baghdasaryan (voir tous)

• Longueur de clé DKIM : comment choisir entre 1 024, 2 048 et 4 096 - 9 juillet 2026
• Qu'est-ce que ClickFix (et FileFix) ? - 8 juillet 2026
• Comment choisir un fournisseur de messagerie électronique : un cadre d'évaluation axé sur la sécurité - 1er juillet 2026