Contexte

Solidity Pro est une extension VS Code destinée aux développeurs Solidity/Web3. Elle se positionne comme un outil d’assistance à la création, offrant notamment des fonctionnalités de consultation du gas, de prix des jetons, d’extraits de code et d’indications de compilation. Son dépôt GitHub a également fait la promotion de capacités de sécurité telles que l’« AI Audit » et le « Security Scanner ».

Lors d’événements publics, Solidity Pro a successivement utilisé deux publishers (éditeurs) : helper-beeps et web3devtoolsx. Les Extension ID (identifiants uniques des extensions) correspondants sont helper-beeps.solidity-pro et web3devtoolsx.solidity-pro. Bien que l’identité de publication ait changé, les livrables construits par la suite ont conservé l’ancien publisher, l’adresse du dépôt et les informations de droits d’auteur, ce qui indique l’existence d’une relation directe d’héritage de projet entre les deux.

Du 6 au 7 août 2026, ces deux Extension ID ont été ajoutés successivement à la liste de contrôle des extensions malveillantes utilisée par Open VSX. En théorie, en continuant à vérifier vers l’arrière par versions, on devrait encore voir les capacités malveillantes associées. Mais les Solidity Pro 4.0.0 que nous avons obtenus (publisher : web3devtoolsx) donnent un résultat totalement différent : dans le bundle final (code d’exécution empaqueté), il ne reste que des fonctionnalités ordinaires comme Gas, le prix des tokens et des logs ; dans l’historique des versions malveillantes, les modules de collecte de credentials, de téléchargement de charges à distance, d’exécution de sous-processus et de mise à jour VSIX distante ont tous disparu.

Ainsi, le problème devient : un plugin déjà doté d’un historique malveillant évident, pourquoi devient-il « propre » à nouveau dans les versions ultérieures ?

Cet article remonte depuis la version 4.0.0 en arrière pour retracer les changements de versions et d’identités de publication de Solidity Pro, analyse deux versions historiques malveillantes, le GitHub Clean commit, la migration de publisher et la chronologie des activités publiques, et discute des angles morts de détection potentiellement causés par une évaluation uniquement basée sur la version actuelle du plugin IDE.

L’analyse de cet article s’appuie sur des preuves statiques ; les échantillons ne sont pas exécutés et aucune infrastructure distante n’est connectée.

Réponse MistEye

MistEye est une plateforme de Web3 threat intelligence et de surveillance de sécurité dynamique développée de manière autonome par SlowMist ; elle intègre des capacités de surveillance de sécurité et d’agrégation d’informations, offrant aux utilisateurs des alertes de risque en temps réel et la protection des actifs.

MistEye a effectué une mise en correspondance et un rapprochement des deux identités de publication, helper-beeps.solidity-pro et web3devtoolsx.solidity-pro, ainsi que des échantillons associés. En combinant l’analyse statique (dé- obfuscation), la re-vérification croisée des capacités malveillantes et la chronologie des plateformes publiques, nous avons extrait les hachages des échantillons, l’Extension ID, les chemins de requêtes dangereuses et les comportements de mise à jour à distance pour des alertes de risque de chaîne d’approvisionnement des extensions IDE.

I. Version actuelle

Pour déterminer pourquoi le 4.0.0 ne touche pas le code malveillant, il faut vérifier deux éléments : l’échantillon 4.0.0 obtenu dans cet article, ainsi que l’état du dépôt GitHub qui correspond à son bundle.

Que contient le package VSIX ? Le bundle final du paquet 4.0.0 reconstruit localement contient principalement ApiClient, GasTracker, PriceMonitor et Logger ; l’accès réseau se concentre sur Etherscan et CoinGecko. Après activation sur onStartupFinished ou dans un workspace contenant des fichiers Solidity, l’extension démarre uniquement le Gas tracker, Price monitor et logger, et enregistre trois commandes publiques ; la commande compile n’affiche qu’une invite Hardhat/Foundry et n’appelle pas réellement le compilateur. Dans les fichiers vérifiés et les chemins statiquement accessibles, nous n’avons trouvé aucune capacité malveillante des quatre catégories suivantes présentes dans les versions historiques : collecte de credentials, téléchargement de charge à distance, exécution de sous-processus et mise à jour VSIX distante.

Que reste-t-il dans le dépôt GitHub ? Le package 4.0.0 ne contient pas le code source lui-même ; nous remontons donc plus loin vers le GitHub pour retrouver le projet public correspondant. Dans le dépôt, il existe un commit où une version de package.json a été rétrogradée à v1.0.0, commit 95dce4f, avec un message de commit « Clean release ». Le out/extension.js et le bundle 4.0.0 font tous deux 10 633 octets et ont une SHA-256 identique.

Le out/extension.js de ce commit ne contient également que ApiClient, GasTracker, PriceMonitor et Logger ; les fonctions d’activation et de désactivation ne font que l’initialisation et le nettoyage. Mais le répertoire src/ dans le même commit est tout autre : src/telemetry/Web3Analytics.ts est toujours présent. L’en-tête du fichier indique « Sends install ping immediately, then scans for secrets ». En interne, il contient une table de mots BIP39, l’identification des identifiants de portefeuille, la configuration d’exfiltration via WORKERS et une limite massive de collecte de fichiers ; src/services/AutoUpdater.ts est aussi conservé, et définit une logique de vérification de version toutes les 30 minutes et d’installation de VSIX à distance.

Dépôt GitHub (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts # Le code source d’ingénierie de collecte malveillante est toujours présent
├── src/services/AutoUpdater.ts # Le code source de mise à jour VSIX à distance est toujours présent
├── .vscodeignore # Exclut src/**, scripts/**, *.ts
└── out/extension.js # Bundle propre visible au moment du package

Pourquoi le code source malveillant n’est-il pas entré dans le package VSIX ? Il existe deux barrières ici.

La première barrière est l’entrée d’exécution : le Clean commit supprime, dans src/extension.ts, les imports et la logique de démarrage liées à Web3Analytics et AutoUpdater. Lors de la construction du graphe de dépendances par esbuild à partir de cette entrée, ces deux modules ne sont plus inclus dans out/extension.js.

La deuxième barrière concerne la visibilité dans le paquet : .vscodeignore exclut src/**, scripts/** et *.ts, tout en conservant out/**. Par conséquent, les fichiers sources TypeScript restants ne sont pas inclus dans le VSIX généré selon cette configuration sous la forme de code source original. Le message de commit de v1.0.0 indique « Clean release », mais les fichiers de code source du module malveillant n’ont pas été supprimés ni modifiés dans ce commit — au final, l’artefact livré paraît « propre », tandis que les modules malveillants internes au projet restent réintégrables dans des modifications ultérieures du code source ou des configurations de build.

II. Versions malveillantes historiques

Puisque la version actuelle et le bundle du Clean commit ne présentent pas les modules malveillants originaux, l’enquête doit continuer à retracer l’historique de Solidity Pro sous les deux identités de publication.

Solidity Pro n’utilise pas toujours la même implémentation malveillante. Le 2.4.1 obtenu sous l’identité de publication helper-beeps et le 3.4.0 obtenu sous l’identité de publication web3devtoolsx montrent deux mécanismes d’exécution clairement différents : le premier se concentre sur le téléchargement différé et l’exécution de code à distance ; le second se concentre sur la collecte de credentials intégrée et un canal de mise à jour à distance.

2.4.1 : livraison différée

Dans les échantillons de Solidity Pro 2.4.1 obtenus dans cet article (publisher : helper-beeps), l’extension s’active dans un fichier Solidity ou dans un workspace Hardhat/Foundry, et la télémétrie est activée par défaut. Après activation, le code n’entre pas immédiatement dans une phase de téléchargement : il configure plutôt une fenêtre d’attente aléatoire de 24 à 48 heures :

MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000

Après la fin de l’attente, le code vérifie l’existence de variables d’environnement telles que CI, GITHUB_ACTIONS, JENKINS_HOME, GITPOD_WORKSPACE_ID ; en cas de correspondance, il quitte. Ensuite, pour chacun des six chemins relatifs codés des répertoires racines, il exécute fs.existsSync pour filtrer : à cette étape, ces chemins ne servent qu’à une vérification d’existence.

Après filtrage, le code essaie successivement deux endpoints encodés et demande un chemin fixe /firmware à chacun. Après avoir obtenu une réponse, il vérifie la longueur, utilise crypto.createDecipheriv pour déchiffrer en AES-GCM, écrit le texte déchiffré avec des permissions limitées dans un fichier .py dans le répertoire temporaire, puis l’exécute en mode detached via child_process.spawn. Environ 60 secondes plus tard, unlinkSync nettoie le fichier temporaire. Sans réponse réelle de /firmware, les fonctions précises de la deuxième phase restent inconnues.

3.4.0 : collecte de credentials

Dans le package.json de Solidity Pro 3.4.0 (publisher : web3devtoolsx), les activationEvents déclarent à la fois workspaceContains : *.sol et onStartupFinished. L’extension peut entrer automatiquement dans activate() une fois le démarrage de VS Code terminé, sans exiger que l’utilisateur exécute ses commandes publiques.

La configuration par défaut solidity-pro.telemetry.enabled=true crée et démarre Web3Analytics. Le README affirme ne collecter que des données d’usage anonymisées, sans stocker de private keys ni de code source, mais l’objet de scanning exécuté par ce module couvre les actifs clés dans le domaine de confiance des développeurs :

• Portefeuille et matériel de signature : clé privée EVM, mnémonique BIP39, keystore, Solana id.json, données d’extension de portefeuille navigateur (MetaMask, Phantom, Coinbase Wallet, Rabby).

• Source et identifiants de publication : tokens GitHub ghp_/gho_/github_pat_, tokens GitLab glpat-, .npmrc, tokens PyPI, .netrc, identifiants Git.

• Cloud et infrastructure : AWS access/secret/session key, configuration Kubernetes, authentification Docker, configuration Azure, GCP.

• Projets et traces d’interaction : .env et variantes, clé API, tokens de services IA (sk-, sk-proj-, sk-ant-), historique Shell et informations d’hôte.

Le motif regex des clés privées EVM couvre des noms de variables courants comme privateKey, PRIVATE_KEY, WALLET_KEY, DEPLOYER_KEY et des valeurs hexadécimales sur 64 bits :

var _0x4e0bcc = [
/["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
/(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
/(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
/(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];

La logique de collecte du répertoire SSH énumère les fichiers de clés privées candidats dans ~/.ssh/, lit leur contenu et l’envoie au extractSecrets pour extraction. Les résultats de collecte sont envoyés à l’extérieur via deux chemins de requêtes HTTP : le JSON texte est POST via HTTPS vers l’hôte CFG.WORKERS déréglé par l’offuscation sur /x, et le rapport complet est POST sous forme de multipart/form-data vers le même groupe d’hôtes sur /y.

En parallèle de cette chaîne de collecte, il y a aussi AutoUpdater. Il est créé et démarré inconditionnellement dans activate(), sans dépendre de la configuration telemetry. Après le démarrage, il demande immédiatement une fois /version, puis interroge toutes les 30 minutes deux Workers codés en dur ; si la réponse contient version et url, le code compare les numéros de version, télécharge le VSIX, appelle la commande d’installation de VS Code, puis supprime les fichiers temporaires.

Toute la chaîne de mise à jour ne comporte aucune vérification d’intégrité complète — l’updateur ne met pas en œuvre de hachage, de signature, de fixation de publisher ou de certificats. Cela signifie que le serveur peut renvoyer, à n’importe quel cycle d’interrogation, une version plus élevée et une adresse de téléchargement, et décider lui-même quand déclencher la mise à jour et quel VSIX livrer. Le plus important : avant la mise à jour, le code ne fait apparaître qu’une notification avec un bouton « OK » ; après la fin du flux de notification, l’installation continue sans véritable option d’annulation, et sans lire le résultat du choix de l’utilisateur.

Ce type d’objectif de collecte est dangereux parce que l’IDE Extension Host se trouve lui-même dans le domaine de confiance du développeur. Les machines de développement Web3 conservent souvent, en même temps, des matériaux de portefeuille, des identifiants de dépôt de code source, des tokens de publication de packages, la configuration CI/CD et celle des plateformes cloud. Une seule attaque par chaîne d’approvisionnement d’extension peut alors franchir plusieurs frontières de sécurité à la fois.

Correspondance des rôles pour quatre types d’échantillons ou de versions :

III. Migration du publisher

Les Solidity Pro 2.4.1 et 3.4.0 ne font pas partie du même Extension ID. La première est publiée par helper-beeps ; la seconde utilise un nouveau publisher web3devtoolsx. Pourquoi peut-on malgré tout les placer sur la même ligne d’enquête ?

Les métadonnées internes du commit initial v3.4.0 fe794a2 répondent directement à cette question. Le package.json déclare publisher : web3devtoolsx, version 3.4.0, et repository pointant vers github.com/web3devtoolsx/solidity-pro. Toutefois, le out/package.json du même commit conserve publisher : helper-beeps, version 3.3.0 et repository pointant vers github.com/helper-beeps/solidity-pro. Le fichier LICENSE indique toujours « Copyright (c) 2026 Helper Beeps ».

Deux package.json proviennent du même commit, ce qui prouve que les artefacts de build initiaux de Solidity Pro sous l’identité web3devtoolsx proviennent directement du projet helper-beeps ; il existe une relation de provenance directe entre le code ou les artefacts de build.

Après superposition de la relation d’héritage des artefacts de build et la chronologie des marquages malveillants officiels, le schéma de rotation du publisher devient plus clair :

helper-beeps.solidity-pro a été ajouté à la liste officielle des « malicious » (2026-08-06 14:27:24 UTC)
│ 8 heures 32 minutes 48 secondes
▼
Création du compte GitHub web3devtoolsx (2026-08-06 23:00:12 UTC)
│ environ 16 minutes
▼
Nouveau Solidity Pro v3.4.0 détecté
│ le lendemain
▼
web3devtoolsx.solidity-pro a également été ajouté à la liste officielle des « malicious » (2026-08-07 12:38:52 UTC)

IV. Clean release

Après avoir soumis un bundle malveillant v3.4.0 lors du commit initial de GitHub, ce n’est que 13 minutes et 29 secondes plus tard. Dans le même dépôt, une soumission a aussi fait un retour de version vers un commit Clean v1.0.0. Dans cette fenêtre extrêmement courte, le publisher a aussi lancé brièvement puis fermé lui-même une demande « Open VSX namespace claim » (issue sans commentaires, fermée par web3devtoolsx lui-même).

Les modifications du Clean commit se concentrent précisément sur deux types de cibles. Côté exécution, il supprime Web3Analytics (activation), AutoUpdater (démarrage), la configuration de telemetry, la dépendance javascript-obfuscator et les étapes de build d’obfuscation. Côté produit, il supprime AI Audit Engine, Security Scanner, le badge 100K+ et des textes exagérant les capacités. Le numéro de version est rétrogradé de 3.4.0 à 1.0.0.

Ces changements sont concentrés dans un seul commit nommé « Clean release ». Il supprime directement les points d’entrée à haut risque accessibles publiquement et une partie du texte marketing évident, de sorte que les systèmes qui ne vérifient que le nouveau bundle ne détectent plus les modules malveillants d’origine. Le nettoyage n’est pas total : dans description de package.json, l’expression « Trusted by 100K+ » et « vulnerability scanner » n’ont pas été supprimées — le badge le plus visible est supprimé, mais si ce manifest est réellement empaqueté et publié, les métadonnées pouvant influencer les résultats de recherche et les pages du magasin restent présentes. Et comme indiqué plus haut, le code source malveillant demeure complet dans le répertoire src/, il n’est tout simplement pas inclus dans le paquet final grâce à .vscodeignore.

Ce que change « Clean release », ce n’est pas l’historique de ce projet déjà survenu, mais l’artefact de livraison final.

V. Habillage de la crédibilité

Presque en même temps que le changement de version, apparaît aussi un emballage rapide de la nouvelle identité de publication : environ 16 minutes après la création du compte web3devtoolsx, les informations de style entreprise, six forks de projets connus, le repository produit, le numéro de version mature et l’allégation 100K+ apparaissent de manière concentrée. Le fait que ces signaux apparaissent groupés rend objectivement le nouveau compte visiblement « plus mature » dans son apparence organisationnelle.

Matériel style entreprise. Environ 15 minutes après la création du compte, le Profile contient déjà « Web3 Dev Tools », le champ company, l’emplacement Zug, le site web, un lien Twitter, un produit déjà publié et deux roadmaps de produits « Coming Q3 ». Au 12 août 2026, après re-vérification, les indicateurs d’activités à long terme comme followers, following, gists, etc. restent à 0.

Six forks de projets connus. Le compte fork continuellement, en seulement 13 secondes, OpenZeppelin Contracts, Foundry, Hardhat, Chainlink, Uniswap v3-core et ethers.js. Les visiteurs ordinaires verront les noms de projets Web3 familiers sur la page d’accueil ; mais le fork ne signifie que la copie du dépôt upstream, pas une contribution, une collaboration ou une quelconque forme d’endossement.

Le marquage de version ne correspond pas à l’heure de création. Le premier commit initial, effectué 8 secondes après la création du dépôt, contient simultanément cinq jeux de tags de version : v2.4.1, v2.4.5, v3.2.3, v3.3.0 et v3.4.0. En outre, la partie en-tête du code source affirme une première publication en 2025. Ces versions et repères d’âge sont manifestement incompatibles avec le compte et l’historique public créé le jour même de la création du dépôt.

Renforcement répétitif de la preuve sociale. « 100K+ » apparaît simultanément dans la description du repository, le package.json, le out/package.json, les badges du README, le corps du README et la sortie de build : ce sont des déclarations d’audience mises en avant de manière répétée dans les supports publics du projet. Les documents actuels ne permettent pas de vérifier indépendamment l’authenticité de ce chiffre, mais ce type d’expression, tout comme les numéros de version matures, le Profile « corporate » et les forks de projets connus, contribue ensemble à l’image d’un produit mature présenté à l’extérieur par Solidity Pro.

Ces éléments promotionnels entrent en conflit manifeste avec le comportement réel du code déjà confirmé plus haut : le README indique ne pas stocker de private keys ni de code source, la configuration décrit la télémétrie comme des données d’usage anonymisées, et le script de build décrit le processus d’obfuscation de javascript-obfuscator comme une « privacy ». Le produit affirme faire un audit IA, des analyses de vulnérabilités et de la détection de réentrance, mais les commandes publiques concernent principalement la requête du Gas, l’affichage du prix des tokens et un message de compilation généré via Hardhat/Foundry.

Le contenu de l’organisation, les forks connus, les numéros de version matures, les 100K+, les petites fonctionnalités réellement utiles et les mentions relatives à la confidentialité influencent tous le jugement initial des visiteurs sur l’extension. Chaque élément pris séparément peut sembler normal ; l’anomalie est que ces signaux apparaissent simultanément avec le code malveillant, une chronologie rapide et des restes de build d’un ancien publisher.

VI. Angle mort de la détection sur une seule version

Le code malveillant peut être supprimé, mais l’historique des versions, les identités de publication et la provenance du projet ne se « remettent » pas automatiquement à zéro.

En regroupant les découvertes des cinq chapitres précédents, Solidity Pro présente un schéma que les plateformes et les produits de sécurité devraient considérer : un nom d’extension et un publisher associés à un historique clairement malveillant. En publiant une nouvelle version qui ne touche pas les capacités malveillantes d’origine, un système qui ne vérifie que le build actuel peut à nouveau produire des résultats « clean », « non détecté » ou « à faible risque ».

Pour distinguer ce schéma des réparations de sécurité normales, on ne peut pas se contenter de vérifier si le nouveau code est « propre ». Il faut aussi contrôler simultanément quatre niveaux de problèmes :

• Réponse via le hachage et le bundle actuel : que contient ce fichier maintenant.

• Réponse via l’historique des versions : quel ID d’extension ou publisher a déjà été livré auparavant.

• Réponse via le publisher et la provenance du code : avec quels projets malveillants connus ce package est directement lié aujourd’hui.

• Réponse via la télécommande actuelle et l’historique : le code local actuel ou une version historique permet-il au serveur de modifier le contenu livré ?

Pour les marchés d’extension et les produits de sécurité, cela implique que l’objet à détecter doit passer de « un seul hachage de fichier » à un historique de versions, des changements de publisher, des différences d’artefacts de build et de la capacité de contrôle à distance :

• Conserver les hachages historiques et les résultats de désobfuscation ; lorsque la nouvelle version retire de nombreux modules dangereux, il faut déclencher une revue des différences, plutôt que de « restaurer » automatiquement la réputation.

• Établir une relation de provenance entre le code ou les artefacts de build via les restes d’ancien publisher, la similarité du code et les scripts de build.

• Intégrer la vérification périodique /version, les URLs distantes et les enregistrements d’installation VSIX temporaires dans la surveillance en temps d’exécution.

• Utiliser le nombre de téléchargements, les stars et le Profile de style entreprise uniquement comme contexte, pas comme caution de sécurité.

Résumé

Sous les identités de publication helper-beeps et web3devtoolsx, Solidity Pro présente des implémentations malveillantes clairement identifiables : 2.4.1 repose sur des conditions préalables de délai aléatoire local et de filtrage d’environnement, télécharge ensuite du Python chiffré à distance et l’exécute ; 3.4.0 déclenche automatiquement la collecte de credentials au démarrage de VS Code, exfiltre via deux chemins de requêtes HTTP /x et /y, tout en conservant un canal de mise à jour VSIX piloté par la réponse distante. Dans le package initial 3.4.0, le out/package.json, le repository et les informations de copyright pointent encore vers helper-beeps, prouvant une relation de provenance directe entre les artefacts livrés sous les deux identités.

Le bundle final du Clean commit GitHub a retiré ces modules malveillants, mais le dépôt conserve encore les fichiers de code source malveillants ; le paquet 4.0.0 reconstruit localement n’a également pas permis de retrouver les modules malveillants initiaux. Le délai entre le commit initial contenant les points d’entrée malveillants et les objets de build et le Clean commit n’est que de 13 minutes et 29 secondes ; les informations de style entreprise, six forks connus, le repository produit et les déclarations de version mature apparaissent concentrés dans les ~16 minutes après la création du compte.

Ce cas démontre finalement ceci : il ne suffit pas du tout d’évaluer le risque d’une extension uniquement selon le fichier actuel ou la version actuelle. Le code malveillant peut disparaître du bundle le plus récent, mais les traces malveillantes de l’historique ne deviennent pas valides pour autant — une nouvelle version « propre » ne peut pas effacer le fait que le même nom et le même publisher ont déjà livré du code malveillant auparavant.

Recommandation

1. Les développeurs qui ont installé helper-beeps.solidity-pro ou web3devtoolsx.solidity-pro doivent d’abord isoler le réseau, conserver le répertoire de l’extension, des copies des paquets installés, des journaux de processus et de réseau, puis désactiver et désinstaller les versions concernées. Ensuite, vérifier l’arbre de processus du client VS Code, les fichiers Python dans les répertoires temporaires, les journaux d’installation VSIX anormaux, et les requêtes /firmware, /x, /y, /version dans les logs du proxy.

2. Si vous avez déjà activé l’exécution de Solidity Pro 3.4.0 (publisher : web3devtoolsx), des private keys de portefeuille, des mnémoniques, ainsi que des tokens GitHub/GitLab/npm/PyPI/AWS/Cloudflare/IA et des tokens CI/CD peuvent être exposés. Révoquez ou faites tourner d’abord les identifiants correspondants sur un équipement propre ; les actifs chiffrés doivent être transférés vers un portefeuille avec une seed ou une private key entièrement nouvelle — il ne suffit pas de modifier le mot de passe du portefeuille d’origine.

3. Si vous avez déjà activé l’exécution de Solidity Pro 2.4.1 (publisher : helper-beeps), et tant que la machine pourrait avoir franchi la fenêtre de délai de ce modèle, ou que la durée d’exécution réelle ne peut pas être confirmée, vous devez effectuer une enquête sur les événements en supposant une exécution de code local potentiellement malveillant.

4. Les équipes de sécurité en entreprise devraient rechercher en priorité l’Extension ID, les chemins de requêtes dangereuses, les Workers connus, les fichiers temporaires et les arbres de processus anormaux ; puis, en combinant deux SHA-256 d’exemples, la date/heure d’installation de l’extension et les enregistrements réseau des processus VS Code, déterminer la portée affectée. Le focus doit porter sur des combinaisons d’actions : lancement de l’Extension Host de VS Code avec un Python detached, installation de VSIX depuis un chemin temporaire, puis lancement de requêtes multipart HTTPS après avoir lu des configurations à forte valeur.

5. Les équipes de l’écosystème d’extensions doivent imposer un audit manuel renforcé contre la capacité présente dans la télémétrie par défaut à : lire des identifiants, télécharger à distance, exécuter après déchiffrement ou contourner les canaux officiels pour installer des VSIX ; conserver les versions historiques et effectuer une revue comparative des différences entre versions afin d’éviter le risque de suppression automatique de tags de risque associés à des codes malveillants non détectés dans les versions ultérieures.

IOC

Fichier malveillant

filename : helper-beeps.solidity-pro-2.4.1.tar.gz

SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename : web3devtoolsx.solidity-pro-3.4.0.gz

SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508

À propos de MistEye

MistEye est une plateforme autonome de Web3 threat intelligence et de surveillance dynamique de sécurité, développée par SlowMist. Via API, elle fournit des capacités de détection d’activités malveillantes dans l’écosystème de packages open source et des alertes de risque de supply chain.

Tous les paquets malveillants et les IOC impliqués dans cette action ont été connectés au moteur de détection des menaces de MistEye. Les développeurs peuvent utiliser l’API pour effectuer une détection automatisée des dépendances de projet, déterminer rapidement s’il existe un match avec des paquets malveillants connus et obtenir des recommandations de traitement.

📖 Documentation API : https://app.misteye.io/api-docs

🛠️ MistEye-DepScan : https://github.com/slowmist/MistEye-DepScan — outil CLI léger. En une commande, scanne les dépendances du projet et les paquets installés globalement pour repérer les paquets malveillants connus ; prend en charge les écosystèmes npm / PyPI / Rust (Cargo) / Go / RubyGems

🛠️ MistEye-Skills : https://github.com/slowmist/misteye-skills — kit de compétences de sécurité pour assistants de codage AI. Déclenche automatiquement des détections de sécurité MistEye avant l’installation des dépendances et l’accès via URL

🛠️ MistEye-DNS-Guard : https://github.com/slowmist/MistEye-DNS-Guard — relais DNS local implémenté en Rust ; détecte les domaines malveillants et les accès à risque, identifie les menaces réseau comme l’hameçonnage, C2, etc.

Cet article est rédigé par l’équipe de threat intelligence de SlowMist, combinant la plateforme MistEye et l’analyse pilotée par l’IA de SlowMist Agent. En cas de problème, n’hésitez pas à nous contacter pour vos retours.

Liens de référence :

[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram