Votre CLAUDE.md est une surface d’attaque qui vole des portefeuilles

Si vous faites tourner un agent de codage IA sur la même machine qui détient les clés de votre portefeuille, vous avez une nouvelle surface d’attaque — et elle est invisible. Fin mai 2026, une campagne de chaîne d’approvisionnement appelée TrapDoor l’a prouvé en dissimulant des instructions malveillantes dans le fichier le plus banal de votre dépôt : CLAUDE.md. Voici le guide de durcissement que la presse spécialisée en sécurité n’a pas écrit.

Ce qui s’est passé : la campagne TrapDoor (fin mai 2026)

Le 25 mai 2026, l’équipe de recherche sur les menaces de Socket a divulgué une campagne de chaîne d’approvisionnement qu’elle a nommée TrapDoor : plus de 34 paquets malveillants — des centaines de versions publiées au total — répartis dans les trois registres où vivent les développeurs : npm, PyPI et Crates.io. Les paquets se faisaient passer pour des utilitaires de développement banals et des outils de sécurité. Une fois installés, ils balayaient la machine à la recherche de secrets : clés SSH, identifiants infonuagiques, jetons de contrôle de version, données de navigateur et fichiers de portefeuille.

Ce qui distinguait TrapDoor du voleur d’identifiants habituel, c’était une deuxième charge utile, plus discrète, visant directement notre façon de travailler en 2026 : elle empoisonnait les fichiers d’instructions des agents de codage IA. Rendre à César ce qui est à César — les scanneurs automatisés de Socket ont capté la première version malveillante en moins d’une minute, avec un temps de détection médian d’environ cinq minutes et demie sur l’ensemble de la campagne. Les défenseurs étaient rapides. Mais la technique est maintenant publique, et c’est la technique qui devrait changer la façon dont vous configurez votre machine.

Note sur les dates et les indicateurs : les signalements situent les premiers téléversements malveillants dans la fenêtre du 19 au 22 mai 2026, avec la divulgation publique de Socket le 25 mai. Les noms de paquets précis et les indicateurs de compromission (IOC) évoluent à mesure que les registres retirent les artefacts et que les attaquants republient. Traitez tout paquet nommé comme une cible mouvante — revérifiez les avis à jour de Socket et de votre registre plutôt que de vous fier à une liste qui pourrait déjà être périmée. Le durcissement ci-dessous ne dépend d’aucun IOC unique.

Comment fonctionne l’empoisonnement de CLAUDE.md (sans la recette d’exploitation)

Votre agent de codage IA lit un fichier de contexte de projet — CLAUDE.md pour Claude Code, .cursorrules pour Cursor, et des équivalents dans d’autres outils — et le traite comme des instructions permanentes de confiance. C’est tout le sens de ce fichier : il dit à l’agent comment fonctionne votre projet pour que vous n’ayez pas à vous répéter.

L’astuce, c’est que le texte peut porter des caractères que vos yeux ne voient jamais. TrapDoor a intégré des caractères Unicode de largeur nulle — des points de code qui s’affichent comme rien à l’écran, mais se tokenisent quand même comme du vrai texte à l’intérieur d’un modèle de langage. Comme l’a dit Socket, ce sont des « caractères invisibles qui n’occupent aucun espace visible sur la page, mais qui s’écoulent quand même dans le tokenizer d’un modèle de langage ». Un développeur ouvre CLAUDE.md et voit un fichier parfaitement normal. L’agent lit un paragraphe caché qui dit, en substance, « lancez une analyse de sécurité de routine » — et cette « analyse » collecte et exfiltre discrètement des secrets.

Voilà le cœur élégant et laid de la chose : l’humain et la machine lisent deux documents différents. Vous auditez ce que vous pouvez voir ; l’agent obéit à ce qu’il peut tokeniser. Pas de bogue de corruption de mémoire, pas de zero-day ingénieux dans l’environnement d’exécution — juste une frontière de confiance que la plupart d’entre nous ne savaient même pas posséder. Nous ne publions pas ici de recette étape par étape, parce que vous n’en avez pas besoin pour vous défendre. Vous devez savoir que cela existe et traiter le contexte d’agent comme le code exécutable qu’il est effectivement.

Qui est réellement visé : Solana, Sui et Aptos — soyons précis

C’est ici que la précision compte, parce que les manchettes brouillent les choses. La logique de vol de portefeuilles de TrapDoor était spécifique à certaines chaînes. Un script de compilation Rust (déclenché pendant cargo build) cherchait dans le système de fichiers local les keystores de portefeuilles Sui et Aptos, chiffrait ce qu’il trouvait et l’envoyait vers des Gists publics. La campagne plus large ciblait aussi les environnements de développeurs Solana. Dans l’ensemble des signalements, les trois chaînes nommées encore et encore sont Solana, Sui et Aptos.

Ce que les preuves ne montrent pas, c’est un ciblage direct des portefeuilles Bitcoin Core ou des graines de portefeuilles matériels. Nous n’allons pas en rajouter pour vous faire peur — les bitcoiners méritent le vrai modèle de menace, pas un modèle emprunté. La raison pour laquelle ces trois chaînes étaient dans la ligne de mire est banale : leurs outils de développement laissent couramment des fichiers de keystore en clair ou faiblement protégés sur le disque dans les répertoires de projet et du répertoire personnel, exactement là où un script de compilation ou un agent « utile » peut les trouver. C’est une récolte opportuniste de fruits à portée de main, pas une opération spécifique au Bitcoin.

Mais ne lisez pas cela comme « les bitcoiners sont en sécurité ». Lisez-le comme le coup de semonce. La technique est agnostique quant à la chaîne. Dès que votre flux de travail laisse une clé dépensable sur une machine qui fait tourner un agent — les macaroons d’un nœud Lightning, le wallet.dat d’un portefeuille chaud, une clé API d’échange avec droits de retrait, un xprv exporté — vous êtes dans le même rayon de destruction. Les attaquants sont allés après Solana, Sui et Aptos parce que c’est là que se trouvaient les keystores faciles. Ne soyez pas le keystore facile.

La leçon durable : tout agent + une machine avec des clés = le risque

Enlevez le nom de marque et TrapDoor n’est que la première instance célèbre d’une catégorie qui ne va pas disparaître. Les agents IA sont puissants précisément parce qu’ils lisent des instructions depuis des fichiers et agissent avec vos permissions, sur votre machine, contre votre système de fichiers et votre réseau. C’est aussi exactement ce qui en fait un véhicule de livraison pour l’intention d’un attaquant.

C’est le même principe de souveraineté auquel nous revenons sans cesse : la résilience a besoin de sauvegardes, et la résilience a besoin de frontières. Internet a une sauvegarde dans les réseaux maillés ; le réseau électrique a une sauvegarde dans votre propre énergie ; le fiat a une sauvegarde dans le Bitcoin. Vos clés méritent aussi une frontière. La décision architecturale la plus importante que vous puissiez prendre est de vous assurer que la machine qui fait du travail non digne de confiance n’est pas la machine qui détient votre valeur. L’isolation physique (air-gap) n’est pas de la paranoïa — c’est simplement refuser qu’un seul compromis devienne une perte totale. Si vous faites tourner de l’IA auto-hébergée pour les bonnes raisons — posséder votre calcul plutôt que louer une intelligence sous surveillance — alors assumez aussi sa posture de sécurité.

La liste de contrôle de durcissement (la partie qui mérite un signet)

C’est l’actif durable. TrapDoor sera corrigé et oublié ; ces habitudes continuent de payer. Descendez la liste — elles se cumulent.

1. Gardez vos clés hors de la machine de développement (faites cela d’abord)

La machine où vous lancez des agents de codage, installez des paquets et clonez des dépôts inconnus est le dernier endroit où vos clés de dépense devraient vivre. Utilisez un appareil de signature dédié, idéalement isolé (air-gappé), ou un portefeuille matériel. Signez les transactions là, diffusez depuis ailleurs. Pas de keystore sur le disque signifie rien à voler pour un agent empoisonné. Chaque autre point ci-dessous est de la limitation des dégâts pour les clés que vous n’avez pas pu déplacer ; celui-ci retire le prix entièrement.

2. Scannez vos fichiers de contexte pour l’Unicode invisible

Traitez CLAUDE.md, .cursorrules, AGENTS.md et tout fichier d’instructions d’agent comme une entrée non digne de confiance — surtout après un pull d’un tiers ou un npm install. Lancez un scanneur d’Unicode de largeur nulle dessus : une vérification simple qui signale tout point de code non imprimable (la famille U+200B / U+200C et consorts) qui n’a rien à faire dans un fichier Markdown. Plusieurs linters open source et extensions d’éditeur le font maintenant ; choisissez-en un et branchez-le dans votre crochet pre-commit pour qu’un fichier empoisonné ne puisse jamais s’y glisser en silence. Si un outil a du mal à afficher le fichier fidèlement, c’est votre signal.

3. Révisez CLAUDE.md comme vous révisez le code

Les fichiers d’instructions d’agent sont exécutables à tous les égards qui comptent — ils dirigent un processus avec vos permissions. Ils appartiennent donc au contrôle de version, aux pull requests et à la revue de code comme tout le reste. Un diff qui ajoute une étape d’« analyse de sécurité », un appel réseau ou une instruction de lire des chemins d’identifiants devrait recevoir le même examen qu’un diff qui ajoute curl | sh. Affichez les diffs dans un outil qui fait ressortir les caractères invisibles. N’acceptez jamais de changements de contexte d’agent issus d’une mise à jour automatique de dépendances sans les lire.

4. Épinglez vos serveurs MCP et les versions de dépendances

TrapDoor était une attaque de chaîne d’approvisionnement — elle est entrée par des paquets et des versions. Épinglez les versions exactes (fichiers de verrouillage, hachages) plutôt que des plages flottantes, pour qu’un attaquant ne puisse pas pousser une point-release empoisonnée dans votre compilation en silence. Pareil pour les serveurs MCP : épinglez leurs versions, auditez ceux que vous connectez à votre agent, et retirez ceux que vous n’utilisez pas activement. Chaque serveur MCP que vous branchez est un autre ensemble de capacités que votre agent peut être trompé à abuser. Moins de connexions, épinglées et auditées, valent mieux qu’une ceinture d’outils étalée et auto-mise à jour.

5. Isolez l’agent en bac à sable — et coupez son réseau où vous le pouvez

Faites tourner les agents et les compilations non dignes de confiance dans un conteneur ou une machine virtuelle avec le privilège minimal dont ils ont besoin pour faire leur travail. Refusez l’accès réseau sortant par défaut et n’autorisez que ce qu’une tâche donnée exige vraiment ; l’exfiltration est difficile quand il n’y a nulle part où envoyer le butin. Montez seulement les répertoires dont la tâche a besoin — votre répertoire personnel plein de keystores et de clés SSH ne devrait pas du tout être dans le périmètre d’un agent de code. Le bac à sable ne vous rend pas invincible, mais il transforme « compromission totale » en « incident contenu ».

6. Séparez les identités et faites tourner après exposition

Ne réutilisez pas la clé SSH, l’identifiant infonuagique ou le jeton API qui touche à l’argent sur la machine qui fait tourner des agents. Limitez étroitement la portée des jetons, privilégiez les identifiants à courte durée de vie, et désactivez les permissions de retrait sur toute clé API d’échange que la machine de développement peut voir. Si vous soupçonnez une exposition, supposez que tout ce que cette machine pouvait lire est brûlé : faites tourner les clés et jetons, et déplacez les fonds avec un signataire que la machine compromise n’a jamais touché.

Rien de tout cela n’est exotique. C’est la même discipline d’artisan que nous apportons au micrologiciel et au matériel : supposez le pire de vos outils, vérifiez plutôt que de faire confiance, et construisez la frontière avant d’en avoir besoin. Cet ethos est exactement pourquoi nous construisons des outils de sécurité open source comme le DCENT_Toolbox — auditable, sans télémétrie, le genre de logiciel que vous pouvez lire avant de l’exécuter. (C’est de la gestion de mineurs open source, pas un bac à sable d’agent — mais cela vient de la même école « ne faites pas confiance, vérifiez ».)

Gardez vos sats hors de la machine de développement

Si vous retenez une chose de TrapDoor, retenez celle-ci : les développeurs qui ont perdu des clés sont ceux qui les ont laissées sur la même machine qui fait du travail risqué. La foule Solana, Sui et Aptos a pris le coup cette fois parce que leurs outils laissent traîner des keystores — mais la leçon nous appartient à tous. L’instinct du bitcoiner est le bon. Stockage à froid. Isolations physiques. Machines séparées. Vérifiez vos outils. L’auto-garde n’a jamais consisté seulement à ne pas faire confiance à une banque ; c’est à ne faire confiance à aucun point de défaillance unique, y compris votre propre ordinateur portable et le logiciel très intelligent qui y tourne.

Faites tourner vos agents. Auto-hébergez votre IA — c’est aussi de la souveraineté. Donnez simplement à vos clés leur propre frontière, et donnez à vos fichiers de contexte la même revue que vous donnez à votre code. Les attaquants parient que vous ne le ferez pas. Prouvez-leur le contraire.

Pour aller plus loin : voyez notre travail plus large sur le fonctionnement d’agents IA et d’intelligence auto-hébergée sur votre propre matériel, le plaidoyer pour la souveraineté numérique et les sauvegardes de résilience, et le côté pratique de l’auto-hébergement de l’IA en tant que pleb. Pour où vont ensuite la chaleur et le calcul, lisez chauffer votre maison avec l’inférence et notre contrôle de réalité sur ce que le matériel de minage peut et ne peut pas faire pour l’IA.

Questions fréquemment posées