Comment Sapphire Sleet a compromis 145 paquets Mastra sur npm

Les paquets concernés totalisaient plus de 1,1 million de téléchargements par semaine . L’incident a donc exposé un écosystème de développeurs largement au-delà du projet Mastra et a accéléré le durcissement des règles d’authentification de Microsoft. Le 19 juin 2026, l’éditeur a attribué l’opération à Sapphire Sleet avec un niveau de confiance élevé .

Le scénario de l’attaque, étape par étape

Cette campagne reprend un schéma bien connu des spécialistes de la sécurité : prendre le contrôle d’une identité légitime, puis utiliser la confiance accordée à cette identité pour distribuer une mise à jour empoisonnée.

1. Un compte de mainteneur pris pour cible

Les attaquants ont d’abord employé des techniques d’ingénierie sociale contre un mainteneur légitime de Mastra afin de récupérer les identifiants de son compte npm . Le compte compromis, identifié sous le nom « ehindero », disposait de droits de publication sur l’ensemble du scope @mastra .

2. Une publication massive automatisée

Une fois le compte détourné, les attaquants ont republié les paquets du namespace @mastra/* dans une fenêtre d’environ 88 minutes. Certains rapports situent même le pic de publication en seulement 19 minutes . Une telle cadence laisse penser qu’un script automatisé a été utilisé plutôt qu’une série de mises en ligne manuelles.

3. Une dépendance presque identique à une bibliothèque connue

Chaque version compromise intégrait une dépendance malveillante appelée easy-day-js, un typosquat — autrement dit, un nom volontairement proche — de la bibliothèque de dates légitime et très répandue dayjs . Les chercheurs ont donné à la campagne le nom d’« easy-day-js » .

4. Un déclenchement dès l’installation

Le code malveillant s’exécutait automatiquement grâce au script npm postinstall. Un développeur qui lançait npm install sur un paquet affecté pouvait donc déclencher la charge utile sans avoir à exécuter le moindre code de son application .

La charge utile désactivait également la vérification TLS et téléchargeait un voleur d’informations de deuxième niveau depuis une infrastructure contrôlée par les attaquants .

5. Des identifiants et des actifs numériques visés

Après son exécution, le programme recherchait notamment des clés de portefeuilles de cryptomonnaies, des identifiants cloud et des secrets utilisés par les systèmes d’intégration et de déploiement continus (CI/CD) sur les postes de travail et les environnements de compilation concernés .

Pourquoi Microsoft accuse Sapphire Sleet

Dans une mise à jour publiée le 19 juin 2026, Microsoft a estimé avec un niveau de confiance élevé que l’attaque était imputable à Sapphire Sleet, un acteur nord-coréen qui cible principalement les secteurs financier et des cryptomonnaies. L’éditeur s’est appuyé sur l’infrastructure observée ainsi que sur des tactiques, techniques et procédures (TTP) déjà associées aux opérations du groupe .

Amazon Threat Intelligence a par ailleurs relié Sapphire Sleet à des campagnes antérieures visant des paquets npm comme axios, debug, chalk et typo-crypto .

La réponse de Microsoft : réduire la durée de vie des secrets

L’affaire Mastra intervient alors que Microsoft préparait déjà plusieurs évolutions de sécurité. Ces changements s’attaquent directement à l’un des points faibles exploités dans ce type d’opération : les clés de publication qui restent valides pendant des mois.

Les nouvelles clés NuGet seront limitées à 30 jours

À compter du 17 août 2026, la durée maximale des nouvelles clés API de NuGet.org passe de 365 jours à 30 jours . Toutes les clés créées avant cette date seront désactivées le 1er novembre 2026 .

L’objectif est de réduire la fenêtre d’action offerte par une clé volée. Comme le résume Microsoft, les clés de longue durée sont des « chaînes de caractères faciles à perdre » et constituent un vecteur important de compromission de la chaîne logicielle . Un attaquant qui récupère une telle clé peut publier des paquets piégés pendant une période prolongée, comme dans l’incident Mastra et dans la compromission récente de NX Console .

Trusted Publishing devient l’option recommandée

Microsoft recommande aux mainteneurs de migrer vers Trusted Publishing, un processus lancé en septembre 2025 qui remplace les clés API persistantes par une authentification OpenID Connect (OIDC) de courte durée .

Ses principaux avantages sont les suivants :

• aucun secret de longue durée à conserver dans le dépôt ou les systèmes CI/CD ;
• des identifiants temporaires délivrés pour chaque publication et qui expirent automatiquement, généralement au bout d’environ une heure ;
• une vérification de l’identité du workflow, du dépôt et, si elle est configurée, de l’environnement autorisé ;
• aucune rotation manuelle périodique des secrets ;
• une surface d’impact fortement réduite en cas de divulgation.

Concrètement, un workflow CI/CD utilisant Trusted Publishing demande à son fournisseur — par exemple GitHub Actions — un jeton OIDC signé cryptographiquement. NuGet.org vérifie ce jeton par rapport à la règle de publication enregistrée, puis fournit une clé API temporaire, à usage unique, valable pour la session de publication .

npm et les autres registres évoluent aussi

La réponse de Microsoft s’inscrit dans un mouvement plus large de sécurisation des gestionnaires de paquets :

• Les jetons classiques npm ont été révoqués : npm a définitivement supprimé tous les jetons classiques de longue durée en décembre 2025. La commande npm login fournit désormais des jetons de session valables deux heures .
• Les jetons npm granulaires expirent plus vite : les nouveaux jetons d’accès granulaires autorisant l’écriture ont une durée par défaut de sept jours et une durée maximale de 90 jours .
• La publication par étapes est disponible : généralisée en mai 2026, cette fonction impose à un mainteneur de valider explicitement une version à l’aide d’une authentification à deux facteurs (2FA) avant qu’elle ne soit installable publiquement .

Ensemble, ces mécanismes cherchent à fermer précisément la brèche exploitée par Sapphire Sleet : un seul jeton npm de longue durée, insuffisamment protégé, donnant accès à toute une portée de paquets.

Ce que les développeurs doivent faire maintenant

• Remplacer les clés NuGet existantes : les clés créées avant le 17 août 2026 expireront le 1er novembre. Générez de nouvelles clés ou passez à Trusted Publishing avant cette échéance .
• Privilégier l’authentification OIDC : Trusted Publishing évite de stocker des secrets persistants dans les pipelines CI/CD. La méthode est prise en charge par NuGet.org, npm et PyPI .
• Auditer les workflows de publication npm : vérifiez que vos pipelines utilisent des jetons de session, des jetons granulaires à durée limitée ou Trusted Publishing, selon le cas .
• Verrouiller les versions sensibles : épinglez les versions connues comme sûres et évitez les mises à niveau automatiques tant que les dépendances n’ont pas été vérifiées .
• Désactiver les scripts d’installation lorsque c’est possible : npm install --ignore-scripts, ou la configuration globale ignore-scripts = true, peut empêcher l’exécution de scripts postinstall malveillants .

L’incident Mastra rappelle une règle essentielle de la sécurité open source : une dépendance de confiance peut devenir un point d’entrée critique dès qu’un compte de publication est compromis.