Le 16 juin 2026, des versions malveillantes de nombreux paquets Mastra ont été publiées après la compromission d’un mainteneur. Un script postinstall pouvait exfiltrer des credentials puis s’effacer. Si une version affectée a été installée, supprimer le paquet ne suffit pas : traitez l’hôte comme potentiellement compromis.
Sources de référence : rapport d’incident Mastra et GitHub Advisory Database. Consultez la liste complète des paquets et versions avant toute conclusion.
1. Ne lancez plus npm install
Isolez du réseau les postes, runners CI ou serveurs concernés. Préservez journaux, lockfiles et artefacts pour l’analyse. N’effectuez pas la remédiation depuis une machine suspecte.
2. Rechercher l’exposition
~~~bash npm ls --all npm explain @mastra/core git log -p -- package-lock.json pnpm-lock.yaml yarn.lock ~~~
Cherchez toutes les dépendances @mastra et easy-day-js, directes ou transitives. Comparez les versions au rapport officiel. Vérifiez caches npm, images de conteneur, artefacts CI et dates d’installation.
3. Révoquer et renouveler les secrets
Depuis une machine saine, révoquez clés LLM, tokens npm et GitHub, credentials cloud, base de données, CI/CD, SSH et portefeuilles accessibles. Ne vous contentez pas de modifier un fichier .env : invalidez les anciens secrets chez chaque fournisseur.
4. Reconstruire l’environnement
Pour un hôte ayant exécuté le postinstall, privilégiez une réinstallation ou une reconstruction depuis une image de confiance. Régénérez le lockfile uniquement après avoir sélectionné des versions déclarées sûres. Purgez les caches et reconstruisez toutes les images dérivées.
5. Vérifier
Analysez les connexions sortantes, processus persistants, tâches planifiées, comptes et journaux d’authentification. Surveillez l’usage des anciens secrets et documentez la chronologie. Faites intervenir l’équipe sécurité si des credentials sensibles étaient présents.
Durcir npm
- imposez lockfile et installation reproductible avec npm ci ;
- bloquez les scripts d’installation par défaut lorsque le projet le permet ;
- analysez les changements de dépendances et de scripts ;
- utilisez registry proxy, SBOM, alertes et signatures disponibles ;
- séparez les secrets du build et rendez les runners éphémères ;
- épinglez les versions critiques et révisez les droits des mainteneurs.
FAQ
Une version récente suffit-elle ?
Elle évite de réinstaller une version connue compromise, mais ne nettoie pas un hôte où le code malveillant a déjà tourné.
Pourquoi renouveler les clés LLM ?
Elles faisaient partie des secrets potentiellement accessibles. Considérez-les exposées jusqu’à preuve contraire.