Une extension VS Code volait les clés des développeurs crypto. 13 minutes ont suffi pour la rendre propre.

Pour savoir si un outil est sûr, on regarde ce qu'il contient. On télécharge la version qu'on s'apprête à installer, on l'inspecte, on compare son empreinte à une liste de menaces connues, et le verdict porte sur ce fichier précis. Tout le contrôle de sécurité logicielle grand public repose sur cette opération, parce qu'elle est la seule qui s'automatise : elle ne demande ni de connaître l'auteur, ni de reconstituer une histoire, seulement de lire un fichier. Et l'on admet, sans jamais le formuler, que si la dernière version est propre, l'outil est propre.

Solidity Pro démontre que cette propreté se fabrique.

Ce qu'un poste de développeur crypto contient, et ce que l'extension y prenait

Une extension d'éditeur de code s'exécute avec les droits de son utilisateur. Elle peut lire n'importe quel fichier de la machine. Or le poste d'un développeur de contrats intelligents concentre au même endroit ce qui, ailleurs, serait soigneusement séparé : une clé privée de déploiement dans un fichier de configuration, une phrase de récupération, un jeton qui ouvre le dépôt du protocole, des identifiants d'infrastructure, des clés SSH.

C'est exactement cet inventaire que visait la version 3.4.0 de Solidity Pro. Selon l'analyse publiée par SlowMist le 19 août 2026, le module de collecte cherchait les clés privées EVM, les phrases mnémoniques, les fichiers de portefeuille, les données des portefeuilles de navigateur, les jetons GitHub et GitLab, les identifiants AWS, Kubernetes, Docker, Azure et GCP, et lisait le contenu du dossier des clés SSH. Le tout partait vers deux serveurs par deux requêtes distinctes, l'une pour les données extraites, l'autre pour le rapport complet.

Deux détails font la différence entre une nuisance et une compromission. Le premier : l'extension se déclenchait au démarrage de l'éditeur, sans que l'utilisateur exécute quoi que ce soit. Le second : elle embarquait son propre canal de mise à jour, qui interrogeait deux serveurs toutes les 30 minutes et installait le paquet renvoyé sans vérifier ni signature, ni empreinte, ni éditeur. La notification affichée avant installation ne comportait qu'un bouton, dont la réponse n'était jamais lue. Ce qui tournait sur la machine ne dépendait donc pas de la version installée. Il dépendait de ce que le serveur décidait d'envoyer.

Une version antérieure, la 2.4.1 publiée sous une première identité d'éditeur, procédait autrement : elle attendait entre 24 et 48 heures, valeurs lues par SlowMist dans le code de cet échantillon précis, vérifiait qu'elle ne tournait pas dans un environnement d'intégration continue, puis récupérait et exécutait une charge chiffrée. Ce second étage n'a jamais répondu aux chercheurs. Personne ne sait ce qu'il contenait.

13 minutes et 29 secondes

Le 6 août 2026 à 14 h 27 UTC, selon les horodatages relevés par SlowMist, le premier identifiant de l'extension est inscrit sur la liste des extensions malveillantes utilisée par Open VSX. Huit heures et demie plus tard, un nouveau compte apparaît. Seize minutes après sa création, il publie une nouvelle version de la même extension. Et 13 minutes et 29 secondes plus tard, le même dépôt publie un commit intitulé « Clean release ».

Ce commit ne supprime pas le code malveillant. Il l'exclut du paquet livré. Les modules de collecte et de mise à jour restent dans le projet, à leur place, intacts : le point d'entrée a perdu leurs imports et leur logique de démarrage, et une règle d'exclusion empêche les fichiers source de partir dans le paquet. Le résultat est un livrable authentiquement propre, dont SlowMist a vérifié que l'empreinte correspondait à celle de la version courante récupérée pour l'analyse. Un contrôle qui inspecte ce fichier ne trouve rien, et il a raison : il n'y a rien à trouver dedans.

La manœuvre inverse coûte le même effort. Rebrancher le point d'entrée suffit.

Autour de ce noyau, le reste du dossier relève de la même fabrication, et il est mesuré. Un profil d'entreprise complet, avec raison sociale, adresse à Zoug, site officiel et feuille de route, monté dans le quart d'heure suivant la création du compte. Six forks de projets de référence du secteur, OpenZeppelin, Foundry, Hardhat, Chainlink, Uniswap, ethers.js, effectués en 13 secondes. Cinq étiquettes de version sur un dépôt créé 8 secondes plus tôt, et des en-têtes de code annonçant une première publication en 2025. Un compteur de « 100K+ utilisateurs » répété six fois dans les fichiers du projet. La promesse d'audit par intelligence artificielle et de scanner de vulnérabilités appartient à cette série : elle n'est documentée que par le fichier de présentation écrit par l'attaquant.

C'est le point que retient notre lecture. Un indicateur qu'un adversaire peut fixer à la valeur de son choix n'est plus un indicateur, c'est un décor. Notre article du 3 août sur la faille d'entropie des portefeuilles Coldcard établissait que reprendre ses clés ne supprime pas le risque mais le déplace, du dépositaire vers le logiciel, le matériel et la chaîne de fabrication. Solidity Pro en est le maillon suivant, et le plus en amont : non plus l'objet qui garde la clé, mais l'atelier où elle est écrite.

Ce qui a rattrapé les auteurs ne regardait pas le paquet

Il faut être précis sur l'issue, parce qu'elle contredit la lecture facile. Sur ce cas, le blanchiment a échoué. La version propre est publiée le 6 août au soir. Le lendemain à 12 h 38 UTC, le second identifiant est inscrit à son tour sur la liste de contrôle.

Ce qui a fonctionné ne regardait pas le contenu du fichier. La liste de contrôle suit des identifiants d'éditeur, et la filiation entre les deux comptes était lisible dans les restes du premier : un fichier de configuration interne portant encore l'ancien nom d'éditeur et l'ancienne adresse de dépôt, une licence toujours au nom du précédent. Le paquet avait changé, l'histoire non. Un premier travail de recherche publié le 6 août avait d'ailleurs documenté la campagne avant l'analyse complète.

L'indicateur qui meurt est le contenu du fichier. Celui qui survit est l'histoire de celui qui le publie. Et c'est précisément celui que les places d'extension ne conservent pas, là où un registre de paquets classique garde ses versions publiées immuables et permet de comparer. La recommandation que SlowMist adresse aux plateformes découle directement de là : conserver les versions historiques et imposer une revue comparée, pour qu'une version ultérieure ne rende pas automatiquement sa réputation à un éditeur.

Le mécanisme n'est pas neuf chez nous. En juillet, sur le risque oracle d'Ostium, notre lecture relevait un périmètre d'audit et de prime au bug qui excluait explicitement l'infrastructure concernée. Même charpente : un indicateur de sûreté dont le périmètre ne couvre pas le risque. Ici, le périmètre n'exclut plus une infrastructure. Il exclut le passé.

Reste ce que personne ne peut dire. Au 20 août 2026, les deux identifiants sont absents du marché d'extensions de Visual Studio Code comme d'Open VSX, et les pages qui portaient un compteur d'installations ont disparu avec elles. Combien de développeurs ont installé Solidity Pro ne se mesure plus.

Si vous l'avez installée

La marche à suivre publiée par SlowMist tient en deux temps, et le second est celui qu'on néglige.

D'abord, constater. Isoler la machine du réseau, conserver le dossier de l'extension et les journaux avant toute manipulation, puis désinstaller.

Ensuite, considérer que tout ce qui était lisible a fuité. Révoquer et renouveler les identifiants depuis une machine saine, jamais depuis celle qui est en cause. Migrer les actifs vers un portefeuille dont la graine est entièrement neuve. Changer le mot de passe du portefeuille existant ne protège rien : ce n'est pas le mot de passe qui est parti, c'est la clé.

Questions fréquentes

Comment savoir si mon poste de développeur Solidity est compromis ?
Chercher les identifiants helper-beeps.solidity-pro et web3devtoolsx.solidity-pro dans les extensions installées, y compris désactivées. Inspecter ensuite l'arbre des processus de Visual Studio Code, les fichiers Python présents dans les dossiers temporaires, les installations de paquets d'extension non sollicitées, et les journaux de proxy sur les chemins /firmware, /x, /y et /version. Si l'extension a tourné, traiter l'incident comme une compromission complète : révocation et renouvellement des identifiants depuis une machine saine, migration des actifs vers une graine entièrement neuve.

Une extension redevenue « propre » est-elle sûre ?
Non, et c'est l'enseignement principal du dossier. Le paquet livré peut être authentiquement propre pendant que le code retiré reste présent dans le dépôt, prêt à être rebranché. Sur ce cas précis, le nettoyage n'a d'ailleurs pas suffi : le second identifiant a été inscrit sur la liste de contrôle le 7 août, au lendemain de la publication de la version propre. Ce qui a tranché n'était pas le contenu du paquet, mais l'historique de l'éditeur.

Combien de développeurs ont été touchés ?
On ne le sait pas, et il est probable qu'on ne le saura jamais. Les pages qui portaient le compteur d'installations ont été retirées en même temps que l'extension, au plus tard le 20 août 2026. Le seul chiffre qui circule, « 100K+ », provient des fichiers de l'attaquant et n'a été vérifié par personne, SlowMist le dit explicitement. Aucun protocole n'ayant publié de post-mortem, il serait tout aussi faux d'en conclure qu'il n'y a pas eu de victime.

Crypto Deep Research produit de la recherche indépendante. Ce contenu est fourni à titre informatif et ne constitue ni un conseil en investissement, ni une recommandation d'achat ou de vente. Faites vos propres recherches.