Nouvelle alerte supply chain dans l’écosystème npm. Des paquets associés à Red Hat ont diffusé Miasma, un malware qui ne vise pas les utilisateurs finaux, mais les accès techniques utilisés par les développeurs.
Quelques mois après l’intrusion visant un serveur GitLab utilisé par ses équipes de conseil, Red Hat se retrouve associé à une nouvelle compromission, cette fois dans son écosystème npm. Détectée le 1er juin 2026 par Aikido, l’attaque a permis de diffuser Miasma, un malware pensé pour aspirer des identifiants développeurs, des tokens et des clés d’accès depuis des machines de développement ou des environnements de compilation. Red Hat assure que le code malveillant n’a pas été publié à destination des clients via console.redhat.com, mais les paquets compromis relevaient bien d’un périmètre sensible, celui des outils utilisés pour développer, tester et publier du code.
Offre partenaire
Votre petite entreprise a de grandes ambitions. Protégez-là contre les pirates. Et développez sereinement votre activité !
Offre partenaire
Des paquets npm piégés via GitHub
Selon Aikido, 32 paquets npm publiés sous le scope @redhat-cloud-services ont été compromis, pour un total de 96 versions piégées et près de 117 000 téléchargements hebdomadaires cumulés. D’après les chercheurs, les cybercriminels ne se seraient pas attaqués directement au registre npm, mais seraient passés par GitHub pour publier des versions malveillantes de paquets existants.
Aikido indique en effet qu’un compte appartenant à un employé Red Hat aurait été compromis, puis utilisé pour pousser des commits malveillants dans plusieurs dépôts. Ces modifications ont permis de déclencher la publication automatique, sur npm, de versions infectées présentées comme des mises à jour légitimes.
Ces versions embarquaient un script malveillant qui exécutait automatiquement une charge utile dès leur installation par un développeur. Le malware fouillait ensuite la machine ou l’environnement de compilation à la recherche d’identifiants, de tokens et de clés d’accès pouvant servir à accéder à des dépôts, publier du code ou administrer des services cloud.
Les équipes de recherche rattachent cette campagne à Miasma, une variante proche de Mini Shai-Hulud. Ce malware s’inscrit dans une série d’attaques récentes contre l’écosystème open source, dont le principe consiste à voler des secrets développeurs pour compromettre ensuite d’autres projets ou d’autres chaînes de publication.
Red Hat a fait le ménage, les accès doivent être renouvelés
Red Hat a confirmé avoir supprimé les paquets concernés du registre npm après avoir été alerté. Dans une déclaration transmise à BleepingComputer, l’entreprise a tenu à limiter le périmètre de l’incident, en précisant qu’il concernait uniquement de l’outillage de développement interne et que le code malveillant n’avait pas été publié à destination des clients via console.redhat.com. L’éditeur a également indiqué ne pas avoir identifié d’impact sur ses environnements de production, ses clients ou ses partenaires pour le moment.
Pour les équipes qui auraient installé l’une des versions piégées depuis le 1er juin 2026, cette suppression ne suffit toutefois pas. Miasma a pu collecter des identifiants, des tokens ou des clés d’accès avant le retrait des paquets, ce qui impose de traiter les machines de développement et les serveurs de compilation concernés comme des environnements exposés.
La suite relève moins du nettoyage que de la révocation. Les organisations concernées doivent renouveler les tokens GitHub, npm et PyPI, remplacer les clés cloud AWS, Google Cloud ou Azure, vérifier les clés SSH, contrôler les fichiers .env exposés et auditer les dépôts ou processus de publication susceptibles d’avoir été modifiés.
Une attaque supply chain consiste à compromettre un maillon de la chaîne de fabrication logicielle (dépendances, outils de build, CI/CD) pour toucher indirectement de nombreux projets. Dans l’écosystème npm, un paquet piégé peut s’installer automatiquement comme dépendance et exécuter du code lors de l’installation ou du build. L’objectif n’est pas forcément d’infecter les utilisateurs finaux, mais de récupérer des accès techniques (tokens, clés, identifiants) présents sur les postes de dev ou serveurs de compilation. Une fois ces secrets volés, l’attaquant peut publier de nouvelles versions malveillantes, accéder à des dépôts privés ou rebondir vers des infrastructures cloud, ce qui démultiplie l’impact.
Comment une compromission de compte GitHub peut-elle entraîner la publication automatique de versions malveillantes sur npm ?De nombreux projets publient sur npm via une chaîne CI/CD reliée à GitHub : un commit, un tag ou un merge peut déclencher un workflow (GitHub Actions, par exemple) qui build et publie une nouvelle version. Si un compte GitHub disposant des droits d’écriture est compromis, l’attaquant peut injecter du code malveillant dans le dépôt, puis laisser l’automatisation produire une release « légitime » en apparence. Cette approche évite d’attaquer directement le registre npm et exploite la confiance accordée au processus de publication. Elle est particulièrement efficace si les secrets de publication (token npm, clés de signature, accès registry) sont disponibles dans la CI.
Que sont les tokens et clés d’accès (GitHub, npm, AWS/Azure/GCP) et pourquoi faut-il les révoquer après une fuite ?Un token est un secret qui permet d’agir au nom d’un compte ou d’un service sans mot de passe, souvent avec des droits précis (publier un paquet, lire un dépôt, déployer sur le cloud). Les clés d’accès cloud (AWS, Azure, GCP) et les clés SSH servent à authentifier des scripts, des développeurs ou des serveurs sur des ressources sensibles. Si un malware les copie, changer le mot de passe ne suffit pas : le token ou la clé reste valable tant qu’il n’est pas invalidé côté fournisseur. Révoquer puis régénérer ces secrets coupe l’accès à l’attaquant et limite les compromissions en cascade (publication de nouveaux paquets, modification de dépôts, déploiements non autorisés).
