TeamPCP : une signature valide qui certifie un malware crypto

La crypto s'est construite sur une promesse : « ne faites pas confiance, vérifiez ». En mai 2026, un ver npm a produit une signature cryptographique parfaitement valide — qui certifiait un malware. Le groupe TeamPCP a empoisonné Nx Console, l'extension officielle de VS Code (2,2 millions d'installations), et a déclenché Mini Shai-Hulud, le premier ver documenté s'auto-propageant avec une provenance (origine signée) SLSA Build Level 3 authentique. GitHub a confirmé l'exfiltration d'environ 3 800 de ses répertoires internes en moins de 20 minutes. Mais la donnée cruciale pour la crypto n'est pas celle-là : c'est que l'attestation cryptographique — le type même de preuve sur lequel repose toute la confiance on-chain — a cessé de garantir quoi que ce soit. Et ce n'est pas un cas isolé : c'est le dernier maillon d'une lignée de huit ans d'attaques de la chaîne d'approvisionnement ciblant spécifiquement la crypto. Nous le disons sans alarmisme : le payload balaie les chemins des wallets, mais au 1er juin, aucun post-mortem ne documente de fonds DeFi volés par cette campagne. C'est un vecteur confirmé, pas une perte consommée — et l'historique précédent explique pourquoi il convient de le prendre au sérieux.

Que s'est-il passé exactement en mai 2026 ?

Le 11 mai 2026, les équipes de sécurité de la chaîne d'approvisionnement ont détecté la première vague d'un ver infectant des paquets npm : plus de 170 paquets compromis, dont des composants de projets très utilisés comme TanStack et des bibliothèques de Mistral AI. Le 12 mai, le code source du ver a été brièvement publié sur un répertoire public GitHub avant d'être retiré — un matériel qui a servi de base aux analyses médico-légales ultérieures.

Le saut qualitatif a eu lieu le 18 mai. TeamPCP a publié une version malveillante (v18.95.0) de Nx Console, l'extension officielle de VS Code pour le monorepo Nx, comptant plus de 2,2 millions d'installations. La version empoisonnée a été disponible sur le VS Code Marketplace pendant une fenêtre très courte : le post-mortem officiel de Nx l'estime à 11 minutes et l'alerte de CISA à 18 — dans tous les cas, moins de 20 minutes. Sur Open VSX (le registre ouvert utilisé par des éditeurs comme Cursor ou VSCodium), la fenêtre a atteint environ 36 minutes. Un temps plus que suffisant pour que la mise à jour automatique la pousse vers un nombre inconnu de machines de développeurs.

Le 19 mai, GitHub a confirmé l'exfiltration d'environ 3 800 de ses propres répertoires internes — un chiffre revendiqué par l'attaquant et validé provisoirement par la plateforme. GitHub a précisé que les répertoires des clients n'ont pas été affectés. Le même jour, une seconde vague du ver s'est déchaînée contre les paquets de la famille @antv (la suite de visualisation de données d'AntDesign), portant à plus de 500 le nombre de paquets compromis dans cette vague. Le chiffre de 518 millions qui a circulé correspond au total historique des téléchargements cumulés par les paquets concernés, et non aux téléchargements du malware.

Comment l'attaque a-t-elle fonctionné, étape par étape ?

L'élégance de l'attaque réside dans l'enchaînement de la confiance légitime à chaque maillon. La séquence, reconstruite à partir des bulletins de StepSecurity, OX Security et du post-mortem de Nx :

1. Extension empoisonnée. Le développeur installe ou met à jour Nx Console depuis le Marketplace officiel. L'extension possède une signature valide et provient du bon éditeur. Lors de son activation, la version malveillante exécute du code sur la machine du développeur avec les mêmes permissions que sa session d'éditeur.
2. Vol du token de CI/CD. De nombreux répertoires utilisent GitHub Actions avec des tokens OIDC (OpenID Connect : identifiants de courte durée qu'un pipeline obtient pour s'authentifier sans secrets statiques) et des tokens de publication npm. Le payload recherche ces identifiants dans l'environnement et dans les fichiers de configuration du projet : variables d'environnement, fichiers .npmrc, tokens d'Actions mis en cache.
3. Propagation du ver. Avec un token de publication npm valide, le malware n'a pas besoin d'attendre une autre victime humaine. Il republie des versions trojanisées des paquets que ce token contrôle, et ces paquets infectent à leur tour quiconque les installe. C'est la propriété qui transforme un incident ponctuel en ver : l'auto-réplication via le réseau de dépendances.
4. Signature de provenance valide. C'est ici que se trouve l'innovation effrayante. Mini Shai-Hulud génère des attestations SLSA Build Level 3 authentiques pour les paquets malveillants. La chaîne de provenance que npm affiche comme preuve qu'un paquet a été construit dans un pipeline de confiance était cryptographiquement correcte — sauf qu'elle certifiait un malware. La signature n'était pas falsifiée : elle était émise par un pipeline détourné.
5. Balayage des identifiants et wallets. Le payload scanne le disque à la recherche de chemins de wallets de crypto-monnaies — fichiers Bitcoin, Ethereum et Monero, et les répertoires d'applications comme Exodus, Electrum et Atomic — en plus des clés de CI/CD, des tokens cloud et des secrets de déploiement. C'est ce qui transforme une attaque générique de la chaîne d'approvisionnement en une menace spécifique pour ceux qui développent en Web3.

Pourquoi cette attaque est-elle spécifiquement dangereuse pour les développeurs Web3 ?

Un développeur d'applications traditionnelles qui subit cette compromission perd, dans le pire des cas, des secrets d'entreprise et l'accès à l'infrastructure de la société. Un développeur Web3 possède sur la même machine, et souvent dans le même arbre de projet, des actifs qui sont de l'argent au porteur.

L'équivalent Web3 de « voler le mot de passe de production » est de voler la clé privée qui signe un déploiement de contrat, ou la seed d'un wallet de trésorerie d'un protocole. Il n'y a pas de département des fraudes pour annuler la transaction ni de support pour geler le compte : si la clé fuite et que l'attaquant signe, les fonds ont disparu. Les chemins que le payload de Mini Shai-Hulud traque — Exodus, Electrum, Atomic, clés Ethereum et Bitcoin — sont exactement ceux qu'un développeur crypto a sous la main pour tester, déployer et opérer.

À cela s'ajoute le risque de pipeline. Si le token de publication npm de votre bibliothèque fuite, l'attaquant ne vous vole pas vous : il trojanise votre paquet et le livre à tous vos utilisateurs avec votre signature. Pour un projet DeFi dont la bibliothèque SDK est consommée par d'autres dapps, cela signifie devenir, sans le savoir, le vecteur qui compromet des tiers. Le dommage réputationnel et de confiance est difficile à inverser.

La distinction honnête : au 1er juin 2026, il n'existe aucun post-mortem public documentant des fonds DeFi soustraits attribuables à cette campagne. Le vecteur est confirmé par l'analyse du payload ; le vol de crypto-actifs par ce biais est un risque actif, pas un fait rapporté. Le traiter comme imminent est prudent ; affirmer qu'il a déjà vidé des trésoreries est faux.

Est-ce nouveau ? La lignée des attaques de chaîne d'approvisionnement contre la crypto

Non. Ce qui rend Mini Shai-Hulud pertinent n'est pas son caractère inédit, mais le fait qu'il représente l'échelon le plus haut d'une échelle que la crypto gravit depuis 2018. La chaîne d'approvisionnement logicielle — les paquets npm, les bibliothèques qui signent les transactions, les SDK qui chargent les dapps — a été une cible récurrente précisément parce qu'elle connecte directement à l'argent. Voici les jalons :

La colonne des vols enseigne deux choses. Premièrement : l'échelle et les dommages ne vont pas de pair. L'attaque de septembre 2025 a touché des paquets avec 2,6 milliards de téléchargements hebdomadaires et n'a rapporté que des centimes ; Ledger a drainé plus d'un demi-million de dollars en moins de deux heures avec une bibliothèque beaucoup plus petite, car elle était branchée directement sur les signatures de dapps. Ce qui décide du butin n'est pas le nombre de machines infectées, mais combien possèdent une clé permettant de déplacer de l'argent à portée de main. Deuxièmement : la sophistication augmente. Copay attendait passivement une victime riche ; Shai-Hulud s'auto-propage ; Mini Shai-Hulud, en plus, signe son propre malware avec une attestation que le système juge valide.

Le paradoxe de la confiance : quand une signature valide certifie un malware

Voici le coup qui devrait déranger la crypto plus que le vol de 3 800 répertoires. L'industrie du logiciel a construit SLSA et les attestations de provenance de npm en réponse à SolarWinds : l'idée était que l'on puisse vérifier cryptographiquement qu'un paquet a été construit dans un pipeline de confiance, sans avoir à croire qui que ce soit sur parole. C'est, point par point, la même philosophie qui soutient la crypto — « don't trust, verify », la vérification remplace la confiance.

Mini Shai-Hulud n'a pas brisé cette vérification : il l'a cooptée. Ses paquets malveillants portent une signature de provenance SLSA Build Level 3 authentique, cryptographiquement correcte, car elle a été émise par un véritable pipeline — seulement celui-ci était détourné. La vérification passe. La preuve est valide. Et elle certifie un malware. La leçon est désagréable et s'applique directement à tout système basé sur l'attestation, y compris une bonne partie de l'échafaudage on-chain : une signature valide prouve d'où vient quelque chose, jamais qu'il soit honnête. Quand nous confondons « vérifié » avec « sûr », la cryptographie cesse de nous protéger et commence à nous donner une fausse tranquillité signée.

En quoi est-ce différent de SolarWinds ?

L'attaque contre SolarWinds (2020) est la référence incontournable de la chaîne d'approvisionnement logicielle. La comparaison aide à mesurer à quel point la barre s'est élevée en six ans.

Deux différences importent plus que les autres. La première est l'auto-réplication : SolarWinds dépendait de l'installation par les victimes d'une mise à jour spécifique ; Mini Shai-Hulud se propage seul chaque fois qu'il capture un token de publication, sans attendre d'intervention humaine. La seconde est la provenance valide : l'industrie a construit SLSA et les attestations npm précisément en réponse à SolarWinds, pour que l'on puisse vérifier qu'un paquet provient d'un pipeline de confiance. TeamPCP n'a pas brisé cette défense — il l'a cooptée. Une signature de provenance authentique cesse d'être une garantie lorsque le pipeline qui l'émet est déjà compromis.

Qui est TeamPCP et pourquoi l'attribution est-elle importante ?

Google Threat Intelligence (Mandiant) suit le groupe sous le nom d'UNC6780. Contrairement à SolarWinds, attribué à de l'espionnage d'État-nation, TeamPCP a une motivation financière : il monétise les accès via le groupe de ransomware Vect, selon l'analyse recueillie par le SANS Internet Storm Center et CSA Labs. Le groupe est latent depuis environ le 24 mai ; aucune nouvelle vague postérieure à cette date ne peut être considérée comme confirmée.

La chronologie institutionnelle a bouclé la boucle fin mai. Le 27 mai, la vulnérabilité de Nx Console — enregistrée sous le nom de CVE-2026-48027, avec un score CVSS de 9,8 dans le NVD et 9,4 dans l'évaluation de CISA — a été ajoutée au catalogue KEV (Known Exploited Vulnerabilities) de CISA, la liste des failles avec exploitation active confirmée. Le 28 mai, CISA a émis une alerte formelle sur les compromissions de Nx Console et des répertoires GitHub. Par ailleurs, le CERT-EU a documenté la Commission européenne comme victime downstream via une compromission antérieure du même groupe sur l'outil Trivy (mars 2026), ce qui montre la portée institutionnelle de l'acteur au-delà de l'écosystème crypto.

Comment auditer mon environnement de développement Web3 dès maintenant ?

Voici le bloc actionnable. Si vous développez en Web3 et utilisez VS Code, npm ou des pipelines de CI/CD, parcourez ces points avant de poursuivre votre lecture.

• Auditez les extensions VS Code installées. Vérifiez la liste des extensions et leurs versions. Si vous avez Nx Console, confirmez que vous n'êtes pas sur la v18.95.0 ; Nx a publié une version propre après l'incident. Au-delà de cette extension spécifique, désactivez la mise à jour automatique des extensions dans les environnements où vous manipulez des clés sensibles : la mise à jour silencieuse a été précisément ce qui a distribué le payload en moins de 20 minutes.
• Vérifiez la provenance de vos dépendances npm — avec scepticisme. Exécutez npm audit signatures et examinez les attestations de provenance, mais partez du principe qu'une provenance valide n'est plus une preuve suffisante en soi. Un indice utile rapporté dans ce cas : lors de la vague @antv du 19 mai, plus de 300 versions ont été publiées en une rafale d'environ 22 minutes ; des outils d'analyse de dépendances comme Socket.dev ou Phylum détectent ce schéma de publication massive en temps réel.
• Isolez les clés de CI/CD des permissions de publication. Le token qui construit et teste ne devrait pas être le même que celui qui publie les paquets. Utilisez des tokens npm granulaires avec une portée minimale, préférez l'OIDC de courte durée aux secrets statiques de longue durée, et configurez le trusted publishing là où le registre le permet. Un token de build volé qui ne peut pas publier ne transforme pas votre bibliothèque en ver.
• Sortez les clés de wallet de l'environnement de développement. Ne stockez pas de seeds de production ni de clés de déploiement dans les fichiers du projet, les variables d'environnement de l'éditeur ou les gestionnaires de secrets que la session VS Code peut lire. Utilisez un wallet matériel ou un signataire isolé pour toute opération ayant une valeur réelle, et des wallets jetables sans fonds pour les tests.
• Renouvelez vos identifiants au moindre doute. Si vous avez installé ou mis à jour Nx Console entre le 11 et le 19 mai, considérez tous les identifiants accessibles depuis cette machine comme compromis : tokens npm et GitHub, clés cloud, et tout particulièrement toute clé de wallet ayant touché cet équipement. Le renouvellement est peu coûteux comparé au risque de supposer que rien ne s'est passé.

Quels signes indiquent qu'une extension ou un paquet est compromis ?

Il n'y a pas toujours de CVE publié quand vous en avez besoin. Ce qui a rendu cet incident difficile à détecter, selon les analyses de Microsoft et StepSecurity, c'est qu'il ne s'est pas appuyé sur une infrastructure externe inconnue mais sur des plateformes de confiance — le Marketplace officiel lui-même, GitHub, le registre npm —, là même où les outils de sécurité ont tendance à baisser la garde. C'est pourquoi la recommandation des équipes de réponse (CISA, CERT-EU) n'a pas été de chercher une signature spécifique, mais de vérifier les accès et l'activité inhabituels sur cette infrastructure de confiance pendant la fenêtre du 18-19 mai.

L'indicateur d'écosystème le plus fiable dans cette campagne a été temporel : une rafale de nouvelles versions publiées presque simultanément sur de nombreux paquets du même auteur ou de la même organisation — le schéma d'un token de publication volé republiant en masse, comme les 300+ versions de @antv en ~22 minutes. C'est un schéma que les outils d'analyse de dépendances signalent en temps réel.

La défense pratique n'est pas de détecter le "jour zéro", mais de réduire le rayon d'explosion : mises à jour manuelles et révisées sur les machines possédant des clés, permissions minimales, et séparation stricte entre l'ordinateur où vous écrivez le code et l'endroit où résident les clés qui déplacent l'argent.

Quelles leçons en tirer pour le développement Web3 ?

Trois données de l'incident lui-même résument la leçon. La première concerne le temps de réaction : CISA a mis neuf jours pour émettre l'alerte formelle (de la compromission du 19 mai à l'alerte du 28), et le CVE-2026-48027 n'est entré au catalogue KEV que le 27. Quiconque a attendu l'avis officiel pour agir a été exposé pendant plus d'une semaine ; la défense ne peut dépendre de la cadence institutionnelle.

La deuxième concerne la portée : le CERT-EU a documenté la Commission européenne comme victime downstream d'une compromission antérieure du même groupe sur l'outil Trivy, datée de mars 2026. Autrement dit, UNC6780 opérait depuis au moins trois mois dans la même chaîne d'approvisionnement avant que l'industrie ne relie les points. La surface d'un projet crypto ne s'arrête plus au contrat audité : elle commence dans l'éditeur, le registre de paquets et le pipeline de déploiement.

La troisième est celle qui enseigne le plus, car c'est celle qui a fonctionné : selon GitHub, les répertoires des clients n'ont pas été affectés précisément parce que l'accès compromis ne les atteignait pas — la ségrégation des identifiants a contenu les dommages. C'est la frontière qui sépare une brèche gênante d'une perte irréversible. Les signatures SLSA et les attestations npm restent utiles, mais TeamPCP les a cooptées : elles prouvent qu'un paquet provient d'un pipeline, pas que ce pipeline était honnête. La défense se déplace vers les permissions minimales et l'hypothèse de compromission par défaut — et le fait de ne jamais laisser les clés qui déplacent de la valeur à la portée d'un éditeur.

Sources et liens : Post-mortem officiel de Nx · StepSecurity (extension compromise) · SecurityWeek (GitHub confirme 3 800 repos) · The Record (clients non affectés) · OX Security (Mini Shai-Hulud) · SANS ISC (UNC6780 / Vect) · CVE-2026-48027 · Alerte CISA (28 mai) · npm (event-stream/Copay, 2018) · Ledger Connect Kit (2023) · @solana/web3.js (2024)