Shai-Hulud : un composant compromis expose les secrets

ChainDrop, une campagne de la famille Shai-Hulud

Le 4 août 2026, des versions malveillantes de paquets npm ont lancé la campagne ChainDrop, rattachée par la Cyber Security Agency of Singapore (CSA) à la famille Shai-Hulud. Son avis du 6 août indique que le malware vole des identifiants de développeurs et peut se propager à d’autres paquets. Microsoft a documenté plus de 400 paquets touchés à cette date ; la CSA recense plus de 1 300 versions compromises. Ces nombres décrivent des paquets et versions, pas le nombre d’installations ou d’organisations effectivement compromises.

Parmi les versions notables listées par la CSA figurent keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6 et cacheable@2.5.1. La liste complète évolue et inclut des dépendances transitives : vérifiez les versions réellement résolues dans les fichiers de verrouillage plutôt que de vous limiter aux dépendances directes. Le déclenchement par script preinstall peut exécuter du code dans le contexte du poste ou du runner qui installe le paquet.

Ce que l’attaquant cherche réellement

Le nom du malware attire l’attention, mais le risque opérationnel est plus simple à comprendre : une dépendance compromise observe l’environnement auquel elle a accès.

Cela peut inclure :

• des tokens GitHub ou GitLab présents dans les variables d’environnement ;
• des clés API conservées dans un fichier local ou un terminal ;
• des identifiants cloud, SSH, Terraform ou Kubernetes ;
• des secrets CI/CD réutilisables depuis un runner trop permissif ;
• des fichiers de configuration ou des sessions déjà ouvertes.

Un secret oublié dans un .env, un script shell ou une variable de pipeline n’est donc pas « seulement local ». Dès qu’un outil tiers s’exécute avec les mêmes droits, il peut devenir un pont vers l’organisation.

La réponse immédiate pour une petite équipe

Si une version potentiellement touchée a été installée, la priorité est de traiter la machine et le pipeline comme suspects. La CSA et Microsoft recommandent d’identifier et supprimer les versions concernées, de reconstruire les systèmes affectés, de faire tourner les identifiants exposés et de rechercher les accès ou changements inhabituels.

Une séquence praticable tient en cinq temps :

1. Stopper la propagation. Mettez en pause les déploiements et installations automatisées liés au projet concerné.
2. Vérifier l’inventaire. Cherchez les paquets et versions dans les lockfiles, caches, postes de développement, runners et artefacts.
3. Isoler puis reconstruire. Ne réutilisez pas un runner ou un poste potentiellement contaminé comme base de confiance ; repartez d’une image saine.
4. Révoquer et remplacer. Faites tourner les tokens, clés API, clés SSH et secrets cloud accessibles depuis les environnements concernés. Un nouveau secret ne suffit pas si l’ancien reste valide.
5. Contrôler les traces. Examinez les connexions, publications de paquets, modifications de workflows et changements de permissions depuis la première installation suspecte.

La rotation doit être hiérarchisée : commencez par les comptes d’administration, les clés permettant de publier du code et les identifiants donnant accès aux données ou à la production. Documentez qui a tourné quoi, quand et où le nouveau secret est stocké.

Trois catégories de secrets à ne pas mélanger

Un coffre de mots de passe sert surtout aux secrets humains : comptes SaaS, accès partagés, codes de récupération ou informations d’administration. Il doit offrir des secrets uniques, un partage contrôlé et une récupération maîtrisée.

Les secrets machine — tokens d’API, clés SSH, credentials cloud — doivent être limités dans le temps, dans leur périmètre et dans leur usage. Ils ne devraient pas être copiés dans un document partagé simplement parce qu’une équipe n’a pas encore formalisé son processus.

Enfin, les secrets CI/CD doivent être injectés par les mécanismes prévus par la plateforme. Préférez des identités dédiées, courtes et peu privilégiées ; isolez les runners et auditez les workflows sensibles. Soclyde ne remplace pas un secret manager CI/CD : son rôle est de réduire les copies et les partages risqués autour des secrets humains, avec un coffre chiffré local-first.

Réduire la surface d’attaque avant le prochain incident

Les analyses de Microsoft et d’Elastic complètent la réponse d’urgence par des garde-fous adaptés à cette campagne : examiner les lockfiles, les caches et les artefacts de build, épingler des versions reconnues comme saines, et introduire un délai avant d’adopter une nouvelle version. La provenance seule n’est pas une garantie : Microsoft relève que certaines publications malveillantes pouvaient utiliser des flux de publication légitimes.

Pour une petite équipe, cela peut devenir une checklist mensuelle :

• conserver et relire les lockfiles dans les changements de dépendances ;
• utiliser npm ci ou l’équivalent reproductible en CI ;
• appliquer une période de refroidissement aux versions fraîchement publiées ;
• exécuter les installations dans un runner éphémère et restreint en sortie réseau ;
• inventorier les tokens, leur propriétaire, leur portée et leur date d’expiration ;
• protéger les branches et examiner les workflows qui disposent de secrets ;
• stocker les mots de passe humains dans un coffre chiffré et éviter les copies dans les tickets, tableurs ou messages.

Le but n’est pas de rendre l’équipe méfiante de chaque paquet. Il est de faire en sorte qu’un paquet compromis ne trouve ni un token permanent, ni un runner réutilisable, ni une collection de secrets copiés partout.

Le lien avec Soclyde

Soclyde ne détecte pas les paquets npm malveillants et ne remplace ni un gestionnaire de secrets machine ni les mécanismes de secrets de la CI/CD. Le coffre local-first concerne surtout les mots de passe humains et les accès partagés ; il ne doit pas devenir un endroit où copier des tokens de pipeline ou des clés API.

Pour revoir l’architecture et les limites d’un coffre local-first, consultez le guide Soclyde sur les gestionnaires de mots de passe local-first.

À retenir

Après l’installation d’une version compromise, supprimer le paquet ne suffit pas : isolez et reconstruisez l’environnement, révoquez les identifiants qui lui étaient accessibles et vérifiez les dépôts, publications et artefacts produits. La liste CSA des versions notables et les analyses de Microsoft et Elastic aident à cadrer ces vérifications.

Pour organiser ces accès partagés avec des règles de transmission et de révocation, consultez aussi le guide de partage sécurisé des mots de passe en équipe.

Pour discuter de la gestion des mots de passe humains, vous pouvez également contacter Soclyde.