What happened to Red Hat’s npm packages?

More than 30 Red Hat Cloud Services npm packages were compromised after attackers hijacked a Red Hat employee’s GitHub account and pushed malicious commits containing a credential‑stealing malware variant called Mini Shai‑Hulud.

How did the attackers compromise the packages?

They first compromised a single Red Hat employee’s GitHub account, then used that legitimate developer identity to push infected code directly to the repositories, bypassing automated trust checks.

What is the Mini Shai‑Hulud malware and how does it work?

It is a credential‑stealer that executes automatically at package installation time (`npm install`), immediately collecting cloud access keys, SSH keys, and Kubernetes configuration files from the target system.

What credentials were the attackers after?

The malware targeted AWS, Google Cloud Platform, and Azure credential files, as well as SSH private keys and Kubernetes configuration files, all of which can grant broad access to production infrastructure.

Why are CI/CD pipelines especially vulnerable to this attack?

CI/CD runners often store long‑lived cloud credentials as environment variables or mounted secrets, so a single infected build runner can silently leak keys that control entire cloud environments.

Les paquets npm de Red Hat touchés : plus de 30 dépôts diffusent un voleur d’identifiants cloud

Une campagne coordonnée d’attaque de la chaîne d’approvisionnement npm visant le vol d’identifiants cloud a frappé l’un des noms les plus connus des logiciels d’entreprise. Des attaquants inconnus ont compromis plus de 30 paquets npm de Red Hat Cloud Services en prenant d’abord le contrôle du compte GitHub d’un employé de Red Hat, puis en utilisant cet accès pour pousser des commits malveillants. Le logiciel malveillant intégré à ces paquets, identifié comme une variante de la souche « Mini Shai-Hulud », s’exécute automatiquement au moment de l’installation et commence immédiatement à exfiltrer des identifiants cloud, notamment des clés d’accès AWS, GCP et Azure, ainsi que des clés SSH et des fichiers de configuration Kubernetes.

Cet incident se distingue non pas à cause d’une faiblesse de npm lui-même, mais par la manière dont les attaquants sont entrés : via une identité de développeur légitime et de confiance.

Comment les paquets npm de Red Hat ont été compromis

La chaîne d’attaque a débuté par la compromission d’un seul compte GitHub appartenant à un employé de Red Hat. Une fois à l’intérieur de ce compte, les attaquants disposaient de l’accès nécessaire pour pousser du code directement vers les dépôts liés aux paquets npm de Red Hat Cloud Services. Comme les commits provenaient d’un compte contributeur reconnu, les pipelines automatisés et les réviseurs ont eu beaucoup plus de mal à détecter quelque chose de suspect.

C’est la caractéristique déterminante d’une attaque de la chaîne d’approvisionnement logicielle : la charge utile malveillante voyage à l’intérieur d’un logiciel légitime, signé et distribué par des canaux de confiance. Les développeurs qui ont installé ou mis à jour l’un des paquets concernés pendant la fenêtre de compromission ont exécuté le logiciel malveillant à leur insu sur leurs propres systèmes, sans avertissement évident. Les paquets eux-mêmes continuaient de fonctionner normalement, rendant la détection encore plus difficile.

La variante « Mini Shai-Hulud » du logiciel malveillant est spécifiquement conçue pour s’exécuter au moment de l’installation, à l’instant où le développeur tape npm install. Elle n’attend pas le lancement de l’application ni l’interaction d’un utilisateur. Cette approche réduit considérablement le délai entre l’infection et l’exfiltration.

Quels identifiants ont été volés et pourquoi c’est important

La liste des cibles du logiciel malveillant ressemble à un inventaire des éléments les plus préjudiciables qu’un attaquant pourrait extraire du poste de travail d’un développeur ou d’un runner de pipeline CI/CD. Les fichiers d’identifiants AWS, Google Cloud Platform et Azure sont les cibles principales, car ces clés portent souvent des autorisations étendues sur l’infrastructure de production. Les clés privées SSH et les fichiers de configuration Kubernetes complètent la récolte, offrant aux attaquants des chemins potentiels de déplacement latéral vers les réseaux internes et les clusters d’orchestration de conteneurs.

Pour les organisations qui utilisent des pipelines de build automatisés, le risque d’exposition est amplifié. Les systèmes CI/CD stockent fréquemment des identifiants cloud à longue durée de vie sous forme de variables d’environnement ou de secrets montés. Un seul runner de build infecté pourrait remettre silencieusement des clés qui contrôlent des environnements cloud entiers, ouvrant potentiellement la porte à l’exfiltration de données, au déploiement de ransomwares ou à un accès persistant de type backdoor.

C’est également pour cette raison que les équipes de sécurité doivent garder à l’esprit que les points d’entrée de la chaîne d’approvisionnement mènent fréquemment à une compromission plus profonde du système. Le récent signalement par la CISA de la CVE-2026-31431, une faille d’élévation de privilèges locale sous Linux, en est un rappel direct : les attaquants qui atterrissent sur un système avec des identifiants volés ou un accès initial s’arrêtent rarement là. Ils cherchent le maillon suivant de la chaîne.

Pourquoi les attaques de la chaîne d’approvisionnement échappent aux sécurités standard

Les outils de sécurité conventionnels reposent sur l’hypothèse que le code externe, non signé ou inconnu, constitue la menace. Les pare-feu, les agents de détection de point de terminaison et les scanners basés sur les signatures sont calibrés pour signaler les anomalies. Les attaques de la chaîne d’approvisionnement contournent ce modèle en se cachant dans des logiciels qui portent une signature légitime et arrivent par un canal attendu.

Dans le cas présent, la marque Red Hat et l’historique du compte GitHub associé ont conféré aux paquets compromis un degré élevé de confiance implicite. Les développeurs travaillant sur une infrastructure proche de Red Hat ont peut-être installé ces paquets précisément parce qu’ils s’attendaient à ce qu’ils soient bien maintenus et sécurisés.

Les outils standard d’analyse des dépendances, qui vérifient les versions vulnérables connues, ne détecteraient pas les voleurs d’identifiants s’exécutant à l’installation, à moins que la version malveillante n’ait déjà été signalée dans une base de données de vulnérabilités. L’attaque exploite l’écart entre la détection du « connu mauvais » et l’analyse comportementale.

Défenses en couches : gestion des secrets, segmentation réseau et VPN

Aucune mesure unique ne peut arrêter une attaque sophistiquée de la chaîne d’approvisionnement, mais une défense en couches peut réduire considérablement le rayon d’impact.

Gestion des secrets plutôt que fichiers d’identifiants locaux. La mesure la plus efficace consiste à éliminer totalement les fichiers d’identifiants statiques des machines des développeurs et des runners CI/CD. Les outils qui délivrent des identifiants éphémères, générés juste à temps, font qu’un identifiant volé expire avant qu’un attaquant puisse en faire un usage significatif.

Épinglage des dépendances et vérification de l’intégrité. Verrouiller les paquets sur des hachages de commit spécifiques et vérifiés plutôt que sur des plages de versions flottantes limite l’exposition à des modifications de code inattendues. Combiner cela à des contrôles automatisés d’intégrité du contenu des paquets ajoute une couche de détection supplémentaire.

Segmentation réseau et filtrage de sortie. Le logiciel malveillant Mini Shai-Hulud a besoin d’envoyer les données volées quelque part. Restreindre les connexions sortantes des environnements de build et des machines des développeurs à des points de terminaison connus peut empêcher l’exfiltration même si le logiciel malveillant s’exécute correctement. Les VPN et les architectures réseau zero-trust peuvent appliquer ces politiques de sortie de manière cohérente sur des équipes distribuées.

Authentification multifacteur sur chaque compte développeur. La compromission initiale était une prise de contrôle de compte GitHub. Des exigences strictes d’authentification multifacteur, en particulier les clés de sécurité matérielles ou l’authentification par passkey, rendent le piratage de compte nettement plus difficile.

Surveillance comportementale dans les pipelines CI/CD. Alerter sur les requêtes DNS sortantes inattendues ou les connexions réseau pendant la phase de build peut révéler un logiciel malveillant à l’installation avant que les identifiants volés ne soient utilisés.

Ce que cela signifie pour vous

Si votre environnement de développement ou d’exploitation dépend de paquets npm de Red Hat Cloud Services, la priorité immédiate est d’auditer les versions de paquets utilisées, de rechercher des indicateurs de compromission dans les journaux réseau autour des événements d’installation et de révoquer tout identifiant cloud qui aurait pu être présent sur les systèmes affectés.

Plus largement, cet incident est une incitation à revoir votre hygiène en matière d’identifiants cloud de bout en bout. Les identifiants sont-ils stockés sous forme de fichiers sur les machines des développeurs ? Les variables d’environnement CI/CD sont-elles limitées au moindre privilège ? L’authentification multifacteur est-elle appliquée à chaque compte disposant de droits de publication de paquets ?

Les attaques de la chaîne d’approvisionnement réussissent en exploitant la confiance. La parade consiste à construire des systèmes qui ne s’appuient pas uniquement sur une confiance implicite : les identités vérifiées, les secrets à durée limitée et la surveillance comportementale en sont les fondations. Commencez dès aujourd’hui par un audit des identifiants, et traitez chaque dépendance comme une surface d’attaque potentielle qui mérite un examen rigoureux.