Utilisateurs de npm, préparez-vous à des changements sur l’authentification et la publication.

GitHub vient de faire passer le message. Il entend réduire, « dans un avenir proche », la gamme d’options disponibles. Ne resteront plus que :

• La publication locale avec MFA obligatoire
• Les tokens granulaires avec durée de vie limitée à 7 jours
• Le trusted publishing

Dans ce cadre, les tokens “classiques” (legacy) seront supprimés. Il en ira de même pour le MFA à base de codes TOTP : il faudra utiliser des méthodes FIDO. Quant aux tokens granulaires, ils expireront plus vite s’ils incluent des permissions de publication.

GitHub compte aussi paramétrer la publication de sorte que les tokens ne seront pas autorisés par défaut. Objectif : encourager l’usage de la publication locale avec MFA… ou du trusted publishing. Cette fonctionnalité implémente un standard défini par l’OpenSSF. Elle utilise l’authentification OIDC pour créer une relation de confiance entre npm et les fournisseurs CI/CD (pour le moment, GitHub Actions et les pipelines GitLab, les exécuteurs autohébergés n’étant pas pris en charge). PyPi fut le premier gestionnaire de paquets à l’adopter, en 2023. RubyGems, crates.io et NuGet, entre autres, ont suivi.

npm récemment compromis par un ver

Sur npm, le trusted publishing est intégré depuis juillet 2025. Il était initialement question d’en laisser se développer l’usage sans incitation particulière. Mais le contexte actuel ne le permet pas, affirme GitHub.

Ce contexte, c’est celui d’une recrudescence des attaques sur les registres de paquets logiciels. Illustration avec celle dite Shai-Hulud (du nom d’un ver des sables dans Dune). Elle a ciblé l’écosystème npm.

À l’origine, il y a possiblement une campagne de phishing ayant ciblé les développeurs, invités à “mettre à jour” leurs options de connexion MFA.
Les comptes ainsi compromis ont servi à publier un package contenant un malware. Celui-ci détectait des authentifiants dans l’environnement compromis (tokens npm et GitHub, clés d’API AWS/Azure/GCP) et les exfiltrait… tout en les rendant publics sur le compte GitHub des victimes.
Les tokens npm ainsi dérobés ont permis d’enclencher un processus de propagation automatisée du malware, ainsi apparenté à un ver. Plus de 500 packages auraient été compromis.

À l’heure actuelle, il reste possible, sur npm, de ne pas exiger le MFA pour la publication des paquets et la modification de leurs paramètres. Pour qui l’active, reste la possibilité d’autoriser les tokens, granulaires ou legacy.
Les tokens legacy (aussi dits jetons d’automatisation) permettent de télécharger des paquets et d’en publier. Ils héritent des permissions dont bénéficie l’utilisateur qui les crée.
Les tokens granulaires ont une date d’expiration et peuvent être associés à des organisations. On peut aussi les limiter à certains paquets et à des plages d’adresses IP.

 Illustration générée par IA

The post Face aux compromissions, GitHub durcit la sécurité de npm appeared first on Silicon.fr.

Romain, fidèle lecteur de korben.info a développé un scanner pour détecter l’attaque Shai-Hulud qui a secoué l’écosystème npm dernièrement ! L’occasion parfaite pour moi de vous raconter cette histoire complètement dingue.

Vous vous souvenez de CrowdStrike ? Cette entreprise de cybersécurité qui a provoqué la plus grande panne informatique mondiale en juillet 2024 avec une mise à jour défaillante ? Celle qui a cloué au sol des milliers d’avions et fait planter des millions de PC Windows ? Eh bien figurez-vous qu’en septembre 2025, des packages npm mis à disposition par CrowdStrike ont été touchés. Et si Crowdstrike n’a pas été directement piraté, ces packages publics (qui n’étaient pas utilisés dans leurs solutions de sécurité, ni en interne chez eux) utilisaient ces dépendances qui ont été compromises par l’attaque.

C’est ce qu’on appelle une supply chain attack et l’attaque Shai-Hulud (oui, comme le ver des sables dans Dune) n’est pas juste un malware de plus. C’est le premier ver informatique qui s’est propagé de manière autonome dans l’écosystème npm, infectant des centaines de paquets en quelques heures.

Le ver utilise TruffleHog, un outil de sécurité normalement conçu pour DÉTECTER les secrets dans le code, c’est à dire les tokens GitHub, npm, AWS et GCP.

Puis quand il trouve des credentials valides, le ver fait les trois choses suivantes : D’abord, il crée un dépôt GitHub public nommé “Shai-Hulud” où il balance toutes les données volées. Ensuite, il pousse une GitHub Action malicieuse dans tous les repos accessibles pour exfiltrer encore plus de secrets. Et le pompon c’est que parfois, il transforme même les repos privés d’entreprise en repos publics personnels. J’vous laisse imaginer la tête du RSSI qui découvre que tout le code proprio de sa boîte est accessible à tout le monde sur GitHub…

Et quand le ver trouve des tokens npm dans son environnement, il publie automatiquement des versions infectées de tous les paquets auxquels il a accès. C’est d’ailleurs la première fois qu’on voit ce comportement de ver auto-répliquant dans l’écosystème JavaScript. Par exemple, le paquet @ctrl/tinycolor, téléchargé 2 millions de fois par semaine, a été l’un des premiers touchés.

Face à ce bordel monumental, Romain a donc développé npm-shai-hulud-scanner , un outil qui détecte non seulement les paquets connus comme compromis, mais aussi les tentatives de typosquatting et les patterns de code malicieux. Il utilise notamment la distance de Levenshtein pour identifier les variations suspectes de noms de paquets (du genre lodash vs lodash_ ou react vs raect).

Quand vous le lancez, le scanner de Romain vérifie d’abord si vous avez des paquets de la liste des 500+ compromis. Ensuite il analyse votre code à la recherche de patterns suspects : tentatives d’exfiltration de credentials, exécution de code à distance, obfuscation, communications réseau louches. Il peut même tourner en mode monitoring continu pour surveiller votre CI/CD. Et cerise sur le gâteau, il peut mettre en quarantaine les paquets suspects automatiquement. C’est top non ?

Shai-Hulud est l’un des attaques les plus sévères jamais vue sur la supply chain JavaScript et si même CrowdStrike se fait avoir, je me dit que personne n’est à l’abri. Donc soyez hyper vigilants et utilisez des outils de contrôle comme celui de Romain !

On ne sait jamais !

— 永久链接

— 永久链接

— 永久链接

— 永久链接

— Permalien

— Permalink

— Permalink

L’open source représente aujourd’hui 77 % des applications et sa valeur mondiale excède 12 000 milliards de dollars (environ 11 130 milliards d’euros). Mais cette omniprésence en fait une cible privilégiée pour les attaques sur la chaîne d’approvisionnement, où des acteurs malveillants insèrent du code frauduleux dans des composants de confiance. Les attaques sur la chaîne d’approvisionnement logicielle ciblent principalement

Ça va, pas trop chaud ? Alors tant mieux, parce que je vais vous faire avoir une petite suée tellement ce truc est cool ! Ça s’appelle Memflix et c’est une bibliothèque JavaScript qui transforme vos documents texte en… fichiers vidéo MP4 ! Oui, vous avez bien lu. Et le plus fou, c’est que vous pouvez ensuite faire des recherches sémantiques ultra-rapides dans ces vidéos.

L’idée est tellement simple qu’elle en devient géniale car au lieu de stocker vos données dans une base de données traditionnelle, Memflix encode tout dans des QR codes qui sont ensuite intégrés frame par frame dans une vidéo. Résultat ? Un stockage 10 fois plus efficace qu’une base de données classique et des recherches qui prennent moins d’une seconde, même sur des millions de chunks de texte.