Ver npm sur les packages de mailing : quand un client MCP « postmark » exfiltre discrètement vos emails transactionnels

> En bref : Un package npm de mailing transactionnel très utilisé (plusieurs millions de téléchargements hebdomadaires) a été compromis via le vol des identifiants npm d'un mainteneur. La version malveillante ajoute une ligne de code qui place en copie cachée (BCC) chaque email envoyé via le package vers une adresse contrôlée par l'attaquant, avant de se retirer d'elle-même du code après quelques jours pour brouiller les pistes. Les applications qui envoient des bulletins de salaire, des factures ou des liens de réinitialisation de mot de passe par email via ce package ont potentiellement exfiltré ces documents en clair pendant la fenêtre de compromission.

Pourquoi ça vous concerne directement

Si votre SaaS RH ou paie envoie des bulletins de salaire, des confirmations de virement ou des liens magiques de connexion par email, il y a de fortes chances que ce soit via une librairie tierce plutôt qu'un serveur SMTP fait maison. C'est exactement la surface visée ici : pas votre code, pas votre infrastructure, mais une dépendance que vous avez ajoutée un jour avec npm install et jamais revérifiée depuis.

Le scénario est particulièrement pervers pour les emails RH : un bulletin de salaire contient nom, IBAN, montant net, parfois numéro de sécurité sociale. Un email de réinitialisation de mot de passe donne un accès direct au compte. Les deux sont des cibles de choix, et les deux transitent typiquement par ce genre de package.

Comment l'attaque a fonctionné

Ce qui rend cette attaque difficile à détecter

Contrairement à un vol de clé d'API classique qui génère du trafic sortant anormal facilement repérable, cette attaque ne fait que modifier légèrement un flux déjà légitime : l'envoi d'emails. Le volume de trafic SMTP ne change presque pas. Aucun nouveau domaine n'apparaît dans vos logs applicatifs — seulement dans l'en-tête BCC de chaque email, invisible sans inspection manuelle du contenu envoyé.

Ce qu'il faut vérifier maintenant

La leçon

Ce n'est pas la première attaque supply chain sur npm, et ce ne sera pas la dernière. Ce qui change ici, c'est la cible : pas un vol de clés cloud ou de crypto-wallet, mais l'exfiltration silencieuse de documents RH sensibles via un canal — l'email transactionnel — que la plupart des équipes ne surveillent jamais au niveau du contenu. Si votre produit envoie des données sensibles par email, la question à se poser n'est pas seulement "quel package j'utilise" mais "qui peut lire ce que ce package envoie en mon nom".