Le CTO de Ledger, Charles Guillemet, a rapporté sur X une attaque de chaîne d'approvisionnement impliquant des packages NPM largement utilisés.
Une attaque de chaîne d'approvisionnement à grande échelle est en cours : le compte NPM d'un développeur réputé a été compromis. Les packages affectés ont déjà été téléchargés plus d'un milliard de fois, ce qui signifie que tout l'écosystème JavaScript pourrait être en danger.
Le payload malveillant fonctionne…
— Charles Guillemet (@P3b7_) 8 septembre 2025
Selon un rapport de CoinDesk, certaines versions compromises – totalisant plus de 1 milliard de téléchargements – incluent un code capable de remplacer, "à la volée", les adresses de destination dans les transactions crypto, redirigeant des fonds vers des portefeuilles contrôlés par des attaquants. Ce scénario s'aligne sur les recommandations de protection de la chaîne d'approvisionnement publiées par des organisations de l'industrie comme OWASP, qui soulignent comment les compromissions de la chaîne d'approvisionnement peuvent avoir des impacts à grande échelle.
Selon les données collectées par notre équipe de renseignement sur les menaces au cours des dernières 24 heures, des indicateurs de compromission ont émergé, cohérents avec la technique décrite dans plusieurs dépôts et pipelines de construction. Les analystes avec lesquels nous collaborons soulignent également que l'ampleur de l'incident est amplifiée par des dépendances transitives et la taille du registre : le registre NPM héberge plus de 2 millions de paquets, augmentant la probabilité de propagation d'un module compromis.
Mécanisme d'attaque : Adresses changées "à la volée"
Cela dit, la charge utile malveillante s'active à la fois lors des opérations sur la chaîne et au moment de la génération ou de la signature de la transaction. En pratique, le logiciel malveillant intercepte l'adresse du destinataire et la remplace par une appartenant aux acteurs malveillants. L'utilisateur, voyant un écran apparemment « propre », pourrait ne pas réaliser que la transaction finale envoie les fonds à une adresse différente – une dynamique également confirmée par The Block. Il convient de noter que la manipulation vise à rester invisible jusqu'à la dernière étape de confirmation.
Mise à jour sur l'attaque NPM : L'attaque a heureusement échoué, avec presque aucune victime.
Cela a commencé par un email de phishing provenant d'un faux domaine de support npm qui a volé des identifiants et a permis aux attaquants d'accéder à la publication de mises à jour de paquets malveillants. Le code injecté ciblait l'activité de cryptographie web,… pic.twitter.com/lOik6k7Dkp
— Charles Guillemet (@P3b7_) 9 septembre 2025
Paquets impliqués : numéros, noms provisoires et distribution
Les analyses initiales indiquent que le compromis s'est produit en exploitant le compte d'un mainteneur ayant accès à des bibliothèques largement utilisées. Parmi les noms qui circulent figure, par exemple, le package error-ex – dont le profil officiel peut être consulté sur npmjs.com – bien que les listes officielles soient encore en cours de mise à jour. L'impact est amplifié par l'effet de cascade dû aux dépendances : un seul module compromis peut se propager à des centaines de projets, grâce aux chaînes d'importation. En effet, la nature modulaire du code JavaScript facilite la propagation du problème lorsque les dépendances sont profondément imbriquées.
Échelle d'exposition : plus de 1 milliard de téléchargements cumulés de versions potentiellement à risque.
Vector : publications sur NPM via des identifiants volés ou un pipeline compromis.
Portée : bibliothèques principales utilisées dans les projets web et les portefeuilles.
Les listes officielles des paquets et versions affectés sont partielles ; il est conseillé de surveiller les avis NPM et les dépôts des mainteneurs. Cependant, jusqu'à ce que des communications définitives soient faites, il reste prudent de considérer l'ensemble de la chaîne de dépendance comme étant à risque.
Impact sur les utilisateurs et les entreprises
Vol direct de crypto après le remplacement furtif de l'adresse.
Intégrité de l'application compromise dans les dApps, les extensions et les portefeuilles de bureau/web.
Risque réputationnel pour les projets qui intègrent des packages contaminés.
Que faire immédiatement : liste de contrôle d'urgence
Pour les utilisateurs finaux (crypto)
Privilégiez les portefeuilles qui affichent clairement les informations de transaction (écran et signature claire – Signature claire ), vérifiant l'adresse et le montant sur l'appareil avant de confirmer. Pour des conseils pratiques, consultez notre guide sur la vérification des portefeuilles matériels.
Évitez la signature aveugle et limitez l'utilisation de codes QR non vérifiés.
Comparez l'adresse affichée avec une copie sécurisée et utilisez des listes blanches pour les destinataires fréquents.
Cette précaution est cruciale car la confirmation sur un portefeuille matériel montre les données qui sont réellement signées, rendant toute substitution d'adresse par le logiciel hôte évidente. Dans ce contexte, la vérification sur l'écran de l'appareil réduit la probabilité d'erreur ou de manipulation en amont.
Pour les équipes de développement
Suspendre temporairement les mises à jour automatiques des dépendances critiques.
Effectuer l'audit et le retour en arrière des versions publiées pendant la période suspecte.
Faites tourner les jetons NPM et rendez l'activation de la 2FA obligatoire pour les mainteneurs et les émetteurs (voir ici).
Activer des systèmes de provenance pour les publications et signer les artefacts de construction.
Comment vérifier si un projet est exposé
Identifier rapidement les dépendances suspectes et les plages de versions installées est crucial : une reconnaissance rapide limite l'effet domino dans les pipelines.
Liste des versions installées et de la chaîne de dépendance
npm ls error-ex
Vérifier les vulnérabilités et avis connus
npm audit –production
npm audit –json > audit.json
Bloquer les mises à jour non déterministes dans CI
npm ci –ignore-scripts
Fixer un seuil d'audit plus strict
npm config set audit-level=high
Vérifiez les versions disponibles et les dates de publication
npm view error-ex versions –json
npm view error-ex time –json
Dans les contextes CI, définir ignore-scripts=true aide à réduire le risque d'exécution de scripts post-installation malveillants. Cela dit, il est conseillé d'établir dès le départ une base reproductible pour éviter des écarts inattendus. Pour une liste de contrôle étendue sur les vérifications CI, référez-vous à notre page sur les meilleures pratiques de la chaîne d'approvisionnement.
Renforcer la chaîne d'approvisionnement : défenses techniques recommandées
Utilisez un fichier de verrouillage déterministe (package-lock.json) et déployez avec npm ci pour garantir la reproductibilité.
Activez la 2FA sur NPM pour les publications et l'accès critique, en utilisant des tokens avec des portées limitées (automation vs. publish).
Implémentez une révision de code obligatoire et utilisez un pipeline CI isolé avec signature des artefacts.
Adoptez des systèmes de provenance, en vous référant à la documentation officielle sur la provenance des packages npm et aux normes comme SLSA.
Utilisez des outils de scan et des mises à jour contrôlées, telles que Dependabot, Renovate et sigstore/cosign, le cas échéant.
Appliquez le principe du moindre privilège pour les comptes des mainteneurs et des bots de publication.
Chronologie et statut des enquêtes
L'alerte a été rendue publique aujourd'hui, le 8 septembre 2025, et des vérifications sont actuellement en cours. Des avis officiels et des listes mises à jour des packages et versions compromis seront publiés progressivement. Par conséquent, il est conseillé de rester prudent, en suspendant les mises à jour non essentielles jusqu'à ce que les indicateurs de compromission soient consolidés. Dans l'attente de nouveaux retours, la priorité reste de contenir l'exposition et de documenter soigneusement chaque changement.
Angle Critique : Une Chaîne de Confiance Encore Fragile
La chaîne d'approvisionnement open source reste vulnérable lorsque l'accès aux comptes et les pipelines de publication ne sont pas suffisamment protégés. Le problème devient particulièrement pressant lorsque, en 2025, de nombreuses publications continuent d'avoir lieu sans l'adoption systématique de mesures telles que l'authentification à deux facteurs, la provenance et des examens rigoureux.
Tant que la confiance est considérée comme acquise, chaque projet continuera d'être exposé au risque généré par les autres. Pourtant, même de petites améliorations dans les processus peuvent réduire considérablement la surface d'attaque.
Le Point
Cet épisode met en avant l'importance cruciale de la sécurité de la chaîne d'approvisionnement dans les logiciels open source. Tant que les enquêtes se poursuivent, la priorité sera de limiter les surfaces d'attaque, de vérifier soigneusement les données de transaction à l'écran et de consolider les processus de publication grâce à l'adoption de l'authentification à deux facteurs (2FA), des fichiers de verrouillage et des systèmes de provenance.
La transparence des avis, comme l'ont souligné de nombreux experts, sera cruciale pour mesurer l'impact réel et restaurer la confiance dans l'écosystème. Dans ce contexte, le respect des meilleures pratiques reste le seul garde-fou immédiat.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
NPM sous attaque : packages JavaScript compromis, adresses crypto détournées. Avertissement de Ledger...
Le CTO de Ledger, Charles Guillemet, a rapporté sur X une attaque de chaîne d'approvisionnement impliquant des packages NPM largement utilisés.
Une attaque de chaîne d'approvisionnement à grande échelle est en cours : le compte NPM d'un développeur réputé a été compromis. Les packages affectés ont déjà été téléchargés plus d'un milliard de fois, ce qui signifie que tout l'écosystème JavaScript pourrait être en danger.
Le payload malveillant fonctionne…
— Charles Guillemet (@P3b7_) 8 septembre 2025
Selon un rapport de CoinDesk, certaines versions compromises – totalisant plus de 1 milliard de téléchargements – incluent un code capable de remplacer, "à la volée", les adresses de destination dans les transactions crypto, redirigeant des fonds vers des portefeuilles contrôlés par des attaquants. Ce scénario s'aligne sur les recommandations de protection de la chaîne d'approvisionnement publiées par des organisations de l'industrie comme OWASP, qui soulignent comment les compromissions de la chaîne d'approvisionnement peuvent avoir des impacts à grande échelle.
Selon les données collectées par notre équipe de renseignement sur les menaces au cours des dernières 24 heures, des indicateurs de compromission ont émergé, cohérents avec la technique décrite dans plusieurs dépôts et pipelines de construction. Les analystes avec lesquels nous collaborons soulignent également que l'ampleur de l'incident est amplifiée par des dépendances transitives et la taille du registre : le registre NPM héberge plus de 2 millions de paquets, augmentant la probabilité de propagation d'un module compromis.
Mécanisme d'attaque : Adresses changées "à la volée"
Cela dit, la charge utile malveillante s'active à la fois lors des opérations sur la chaîne et au moment de la génération ou de la signature de la transaction. En pratique, le logiciel malveillant intercepte l'adresse du destinataire et la remplace par une appartenant aux acteurs malveillants. L'utilisateur, voyant un écran apparemment « propre », pourrait ne pas réaliser que la transaction finale envoie les fonds à une adresse différente – une dynamique également confirmée par The Block. Il convient de noter que la manipulation vise à rester invisible jusqu'à la dernière étape de confirmation.
Mise à jour sur l'attaque NPM : L'attaque a heureusement échoué, avec presque aucune victime.
Cela a commencé par un email de phishing provenant d'un faux domaine de support npm qui a volé des identifiants et a permis aux attaquants d'accéder à la publication de mises à jour de paquets malveillants. Le code injecté ciblait l'activité de cryptographie web,… pic.twitter.com/lOik6k7Dkp
— Charles Guillemet (@P3b7_) 9 septembre 2025
Paquets impliqués : numéros, noms provisoires et distribution
Les analyses initiales indiquent que le compromis s'est produit en exploitant le compte d'un mainteneur ayant accès à des bibliothèques largement utilisées. Parmi les noms qui circulent figure, par exemple, le package error-ex – dont le profil officiel peut être consulté sur npmjs.com – bien que les listes officielles soient encore en cours de mise à jour. L'impact est amplifié par l'effet de cascade dû aux dépendances : un seul module compromis peut se propager à des centaines de projets, grâce aux chaînes d'importation. En effet, la nature modulaire du code JavaScript facilite la propagation du problème lorsque les dépendances sont profondément imbriquées.
Échelle d'exposition : plus de 1 milliard de téléchargements cumulés de versions potentiellement à risque.
Vector : publications sur NPM via des identifiants volés ou un pipeline compromis.
Portée : bibliothèques principales utilisées dans les projets web et les portefeuilles.
Les listes officielles des paquets et versions affectés sont partielles ; il est conseillé de surveiller les avis NPM et les dépôts des mainteneurs. Cependant, jusqu'à ce que des communications définitives soient faites, il reste prudent de considérer l'ensemble de la chaîne de dépendance comme étant à risque.
Impact sur les utilisateurs et les entreprises
Vol direct de crypto après le remplacement furtif de l'adresse.
Intégrité de l'application compromise dans les dApps, les extensions et les portefeuilles de bureau/web.
Risque réputationnel pour les projets qui intègrent des packages contaminés.
Que faire immédiatement : liste de contrôle d'urgence
Pour les utilisateurs finaux (crypto)
Privilégiez les portefeuilles qui affichent clairement les informations de transaction (écran et signature claire – Signature claire ), vérifiant l'adresse et le montant sur l'appareil avant de confirmer. Pour des conseils pratiques, consultez notre guide sur la vérification des portefeuilles matériels.
Évitez la signature aveugle et limitez l'utilisation de codes QR non vérifiés.
Comparez l'adresse affichée avec une copie sécurisée et utilisez des listes blanches pour les destinataires fréquents.
Cette précaution est cruciale car la confirmation sur un portefeuille matériel montre les données qui sont réellement signées, rendant toute substitution d'adresse par le logiciel hôte évidente. Dans ce contexte, la vérification sur l'écran de l'appareil réduit la probabilité d'erreur ou de manipulation en amont.
Pour les équipes de développement
Suspendre temporairement les mises à jour automatiques des dépendances critiques.
Effectuer l'audit et le retour en arrière des versions publiées pendant la période suspecte.
Faites tourner les jetons NPM et rendez l'activation de la 2FA obligatoire pour les mainteneurs et les émetteurs (voir ici).
Activer des systèmes de provenance pour les publications et signer les artefacts de construction.
Comment vérifier si un projet est exposé
Identifier rapidement les dépendances suspectes et les plages de versions installées est crucial : une reconnaissance rapide limite l'effet domino dans les pipelines.
Liste des versions installées et de la chaîne de dépendance
npm ls error-ex
Vérifier les vulnérabilités et avis connus
npm audit –production
npm audit –json > audit.json
Bloquer les mises à jour non déterministes dans CI
npm ci –ignore-scripts
Fixer un seuil d'audit plus strict
npm config set audit-level=high
Vérifiez les versions disponibles et les dates de publication
npm view error-ex versions –json
npm view error-ex time –json
Dans les contextes CI, définir ignore-scripts=true aide à réduire le risque d'exécution de scripts post-installation malveillants. Cela dit, il est conseillé d'établir dès le départ une base reproductible pour éviter des écarts inattendus. Pour une liste de contrôle étendue sur les vérifications CI, référez-vous à notre page sur les meilleures pratiques de la chaîne d'approvisionnement.
Renforcer la chaîne d'approvisionnement : défenses techniques recommandées
Utilisez un fichier de verrouillage déterministe (package-lock.json) et déployez avec npm ci pour garantir la reproductibilité.
Activez la 2FA sur NPM pour les publications et l'accès critique, en utilisant des tokens avec des portées limitées (automation vs. publish).
Implémentez une révision de code obligatoire et utilisez un pipeline CI isolé avec signature des artefacts.
Adoptez des systèmes de provenance, en vous référant à la documentation officielle sur la provenance des packages npm et aux normes comme SLSA.
Utilisez des outils de scan et des mises à jour contrôlées, telles que Dependabot, Renovate et sigstore/cosign, le cas échéant.
Appliquez le principe du moindre privilège pour les comptes des mainteneurs et des bots de publication.
Chronologie et statut des enquêtes
L'alerte a été rendue publique aujourd'hui, le 8 septembre 2025, et des vérifications sont actuellement en cours. Des avis officiels et des listes mises à jour des packages et versions compromis seront publiés progressivement. Par conséquent, il est conseillé de rester prudent, en suspendant les mises à jour non essentielles jusqu'à ce que les indicateurs de compromission soient consolidés. Dans l'attente de nouveaux retours, la priorité reste de contenir l'exposition et de documenter soigneusement chaque changement.
Angle Critique : Une Chaîne de Confiance Encore Fragile
La chaîne d'approvisionnement open source reste vulnérable lorsque l'accès aux comptes et les pipelines de publication ne sont pas suffisamment protégés. Le problème devient particulièrement pressant lorsque, en 2025, de nombreuses publications continuent d'avoir lieu sans l'adoption systématique de mesures telles que l'authentification à deux facteurs, la provenance et des examens rigoureux.
Tant que la confiance est considérée comme acquise, chaque projet continuera d'être exposé au risque généré par les autres. Pourtant, même de petites améliorations dans les processus peuvent réduire considérablement la surface d'attaque.
Le Point
Cet épisode met en avant l'importance cruciale de la sécurité de la chaîne d'approvisionnement dans les logiciels open source. Tant que les enquêtes se poursuivent, la priorité sera de limiter les surfaces d'attaque, de vérifier soigneusement les données de transaction à l'écran et de consolider les processus de publication grâce à l'adoption de l'authentification à deux facteurs (2FA), des fichiers de verrouillage et des systèmes de provenance.
La transparence des avis, comme l'ont souligné de nombreux experts, sera cruciale pour mesurer l'impact réel et restaurer la confiance dans l'écosystème. Dans ce contexte, le respect des meilleures pratiques reste le seul garde-fou immédiat.