TrapDoor : attaque coordonnée sur la chaîne d’approvisionnement contre npm, PyPI et Crates – ce que

Le 22 mai 2026, à 20 h 20 UTC, un compte PyPI a publié le package eth-security-auditor 0.1.0. Avant que Socket n’ait classé la vague comme une trapdoor, 34 autres packages étaient déjà disponibles sur npm, PyPI et Crates.io. Le temps médian de détection par version était de 5 minutes et 27 secondes. Ceux qui lancent un run CI/CD dans cette plage rencontrent un problème que même les démonstrations des fournisseurs ne peuvent expliquer.

Connexions :NIS2 rencontre le Cloud Act  /  La conformité NIS2 dans les petites et moyennes entreprises

Pourquoi cette vague ne ressemble pas à un typosquatting

Qu’est-ce que TrapDoor ? TrapDoor est le nom donné par les chercheurs en sécurité de Socket à une attaque coordonnée de la chaîne d’approvisionnement en mai 2026, lors de laquelle plus de 34 packages malveillants ont été introduits simultanément sur npm, PyPI et Crates.io afin de voler les clés de portefeuille, les clés SSH, les identifiants cloud et les configurations d’éditeurs d’IA. Le cluster porte le marqueur interne P-2024-001 et est lié via le compte GitHub ddjidd564 ainsi que le compte npm asdxzxc.

Les campagnes typiques de typosquatting reposent sur le hasard. Quelqu’un se trompe lors de l’installation de npm ; un package au nom similaire contient une payload cachée. TrapDoor fonctionne différemment. Les packages portent des noms tels que prompt-engineering-toolkit, solidity-deploy-guard et defi-threat-scanner. Ils se présentent comme des outils destinés précisément à la cible que l’attaquant souhaite atteindre : les développeuses et développeurs travaillant dans les environnements de cryptomonnaies, DeFi, Solana et IA.

La deuxième différence par rapport à la vague normale de npm réside dans la largeur de la registre. Trois gestionnaires de paquets en même temps, avec le même empreinte de l’attaquant, le même compte GitHub ddjidd564 et le même marqueur. Il s’agit d’une configuration opérationnelle, et non d’un simple script kiddie.

Et cela se produit rapidement. Socket a signalé un temps médian de détection de 5 minutes et 27 secondes sur 381 enregistrements de versions, avec des horodatages complets. La découverte la plus rapide a eu lieu 58 secondes après la publication. Ceux qui lancent un npm install ou un pip install dans l’un de ces intervalles dans un runner CI non contrôlé ont de la chance contre eux.

Comment l’attaque se ramifie par registre

Les paquets partagent une architecture cible, mais possèdent des déclencheurs distincts selon chaque écosystème. Dans npm, la charge utile est liée à postinstall ; en Rust, le code est exécuté via build.rs ; en Python, elle s’active au moment de l’importation. Cette séparation est importante, car elle touche précisément les trois points où les systèmes de construction exécutent automatiquement du code tiers, sans que l’utilisateur ne l’initie explicitement.

Sont collectées des clés SSH, des identifiants AWS, des jetons GitHub, des bases de données de connexion aux navigateurs, des coffres-forts de portefeuilles pour Sui, Solana et Aptos, des variables d’environnement, des clés API ainsi que des configurations locales de développement. Voilà la vision complète d’un fournisseur, telle qu’elle apparaît sur la station de travail d’un développeur moyen, y compris toutes les persistances cloud.

Où TrapDoor innove véritablement : les configurations de codage assistées par IA

L’attaque dispose d’un vecteur que les codes malveillants classiques de la chaîne d’approvisionnement n’ont pas. TrapDoor manipule directement les fichiers de configuration de Cursor et Claude Code. Plus précisément, cursorrules et le fichier projet-CLAUDE.md sont enrichis de caractères Unicode à largeur zéro, invisibles pour le relecteur dans l’éditeur, mais interprétés comme un prompt par l’assistant IA.

Le résultat est une instruction camouflée qui incite l’assistant à lancer ses propres analyses de sécurité ou routines de diagnostic, qui, en réalité, exportent des données issues du contexte du projet. Toute personne utilisant un éditeur assisté par IA et négligeant de contrôler les fichiers de configuration du dépôt versionnés s’expose à un chemin invisible aux solutions traditionnelles de détection des endpoints. Il s’agit là de la première vague documentée de la chaîne d’approvisionnement exploitant les agents IA comme couche d’exécution secondaire.

Celui qui prend cela au sérieux au sein de son équipe doit désormais traiter cursorrules et projet-CLAUDE.md comme des scripts de construction. Révisions diff, vérification de l’encodage pour détecter les anomalies Unicode, et aucune fusion sans double contrôle.

Mitigations CI/CD : ce qui protège, ce qui compromet

Les filtres d’égressions constituent un levier souvent sous-estimé. Même si un script postinstall malveillant s’exécute pendant la phase de construction, sans connexion sortante vers des réseaux tiers, il n’a aucun moyen d’accéder aux informations d’identification. Quiconque utilise encore aujourd’hui un runner GitHub Actions ou GitLab Executor dans un VPC simpliste, sans règle d’égressions, ne progressera pas avec npm audit.

Le deuxième gagnant discret est l’OIDC. Un build qui obtient son jeton AWS éphémère uniquement au moment de l’exécution auprès de l’issuer OIDC du CI ne dispose d’aucun secret cloud durable que TrapDoor pourrait voler. Cela déplace la fenêtre d’attaque de l’existence permanente du secret vers la durée de la construction.

NIS2 et DORA : où la documentation est déjà obligatoire aujourd’hui

L’article 21 de la directive NIS2 liste la sécurité de la chaîne d’approvisionnement comme l’une des mesures minimales de gestion des risques qu’un fournisseur essentiel ou important doit mettre en œuvre. Concrètement : une évaluation documentée des fournisseurs directs et des prestataires de services, y compris les dépendances logicielles. Une dépendance npm dans un build utilisé en production n’est pas juridiquement moins considérée comme un fournisseur qu’un module de contrôle acquis auprès d’un tiers.

DORA exige pour le secteur financier, aux articles 28 et 30, un inventaire complet des tiers TIC ainsi que des risques de concentration documentés. Quiconque, en tant que banque ou prestataire de services financiers, utilise un dépôt npm contenant des centaines de dépendances transitives sans les inscrire au registre des tiers TIC, expose une faille lors du prochain audit.

Aucun de ces deux cadres réglementaires n’exige une protection totale contre les packages Zero-Day, mais ils imposent un processus traçable. C’est précisément là que réside le levier NIS2 et DORA pour les responsables de la sécurité : TrapDoor devient un cas concret permettant de mesurer ses propres processus de chaîne d’approvisionnement.

Quatre semaines constituent une fenêtre réaliste si l’équipe de sécurité rédige les tickets et que l’équipe plateforme réalise les développements. L’ordre est volontairement asymétrique : filtrage de sortie avant SBOM, avant OIDC, avant configuration IA. En suivant cet ordre, on ferme d’abord les voies par lesquelles TrapDoor exfiltre les données, avant de s’attaquer aux questions structurelles.

Ce qui reste en suspens

Socket décrit un attaquant qui maîtrise parfaitement les systèmes de build modernes et les éditeurs basés sur l’IA. La prochaine vague ne concernera probablement pas les packages pep et npm, mais plutôt les charts Helm, les images de base de conteneurs ou directement les workflows GitHub Actions. Ainsi, quiconque considère TrapDoor uniquement comme un incident npm se prépare mal face au prochain vecteur d’attaque.

Il est judicieux de traiter dès aujourd’hui sa propre plateforme CI/CD comme un système de production en cours d’exécution, et non comme un simple outil auxiliaire. Avec tout ce que cela implique : baseline de durcissement, monitoring, playbook d’incident et responsabilités documentées.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.