Red Hat attaqué via npm : décryptage d’une chaîne d’approvisionnement piégée

Temps de lecture : 6 min

npm, le maillon faible de la chaîne d’approvisionnement

Quand Red Hat annonce avec IBM un plan de sécurité global pour l’open source, on s’attend à ce que l’exemple vienne d’en haut. Pourtant, quelques jours après cette annonce, c’est Red Hat lui-même qui se fait percer. L’attaque vise npm, le gestionnaire de paquets JavaScript de Node.js. Rien de très original dans la cible – npm accumule les failles – mais le contexte rend l’affaire particulièrement embarrassante.

Comment la brèche s’est ouverte

Fin juin 2026, les équipes de sécurité d’Aikido détectent une activité suspecte dans l’espace de noms @redhat-cloud-services. Le verdict tombe : 96 versions réparties sur 32 paquets sont compromises. Le ver vole les identifiants et cumule à lui seul près de 117 000 téléchargements par semaine.

Le point d’entrée ? Un compte GitHub appartenant à Red Hat, compromis. Les attaquants injectent un script malveillant via un hook de préinstallation npm. Dès qu’un développeur ou un système CI/CD exécute npm install sur un paquet infecté, le code s’exécute automatiquement.

Microsoft Threat Intelligence précise que chaque paquet piégé contient un script préinstall qui charge un index.js obfusqué, lequel télécharge une charge utile conçue pour aspirer les secrets présents dans l’environnement : jetons npm, GitHub, AWS, SSH, et bien d’autres.

Miasma : la nouvelle variante du ver Shai-Hulud

Les chercheurs relient rapidement cette campagne au malware Mini Shai-Hulud, un ver npm déjà actif lors d’incidents antérieurs. Mais ici, il s’agit d’une variante plus sophistiquée baptisée Miasma. Celle-ci conserve la capacité d’auto-propagation et y ajoute une obfuscation renforcée ainsi qu’un chargement en plusieurs étapes.

Le point le plus inquiétant ? Dès que le ver s’exécute sur une machine ayant accès à d’autres paquets npm, il identifie ceux que l’utilisateur courant peut publier et les republie avec la même charge malveillante. Chaque victime devient un nouvel attaquant. Cette propagation fulgurante a permis de contaminer plus de trente paquets en quelques minutes.

Des secrets en libre accès

Une fois infiltrés, les attaquants n’ont pas fait dans la dentelle. Le code malveillant aspire :

• les secrets et jetons d’accès GitHub Actions
• les clés SSH et jetons personnels GitHub
• les identifiants AWS, GCP, Azure
• les configurations et jetons Kubernetes
• les jetons HashiCorp Vault
• les secrets CI/CD (npm, CircleCI, etc.)

Si vous avez installé ces paquets, considérez que tous les secrets exposés sont entre les mains de l’attaquant. Les éditeurs de solutions de sécurité sont unanimes : il faut partir du principe que tout environnement ayant exécuté ces paquets est compromis.

Ce qu’il faut faire immédiatement

Red Hat a rapidement réagi : retrait des paquets du registre npm, enquête en cours. L’entreprise assure que le code malveillant n’a jamais été publié via les systèmes clients (console.redhat.com). Pas d’impact client ni partenaire, affirme-t-elle. Mais sur le terrain, je reste prudent. Voici ce que je recommande si vous utilisez les services cloud de Red Hat ou avez intégré des paquets @redhat-cloud-services :

• Scannez vos arborescences de dépendances pour identifier les versions compromises.
• Bloquez ces versions dans vos fichiers de verrouillage (package-lock.json, yarn.lock).
• Remplacez ou rétrogradez les paquets concernés par des builds de confiance.
• Rotation immédiate de tous les secrets : jetons GitHub, clés SSH, clés API cloud, tokens CI/CD. Ne faites pas l’impasse.
• Reconstruisez les environnements à partir de bases saines connues.

Certes, l’incident aurait pu être bien pire. Mais ne vous reposez pas sur les assurances de Red Hat. Comme le rappellent les chercheurs de Semgrep, toute build ayant touché ces paquets doit être considérée comme potentiellement compromise. Le ver se propage vite, et une seule machine infectée peut contaminer toute la chaîne.

Leçon pour l’avenir

Cet incident montre une fois de plus que les dépôts npm, même quand ils sont gérés par des grands comptes comme Red Hat, restent un terrain miné. La pression monte sur les gestionnaires de registres et sur les fournisseurs pour offrir des garanties solides sur la provenance des paquets. En attendant, la seule protection fiable, c’est la vigilance et l’hygiène de base : rotation régulière des secrets, isolation des builds, et scan systématique des dépendances.

Décortiquons ça : si même Red Hat, qui vient de lancer un plan de sécurité mondial, peut se faire avoir, c’est que le problème est systémique. Sur le terrain, ce qui compte vraiment, c’est de ne jamais baisser la garde. En pratique, un bon verrouillage des versions et des miroirs internes reste la meilleure défense. Mais encore faut-il que ces miroirs soient eux-mêmes sécurisés – et ça, c’est une autre histoire.

En résumé

• 96 versions de paquets npm Red Hat compromises par le ver Miasma.
• Propagation via hooks de préinstallation : toute machine dev devient potentiellement vecteur.
• Rotation des secrets impérative pour tout environnement ayant touché ces paquets.
• Pas de clients finaux impactés, mais la confiance dans les chaînes open source en prend un coup.

Si cet article vous a été utile, n’hésitez pas à le partager. Et surtout, gardez un œil sur vos dépendances – c’est le conseil le plus pragmatique que je puisse vous donner aujourd’hui.

Article initialement publié en juin 2026. Mis à jour pour refléter les dernières informations disponibles.

Mathias Courtois

Ingénieur systèmes et architecte cloud pendant 8 ans chez un leader européen de l’hébergement, reconverti dans l’analyse tech et business. Passionné par l’intersection entre infrastructure IT, IA générative et transformation digitale des entreprises. J’aide les décideurs et les équipes techniques à naviguer dans l’écosystème tech sans bullshit marketing.