La campagne PhantomRaven diffuse des packages npm malveillants via typosquatting pour voler tokens GitHub et secrets CI/CD. Auditez vos dépendances Node.js et révoquez les tokens potentiellement exposés.
Une campagne active baptisée PhantomRaven diffuse des dizaines de packages npm malveillants dans le registre officiel de Node.js, spécifiquement conçus pour dérober des tokens GitHub, des secrets CI/CD et des credentials d'accès aux pipelines de déploiement. La technique employée est le typosquatting : les packages imitent des dépendances légitimes populaires avec des noms quasi-identiques, exploitant les erreurs de frappe des développeurs lors de l'installation. Une fois installé, le package exfiltre silencieusement les variables d'environnement du système, les fichiers de configuration Git, les tokens OAuth et les credentials stockés localement. Cette campagne s'inscrit dans la continuité de l'attaque sur Trivy via GitHub Actions que nous avons documentée récemment, et confirme que les pipelines CI/CD et les postes développeurs sont devenus la cible prioritaire des attaquants cherchant à compromettre des chaînes logicielles entières en une seule frappe. Le danger est particulièrement élevé dans les organisations où les secrets CI/CD donnent accès aux environnements de production, un risque que nous avons analysé en détail dans notre article sur les angles morts de la sécurité DevOps. Les campagnes de type APT utilisent aussi ce vecteur — voir notre analyse sur APT41 et le ciblage des chaînes de développement.
- Contexte et chronologie des événements
- Impact sur l'écosystème cybersécurité
- Leçons apprises et recommandations
- Perspectives et évolutions attendues
En bref
- Dizaines de packages npm malveillants volant tokens GitHub, secrets CI/CD et credentials via typosquatting
- Développeurs Node.js, équipes DevOps, projets open-source et pipelines GitHub Actions / GitLab CI
- Auditer les packages installés récemment, révoquer tous les tokens potentiellement exposés
Un token GitHub compromis peut donner accès à l'ensemble des repositories de l'organisation, aux GitHub Actions secrets, aux packages privés et aux environnements cloud intégrés. Un secret CI/CD volé peut permettre à l'attaquant de modifier le code source, d'injecter des backdoors dans les builds et de compromettre les artefacts publiés — touchant potentiellement tous les utilisateurs du logiciel. Cette technique de pivot par la supply chain est particulièrement redoutable parce qu'elle contourne les défenses périmètriques classiques : l'attaquant n'a pas besoin de percer un pare-feu, il attend qu'un développeur fasse une faute de frappe. Les organisations utilisant des monorepos avec des dizaines de dépendances npm sont particulièrement exposées. Les outils recommandés pour se protéger incluent npm audit et les solutions de SCA comme Snyk. Pour comprendre comment les développeurs sont devenus une cible primaire, consultez notre article sur les campagnes APT ciblant les développeurs.
Recommandations immédiates
- Auditer les packages récents : vérifiez tous les packages npm installés depuis le 1er février 2026 dans vos projets et pipelines CI/CD
- Révoquer et renouveler les tokens GitHub, npm, AWS et autres secrets potentiellement exposés via les environnements de build
- Activer npm provenance et la vérification de l'intégrité des packages (
npm audit signatures) - Lockfile strict : committez votre
package-lock.jsonet interdire les installations sans lockfile en CI/CD - Restreindre les permissions des scripts postinstall en environnement CI/CD — utiliser
--ignore-scriptspour les packages de confiance inconnue - Monitorer les alertes de GitHub Security et Snyk sur les nouveaux packages malveillants détectés dans vos dépendances
Comment vérifier si un de mes packages npm fait partie de la campagne PhantomRaven ?
Exécutez npm audit dans tous vos projets — les packages malveillants identifiés par la campagne PhantomRaven ont été signalés à npm Inc. et apparaissent dans la base de vulnérabilités npm. Vérifiez également manuellement les packages installés récemment avec npm list --depth=0 et comparez les noms exacts aux packages légitimes que vous attendez. Recherchez des variantes avec des lettres transposées, des tirets ajoutés ou supprimés, ou des suffixes inhabituels (-utils, -helper, -core). Si vous trouvez un package suspect, supprimez-le, révoquez immédiatement vos tokens d'environnement et analysez vos logs de build pour détecter d'éventuelles exfiltrations.
Les pipelines CI/CD sur GitHub Actions sont-ils directement exposés à PhantomRaven ?
Oui, et c'est précisément la cible principale de cette campagne. Lors d'un job GitHub Actions qui exécute npm install, si un package malveillant est installé, il a accès aux variables d'environnement du runner — incluant les GITHUB_TOKEN, AWS_ACCESS_KEY_ID, et tout autre secret configuré dans les paramètres du repository. Ces secrets sont exfiltrés vers les serveurs de l'attaquant avant même que le build ne commence. La solution immédiate est d'activer le mode permissions restreintes sur vos workflows GitHub Actions et d'utiliser des lockfiles pour garantir l'installation exacte des packages attendus.
Comment prévenir les attaques de typosquatting npm à long terme dans mon organisation ?
Plusieurs mesures structurelles réduisent significativement ce risque : configurer un registre npm privé (Artifactory, Verdaccio, GitHub Packages) qui sert de proxy de confiance et bloque les packages non whitelistés ; activer les politiques de sécurité npm sur votre organisation GitHub pour exiger la vérification de provenance ; utiliser des outils de SCA (Snyk, Dependabot, Grype) intégrés dans votre pipeline pour détecter les nouveaux packages suspects ; et former vos développeurs à toujours vérifier deux fois le nom exact d'un package avant de l'installer, notamment pour les packages peu connus.
Intégrer la sécurité supply chain dans votre programme de sécurité
Les attaques de type supply chain sur npm ne sont pas des incidents isolés — elles font partie d'une tendance de fond qui nécessite une réponse programmatique et non uniquement réactive. Intégrer la sécurité des dépendances open source dans votre programme de sécurité signifie : inclure les audits de dépendances dans vos cycles de revue de code, définir des politiques d'approbation pour les nouveaux packages introduits dans les projets, et intégrer des outils de SCA (Software Composition Analysis) dans vos pipelines CI/CD comme étape bloquante. Sur le plan de la gouvernance, les organisations qui ont un niveau de maturité suffisant mettent en place un inventaire des dépendances open source (Software Bill of Materials / SBOM) qui permet de détecter rapidement si un package compromis est utilisé quelque part dans leur patrimoine applicatif. Consultez notre guide de sécurisation des accès d'entreprise pour comprendre comment intégrer ces contrôles dans votre politique de sécurité globale, et notre article sur l'automatisation des audits de sécurité pour voir comment industrialiser ces vérifications.
Points clés à retenir
- PhantomRaven : campagne active de packages npm malveillants ciblant les tokens GitHub et secrets CI/CD
- Vecteur : typosquatting + script postinstall automatique lors de npm install
- Action immédiate : audit des packages récents + révocation de tous les tokens potentiellement exposés
- Lockfile strict et npm provenance = mesures préventives structurelles à mettre en place dès maintenant
Article suivant recommandé
Moscou Usurpe Signal pour Cibler Officiels et Journalistes →Des acteurs affiliés au renseignement russe se font passer pour le support Signal afin de compromettre les comptes d'off
Articles connexes
Conclusion
Face à l'évolution constante des menaces, une posture de sécurité proactive est indispensable. Les techniques et recommandations présentées dans cet article constituent des fondations solides pour renforcer la résilience de votre infrastructure.
Besoin d'un accompagnement expert en cybersécurité ? Contactez Ayi NEDJIMI Consultants pour un audit personnalisé de votre infrastructure.
À lire également
Analyse des impacts et recommandations
L'analyse des risques associés à cette problématique révèle des impacts potentiels significatifs sur la confidentialité, l'intégrité et la disponibilité des systèmes d'information. Les recommandations présentées s'appuient sur les référentiels de l'ANSSI et du NIST pour garantir une approche structurée de la remédiation.
Lectures recommandées
Surface d'attaque : Ensemble des points d'entrée exploitables par un attaquant pour compromettre un système, incluant les services exposés, les interfaces utilisateur et les API.
À propos de l'auteur
Ayi NEDJIMI
Auditeur Senior Cybersécurité & Consultant IA
Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense
ayi@ayinedjimi-consultants.fr
Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.
À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.
Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.
Domaines d'expertise
Ressources & Outils de l'auteur
Articles connexes
Qilin : 6 victimes en 4 jours, RDP enumeration au coeur du TTP
Le groupe Qilin enchaine les victimes en cette fin avril 2026 : Lifeline PCS, The Switch Enterprises, Zinkan & Barker, Jayeff Construction. Nouvelle technique de reconnaissance via l'historique RDP des serveurs compromis.
CVE-2026-33827 : RCE wormable IPv6 dans la pile Windows TCP/IP
Microsoft a corrigé CVE-2026-33827, une race condition critique CVSS 9.8 dans la pile TCP/IP Windows lors du réassemblage de fragments IPv6 avec IPSec. Wormable, non-authentifiée, sans interaction utilisateur.
CVE-2026-32202 : APT28 vole vos hashes NTLM en zéro-clic
Microsoft et CISA confirment l'exploitation active de CVE-2026-32202, un correctif incomplet du zéro-day APT28. Coercition NTLM zéro-clic via fichier .lnk : le simple affichage d'un dossier suffit à fuiter les hashes vers l'attaquant.
Commentaires (1)
Laisser un commentaire