Un compte de contributeur oublié a compromis tout le périmètre de packages npm Mastra

Le 17 juin 2026, un attaquant a republié l’intégralité du périmètre npm @mastra, en glissant une dépendance malveillante dans 143 packages et ce nombre continue d’augmenter, dont @mastra/core, qui totalise environ 4 millions de téléchargements par mois et compte des centaines de projets dépendants. La dépendance injectée, easy-day-js, est un clone de dayjs dont le hook d’installation désactive la vérification TLS, télécharge une charge utile de deuxième étape depuis une adresse IP brute et exécute en arrière-plan un voleur de cryptomonnaie multiplateforme. Cette attaque visant un package npm a été rendue possible par un ancien compte de contributeur dont les droits d’accès au périmètre n’avaient jamais été révoqués.

Action requise : si vous avez installé un package @mastra, ou tout package qui en dépend, dans un nouvel arbre de dépendances ou un arbre mis à jour le 17 juin 2026 ou après, considérez qu’il s’agit d’une exposition de vos identifiants et portefeuilles et poursuivez votre lecture.

MISE À JOUR : Snyk a ajouté un nouveau package compromis, @mastra/node-speaker, version 0.1.1.

En bref

• Incident : prise de contrôle du périmètre npm @mastra, avec republication massive et injection d’une dépendance malveillante

• Dépendance malveillante : easy-day-js@1.11.22 (un imposteur de dayjs servant de dropper)

• Avis Snyk : SNYK-JS-EASYDAYJS-17353313, code malveillant intégré, affecte easy-day-js 1.11.21 et 1.11.22

• Packages affectés : pratiquement tout le périmètre @mastra, republié le 17 juin 2026 ; les mesures correctives de Mastra couvrent 142 packages publiables

• Versions notables : @mastra/core@1.42.1, mastra@1.13.1, create-mastra@1.13.1

• CVE / CVSS : aucun identifiant attribué ; il s’agit d’un incident actif touchant la chaîne d’approvisionnement, et le code source de Mastra lui-même n’a pas été modifié

• Charge utile : voleur de portefeuilles de cryptomonnaie multiplateforme et cheval de Troie d’accès à distance avec persistance

• Statut : easy-day-js a été retiré de npm, ehindero n’est plus propriétaire du périmètre, et Mastra a publié des versions correctives plus récentes (PR #18056). La dernière version de @mastra/core latest est revenue à une version saine, 1.42.0. Considérez toute version compromise que vous avez déjà résolue comme un incident d’exposition de l’hôte.

Déroulement de l’attaque

Le point d’entrée était un identifiant de mainteneur obsolète. Le périmètre @mastra était publié depuis le compte npm ehindero, appartenant à un ancien contributeur réel de Mastra. L’historique de publication du registre npm recense des versions alpha légitimes de @mastra/core publiées depuis ce compte fin 2024 et début 2025, puis celui-ci est devenu inactif. Ses droits d’accès au périmètre n’ont jamais été révoqués.

Le compte présente des signes de prise de contrôle plutôt que d’action interne, notamment une modification de l’adresse e-mail, qui ne correspond plus à l’adresse d’origine du contributeur et a été remplacée par ehindero2016@tutamail[.]com. Les mécanismes en jeu méritent qu’on s’y attarde : npm n’expire pas les autorisations de publication dans un périmètre en cas d’inactivité. Un seul identifiant de mainteneur obsolète a donc suffi pour publier dans tous les packages du périmètre. La cause première est un manque d’hygiène du projet, pas une vulnérabilité zero-day.

Le vecteur : une ligne dans chaque package.json

L’attaquant n’a pas touché au code source de Mastra. Le code malveillant a été injecté dans les archives publiées au moment de la publication, et la PR de correction de Mastra confirme que le dépôt a été vérifié et ne contient aucune trace de easy-day-js dans les fichiers package.json ni les fichiers de verrouillage (PR #18056). Chaque version malveillante publiée sur npm ajoutait exactement une ligne au fichier package.json publié :

"easy-day-js": "^1.11.21"

Cette dépendance n’est importée nulle part dans le code source de Mastra. Elle sert uniquement à installer un cheval de Troie. L’astuce réside dans la plage avec caret. Le 16 juin, l’attaquant a d’abord publié une version saine, easy-day-js@1.11.21, un clone de dayjs identique octet pour octet, jusque dans le fichier dayjs.min.js intégré et la description du package. Le lendemain, il a publié easy-day-js@1.11.22 avec le malware et lui a attribué le tag latest. Comme 1.11.22 satisfait la plage ^1.11.21, une commande npm install classique sélectionne directement la version piégée.

Puis, le 17 juin 2026, l’attaquant a republié le reste du périmètre en une seule opération, avec la même dépendance injectée dans chaque package. Les mesures correctives de Mastra recensent précisément l’ampleur de l’attaque : son changeset d’urgence publie des versions correctives pour 142 packages publiables du périmètre @mastra/*, ainsi que mastra, create-mastra et mastracode (PR #18056). Selon les instantanés, les informations publiques font état de 80 à 144 packages, mais le chiffre du fournisseur lui-même est la référence à retenir. Dans tous les cas, le constat est le même : pratiquement tout le périmètre a été touché.

Pour quelques packages, l’attaquant a même publié des versions supérieures à la version légitime latest (par exemple, @mastra/schema-compat@1.2.12, @mastra/react@1.0.1, @mastra/voice-playai@0.12.2). Mastra a ensuite dû définir explicitement des versions supérieures au lieu d’effectuer de simples mises à jour de correctifs pour les remplacer (PR #18060).

Le dropper du malware : désactivation TLS, téléchargement, détachement, suppression

easy-day-js@1.11.22 contient un fichier setup.cjs exécuté par le hook postinstall. Lors de l’installation, il :

1. Désactive la validation des certificats TLS en définissant NODE_TLS_REJECT_UNAUTHORIZED='0', ce qui permet à une requête HTTPS d’aboutir auprès d’une adresse IP brute dotée d’un certificat autosigné.

2. Écrit des fichiers marqueurs (~/.pkg_history, ~/.pkg_logs) pour suivre les installations.

3. Télécharge une charge utile de deuxième étape depuis https://23.254.164[.]92:8000/update/49890878 (hébergé par Hostwinds).

4. L’écrit dans le répertoire temporaire et le lance en arrière-plan, en processus détaché et masqué, sans sortie console.

5. Se supprime lui-même afin de réduire les traces forensiques.

La charge utile : un voleur de cryptomonnaie et un RAT multiplateformes

La deuxième étape (SHA256 221c45a790dec2a296af57969e1165a16f8f49733aeab64c0bbd768d9943badf) est un voleur de portefeuilles de cryptomonnaie obfusqué, de la même catégorie que les charges utiles suivies par Snyk lors de précédentes compromissions npm. Il examine les profils Chrome, Brave et Edge à la recherche d’une liste codée en dur d’extensions de navigateur pour portefeuilles de cryptomonnaie, notamment MetaMask, Phantom, Solflare, Coinbase Wallet, OKX et Keplr. En plus des données des portefeuilles, il collecte le nom d’utilisateur, le nom d’hôte, le système d’exploitation et l’architecture, la version de Node, les applications installées, l’historique du navigateur et la liste des processus en cours d’exécution, puis encode le tout en base64 dans une balise JSON.

Il assure également sa persistance en se faisant passer pour un outil Node et en envoyant un signal à un serveur C2 distinct du RAT (23.254.164[.]123/49890878) environ toutes les 10 minutes, au moyen d’un certificat de test wolfSSL autosigné (CN=www.wolfssl.com, expiré en janvier 2018) :

• macOS : LaunchAgent à l’emplacement ~/Library/LaunchAgents/com.nvm.protocal.plist

• Linux : service utilisateur systemd ~/.config/systemd/user/nvmconf.service

• Windows : exécution PowerShell préparée dans C:\ProgramData\NodePackages

La dépendance d’abord saine, puis piégée, le dropper d’installation setup, le téléchargement depuis une IP brute avec contournement TLS et la charge utile de vol de cryptomonnaie ressemblent fortement à la compromission npm d’Axios analysée par Snyk plus tôt en 2026, jusque dans le dropper d’installation qui s’autodétruit. Microsoft Threat Intelligence a attribué cette campagne antérieure à l’acteur qu’il suit sous le nom de Sapphire Sleet (BlueNoroff). L’attribution de cet incident précis n’est pas confirmée ; nous n’irons donc pas plus loin dans les spéculations. Ce schéma mérite l’attention des équipes de défense, mais ne doit pas être présenté comme un fait avéré.

Analyse de l’impact

À lui seul, @mastra/core totalise environ 4 millions de téléchargements par mois (registre npm) et compte des centaines de projets dépendants ; mastra en ajoute environ 1,5 million (registre npm). Avec 142 packages republiés dans le périmètre, le volume cumulé de téléchargements mensuels se chiffre en dizaines de millions. L’ampleur potentielle de l’attaque est donc importante.

L’exposition réelle est plus limitée que ne le laisse penser ce chiffre, et il est important d’être précis. Vous êtes exposé uniquement si une machine de développement ou de build a résolu l’une des versions malveillantes pendant la période concernée. Dans les projets npm, les fichiers de verrouillage sont déterminants et constituent la méthode sûre et reproductible pour gérer les dépendances :

• Verrouillée sur une version antérieure à l’incident par un fichier de verrouillage commité : npm ci n’aurait pas installé la version malveillante. Vous êtes probablement à l’abri, mais vérifiez.

• Absence de fichier de verrouillage, plage de versions souple, nouvelle installation ou régénération du fichier de verrouillage le 17 juin ou après : la plage avec caret aurait sélectionné easy-day-js@1.11.22, la version piégée, et le hook postinstall aurait été exécuté.

La charge utile s’exécutant au moment de l’installation, les exécuteurs CI, les agents de build éphémères et les ordinateurs portables des développeurs sont tous concernés, et pas uniquement les serveurs de production. Les identifiants et portefeuilles de ces hôtes pourraient avoir été dérobés.

Détection : êtes-vous exposé ?

1. Vérifiez si easy-day-js a déjà figuré dans votre arbre de dépendances. Sa présence n’est jamais légitime :

npm ls easy-day-js

grep -r "easy-day-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

2. Vérifiez les @mastra versions que vous avez résolues. Les versions compromises ont été publiées le 17 juin 2026 et ne disposent pas de provenance SLSA. Vérifiez les versions réellement verrouillées dans votre fichier :

npm ls @mastra/core mastra create-mastra

3. Lancez une analyse avec Snyk. Snyk signale le package malveillant sous l’identifiant SNYK-JS-EASYDAYJS-17353313 (code malveillant intégré) :

snyk test

snyk monitor

4. Recherchez des traces sur les hôtes de toute machine ayant exécuté une installation pendant la période concernée :

#Dropper markers

ls -la ~/.pkg_history ~/.pkg_logs 2>/dev/null

#Persistence

ls -la ~/Library/LaunchAgents/com.nvm.protocal.plist 2>/dev/null      # macOS

ls -la ~/.config/systemd/user/nvmconf.service 2>/dev/null             # Linux

dir "C:\ProgramData\NodePackages"                                      # Windows

5. Consultez les journaux de trafic sortant pour repérer les connexions à 23.254.164[.]92:8000, 23.254.164[.]123 ou toute adresse du bloc 23.254.164.0/24.

Pour découvrir concrètement comment détecter et corriger avec Snyk une compromission npm de ce type touchant tout un périmètre, cette démonstration présente le processus de bout en bout :

Play Video: Shai-Hulud NPM Attack: Remediation with Snyk

Attaque NPM Shai-Hulud : correction avec Snyk (un processus pratique de correction d’une attaque de chaîne d’approvisionnement npm par republication massive).

Correction

Si easy-day-js est absent et que votre fichier de verrouillage fixe des versions @mastra antérieures à l’incident : confirmez-le à l’aide des étapes de détection ci-dessus, conservez les versions verrouillées et poursuivez vos activités.

Si vous avez résolu une version malveillante, considérez tout hôte concerné comme compromis.

1. Passez à une version saine ; ne vous contentez pas de revenir à une version antérieure. Mastra a publié des versions correctives plus récentes pour ses 142 packages publiables et déplacé le tag de distribution latest au-delà des versions compromises (PR #18056, PR #18049), plutôt que de compter sur leur dépublication. Passez à la version saine actuelle (par exemple, @mastra/core@1.42.0 ou une version ultérieure), régénérez un fichier de verrouillage sain et supprimez toute trace de easy-day-js. Comme l’attaquant a publié certaines versions supérieures à la version légitime latest, vérifiez bien que la version choisie est une version Mastra reconnue comme saine et non une version de l’attaquant qui serait restée en circulation.

2. Faites tourner tous les identifiants auxquels l’hôte pouvait accéder : clés cloud, secrets et jetons CI, clés d’API LLM et autres, jetons npm et clés SSH. Mastra étant un framework d’agents, les clés des fournisseurs LLM sont particulièrement susceptibles d’être présentes.

3. Transférez les portefeuilles de cryptomonnaie : si le profil d’un navigateur sur la machine contenait une extension de portefeuille ciblée, considérez que la phrase de récupération et les clés sont exposées et transférez les fonds vers un nouveau portefeuille depuis un appareil sain.

4. Supprimez les mécanismes de persistance : supprimez le LaunchAgent, l’unité systemd ou les fichiers préparés dans C:\ProgramData\NodePackages, arrêtez le processus détaché et effacez les marqueurs laissés par le dropper.

5. Réinstallez le système si possible. En présence d’un RAT doté d’un mécanisme de persistance établi, une réinstallation complète est l’option la plus sûre.

Pour réduire votre exposition à ce type d’attaque à l’avenir :

• Désactivez les scripts d’installation par défaut avec npm config set ignore-scripts true, et autorisez-les uniquement lorsque la compilation en a réellement besoin. Cela neutralise les programmes malveillants postinstall et fait partie des bonnes pratiques de sécurité npm de Snyk.

• Validez les fichiers de verrouillage et utilisez npm ci dans votre pipeline CI afin de garantir la reproductibilité des compilations et d’empêcher qu’une balise latest modifiée ne déclenche une nouvelle résolution silencieuse des dépendances.

• Exigez la provenance. Mastra générait des attestations de provenance SLSA lors des publications par CI, mais celles-ci n’étaient pas obligatoires : un simple jeton pouvait donc toujours permettre une publication sans attestation. La même faille a permis la diffusion de versions malveillantes lors de la compromission du package Nx ; exiger la provenance lors de la consommation des packages renforce la sécurité.

• Surveillez les dépendances fantômes. Lorsqu’un package mature et largement utilisé se retrouve soudainement avec une seule dépendance inutilisée, c’est précisément le signal observé ici. La priorisation des risques et la découverte des actifs dans votre environnement vous aident à déterminer où un package affecté a été installé, ainsi que les instances qui sont accessibles et détiennent des identifiants. Vous pouvez ainsi corriger en priorité les hôtes exposés, au lieu de passer en revue toutes les installations du scope une par une.

Articles Snyk associés

Il s’agit du dernier d’une série de détournements de scopes npm et de comptes de mainteneurs en 2026. Le scénario — un compte de mainteneur compromis utilisé pour republier rapidement des packages de façon automatisée — est le même que celui des campagnes Mini Shai-Hulud :

Play Video: Mini Shai-Hulud: The Most Sophisticated NPM Supply Chain Attack of 2026

Mini Shai-Hulud : l’attaque de la chaîne logistique npm la plus sophistiquée de 2026 (une analyse détaillée de la façon dont un seul compte de mainteneur compromis peut servir à introduire un cheval de Troie dans des centaines de packages npm à la fois, et des moyens de détecter et de corriger l’exposition).

Pour en savoir plus sur cette même famille d’attaques et les mesures de défense, consultez les articles de Snyk sur la compromission d’Axios sur npm, l’attaque Mini Shai-Hulud contre AntV et celle contre TanStack, le ver à propagation automatique node-gyp et les compromissions de tinycolor et ngx-bootstrap. Pour découvrir comment renforcer votre pipeline d’installation, consultez Sécurité npm : prévenir les attaques de la chaîne logistique, ainsi que la leçon Snyk Learn sur la compromission d’un package légitime.

Chronologie

• De fin 2024 à début 2025 : le compte ehindero publie des versions alpha légitimes de @mastra/core, puis devient inactif. L’accès au scope n’est jamais révoqué.

• 16 juin 2026 : une version saine de easy-day-js@1.11.21 est publiée pour servir de couverture, en usurpant l’identité de dayjs.

• 17 juin 2026, vers 01:01 UTC : la version malveillante easy-day-js@1.11.22 est publiée et reçoit la balise latest.

• 17 juin 2026, vers 01:12–02:36 UTC : la majeure partie du scope @mastra/* est republiée avec la dépendance easy-day-js injectée.

• 17 juin 2026 : plusieurs fournisseurs de solutions de sécurité divulguent publiquement l’incident ; easy-day-js est retiré de npm et les versions malveillantes sont signalées (avis Snyk SNYK-JS-EASYDAYJS-17353313).

• 17 juin 2026 (le jour même) : Mastra réagit en supprimant le propriétaire non autorisé, en ouvrant des changesets d’urgence pour publier des versions saines (PR #18049), en publiant de nouvelles versions des 142 packages publiables (PR #18056) et en épinglant des versions supérieures explicites lorsque l’attaquant avait publié au-delà de latest (PR #18060).