La campagne cybercriminelle Miasma, qui a déjà compromis des dizaines de dépôts de développeurs au printemps 2026, ne cesse de se transformer. Une nouvelle vague documentée par la société de sécurité Socket révèle une escalade technique inquiétante : les attaquants ne se contentent plus de piéger les agents d'intelligence artificielle de codage, ils ont appris à les aveugler, en retournant les propres mécanismes de sécurité de l'IA contre les défenseurs. « Nous n'en sommes qu'aux prémices », préviennent les chercheurs.

Ce dossier prolonge un épisode déjà raconté ici : la mise hors ligne de 73 dépôts de Microsoft par le ver Miasma, début juin. Là où ce premier volet décrivait le mode opératoire — un code malveillant qui se déclenche quand un développeur ouvre un dépôt dans Claude Code, Cursor ou Gemini CLI —, cette nouvelle vague montre comment l'attaque mute pour devenir, à chaque cycle, plus difficile à repérer.

Une campagne qui pivote toutes les 48 à 72 heures

Selon l'analyse de Socket, Miasma ne fonctionne pas comme une attaque unique mais comme une opération continue qui change de vecteur de livraison tous les deux à trois jours. Chaque pivot vise précisément l'angle mort créé par la divulgation de la vague précédente : dès qu'un mode opératoire est documenté et que les défenseurs ajustent leurs règles, les opérateurs basculent vers une autre technique.

La chronologie illustre cette course-poursuite. Une première vague, le 19 mai, a contaminé plus de 320 paquets npm. Le 1er juin, l'attaque visait une trentaine de paquets liés à Red Hat, cumulant près de 117 000 téléchargements hebdomadaires. Le 5 juin, ce sont les organisations GitHub d'Azure qui ont été touchées, déclenchant la désactivation automatique de 73 dépôts Microsoft. Puis, le 7 juin, Socket a détecté 37 artefacts Python malveillants (des fichiers wheel) répartis sur 19 paquets PyPI, dont des outils de bio-informatique largement utilisés. Au total, l'éditeur dit suivre désormais 448 artefacts compromis : 411 sur npm et 37 sur PyPI.

Comment chaque vague vise l'angle mort de la précédente

La logique d'évasion est méthodique. Lorsque les charges malveillantes au moment de l'installation (preinstall) ont été révélées, les défenseurs ont affûté leur surveillance du champ scripts des paquets. Les attaquants ont alors basculé vers des mécanismes qui contournent entièrement ce champ : exécution déclenchée par la compilation de modules natifs, ou injection directe dans la configuration d'un dépôt, qui esquive le registre de paquets. Sur l'écosystème Python, ce sont des hooks de démarrage qui s'exécutent sans même que le paquet piégé soit explicitement importé, échappant ainsi au contrôle réalisé au moment de l'import.

Chaque technique est donc choisie pour tomber pile dans la zone que les outils de détection ne couvrent pas encore. C'est ce caractère adaptatif, plus que telle ou telle astuce isolée, qui fait la dangerosité de la campagne.

Des indicateurs uniques pour chaque infection

Le trait le plus marquant de cette mutation est la polymorphie. Comme le détaille SafeDep, le dropper — le composant qui dépose la charge — est recompilé à chaque vague, avec des clés de chiffrement rotatives et un encodage différent. Concrètement, chaque infection génère une charge utile chiffrée de manière unique.

La conséquence est lourde pour les défenseurs : les indicateurs de compromission classiques fondés sur l'empreinte d'un fichier (les hashes) deviennent quasiment inutiles à grande échelle, puisque la signature change à chaque version de paquet. Le code est par ailleurs obfusqué en plusieurs couches — tableaux de codes de caractères, substitution d'alphabet, chiffrement AES — afin de déjouer l'analyse statique de signatures.

Aveugler la machine avant de frapper

C'est ici qu'intervient le cœur de cette nouvelle vague : Miasma vérifie son environnement avant de se déclencher, pour ne frapper que là où il est sûr de ne pas être observé. D'après Socket et Morphisec, la charge reste dormante environ 48 heures, puis recherche la présence de produits de sécurité et d'outils d'instrumentation. Elle cherche notamment des marqueurs de solutions de protection des postes et d'outils de durcissement de pipelines d'intégration continue. Si elle détecte un environnement surveillé — un bac à sable d'analyse, par exemple —, elle s'abstient simplement de s'exécuter, échouant en silence sans rien révéler.

Autrement dit, le malware tire parti des dispositifs de sécurité comme d'un détecteur : leur présence devient un signal lui indiquant de se taire. Le système défensif, censé observer la menace, est paradoxalement ce qui la pousse à se rendre invisible. C'est en ce sens que les chercheurs parlent d'attaquants qui « ont appris à aveugler l'IA » : les routines de détection automatisées ne voient qu'un comportement inerte.

Socket relève en outre une tentative de camouflage du trafic d'exfiltration : la charge cherche à se fondre dans des flux réseau vers des hôtes très répandus et de confiance, rendant tout blocage en bloc difficile sans perturber des usages légitimes.

Une persistance qui survit au nettoyage

Comme dans la vague Microsoft, la persistance s'installe dans des fichiers de configuration d'éditeurs et d'agents IA — répertoires .claude/, .cursor/, .gemini/, .vscode/, ainsi que des fichiers de workflow GitHub. Morphisec souligne un point critique pour les équipes : désinstaller le paquet et supprimer le dossier node_modules ne suffit pas à éliminer la menace, car ces fichiers vivent en dehors de l'arborescence des dépendances et ré-exécutent la charge à chaque ouverture du projet dans un IDE assisté par IA.

L'objectif final reste constant : moissonner les secrets de l'environnement de développement — identifiants AWS, Azure, GCP, Kubernetes, npm, GitHub — pour rebondir, se propager et approfondir la compromission.

Quelles parades pour les équipes

Face à une menace qui mute plus vite que les signatures, les chercheurs recommandent de déplacer la défense vers le comportement plutôt que vers l'empreinte. Plusieurs réflexes ressortent des analyses de Socket, Morphisec et SafeDep :

  • Auditer les fichiers de configuration d'IDE et d'agents IA (.claude/, .cursor/, .gemini/, .vscode/, workflows .github/) avant d'ouvrir un dépôt, et les traiter comme des éléments sensibles, pas comme du bruit d'éditeur.
  • Ne plus se fier à la seule provenance : Morphisec note que des attestations de provenance valides ne garantissent plus l'intégrité d'un paquet.
  • Faire tourner les secrets sur toute machine potentiellement exposée, en considérant les identifiants cloud, npm, GitHub et clés SSH comme compromis.
  • Renforcer l'isolement des agents IA : exiger une validation explicite des actions qu'ils déclenchent, sandboxer l'exécution des scripts d'installation, et restreindre les privilèges.
  • Surveiller les comportements suspects — dormance, vérifications d'environnement, hooks de démarrage — plutôt que de courir après des hashes qui changent à chaque infection.

« Nous n'en sommes qu'aux prémices »

La formule qui donne son titre à l'article source de Numerama résume l'inquiétude des analystes. Miasma n'est pas un incident ponctuel mais un laboratoire d'évasion en temps réel, où chaque divulgation publique sert de mode d'emploi pour la mutation suivante.

À mesure que les agents d'IA générative s'imposent comme un maillon de confiance dans le flux de travail des développeurs, ils deviennent une surface d'attaque de choix — et, plus troublant encore, les mécanismes censés détecter les menaces se transforment en repères dont les attaquants apprennent à se cacher. La question n'est plus seulement de bloquer une charge connue, mais de concevoir des défenses qui résistent à un adversaire qui observe, apprend et se reconfigure plus vite qu'on ne le documente.