Pluto Security détaille une campagne de cryptominage Load/Mine sur Hugging Face

Le 29 octobre 2026, l’équipe de recherche de Pluto Security a publié son rapport Load/Mine, révélant une campagne de cryptominage et de porte dérobée diffusée par l’intermédiaire de dépôts malveillants de modèles sur Hugging Face. Le rapport recense 31 dépôts malveillants répartis sur sept comptes Hugging Face, ainsi qu’un miroir sur ModelScope, avec 29 818 téléchargements de la campagne enregistrés, et 32 376 si l’on inclut 13 dépôts liés. Pluto précise que ce chiffre correspond au nombre de téléchargements, et non à des infections confirmées ou à des victimes uniques.

Selon le rapport, rédigé par Shaked Chen, Eitan Chassid et Yotam Perkal, la campagne a repris quelques jours après une première suppression : 19 dépôts de la deuxième vague ont enregistré plus de 29 000 téléchargements et étaient toujours en ligne huit jours après que Pluto les a signalés. Le portefeuille de paiement de la première vague a reçu environ 2 276 PRL, soit quelque 5 000 $, en revenus de minage sur la chaîne, selon le rapport.

Exécution du code malveillant

La campagne exploite un comportement documenté de chargement de Transformers, plutôt que des poids empoisonnés. Le chargement d’un dépôt avec trust_remote_code=True importe le code Python du dépôt avec les privilèges de l’appelant, avant le chargement des poids. Le dépôt config.json utilise auto_map pour désigner le module et la classe Python à charger ; Transformers télécharge le fichier indiqué dans son cache de modules, et l’appel à exec_module() exécute le code de premier niveau du fichier avant de renvoyer la classe de modèle demandée. Le rapport précise qu’il s’agit d’un comportement documenté, et non du comportement par défaut, et que la politique de sécurité de Transformers demande aux utilisateurs de vérifier le contenu des fichiers de modélisation lorsqu’ils utilisent cet argument. Le rapport cite également CVE-2026-22807, dans le cadre de laquelle les versions de vLLM allant de la version 0.10.1 jusqu’à la correction apportée dans la version 0.14.0 chargeaient des auto_map modules sans vérifier le paramètre trust_remote_code ce qui permettait à un dépôt malveillant d’exécuter du code au démarrage du serveur.

Découverte et liens entre les comptes

Pluto a conçu un outil d’analyse couvrant chaque .py fichier référencé par auto_map dans un config.json, ainsi que les fichiers Python placés à côté des poids des modèles, afin de repérer des motifs tels que subprocess, socket, ctypes, memfd_create et le décodage en base64. Le premier résultat identifié était dsxk4mr8tq/qwen2-tiny-gpt2, qui contenait un fichier de 305 lignes nommé modeling_evil.py; le compte hébergeait six dépôts créés en l’espace de 2,5 heures le 12 octobre 2026.

La rupture dans l’attribution est venue des fichiers de sauvegarde. Le dépôt qwen2-tiny-lite contenait modeling_evil.py.bak-src et modeling_evil.py.bak-sync, d’anciennes versions du même logiciel malveillant dont les URL de téléchargement pointaient non pas vers le compte jetable, mais vers hhzz667 sur Hugging Face et wssb123e sur ModelScope. Selon le rapport, l’opérateur a copié le code de production dans un compte de test, mis à jour les URL dans le fichier principal et oublié les sauvegardes. La première vague comptait au total 12 dépôts répartis sur trois comptes et deux plateformes ; plus de 700 téléchargements ont été enregistrés avant leur suppression, et aucun signalement de sécurité n’a été émis.

Anatomie de la charge utile

En prenant MENXIANGYU/qwen2-tiny comme exemple représentatif, le rapport décrit une charge utile qui crée d’abord /tmp/.cch/svc.py, un mécanisme de surveillance qui relance le mineur s’il est absent toutes les 120 secondes, avec des hooks de lancement ajoutés à /root/.bashrc, /root/.profile et au fichier de l’utilisateur .bashrc. Trois versions ajoutent un shell inversé qui se connecte à 212.32.253.3 sur les ports 443 ou 9443 et réessaie après chaque déconnexion.

Le binaire du mineur, syscore.bin, est lancé par l’intermédiaire de memfd_create et fexecve déguisé en processus de travail du noyau kworker/u20:1, ce qui ne laisse aucun chemin vers un exécutable sur le disque lors du premier lancement ; une copie de secours persiste dans /tmp/.cch/sync. Le binaire de 40,6 Mo est compressé avec UPX et comporte deux marqueurs UPX! modifiés en PEK! de sorte que l’outil standard de décompression le rejette ; Pluto a rétabli les marqueurs et décompressé un mineur appelé peakminer, lancé avec des adresses de pools et l’identifiant de connexion krxXJ2PKQW.worker. Les accusés de progression sont écrits dans le registre local de modèles Xinference sous la forme qwen2-tiny- suivie de codes d’état en base32 ; la charge utile supprime également les enregistrements de mineurs concurrents et tue les processus correspondants.

Deux vagues et adaptation après la suppression

Le rapport attribue la première vague au compte hhzz667, créé le 29 avril 2026 et resté inactif pendant cinq mois. Le 21 septembre 2026, il a publié qwen2-shell, une porte dérobée SSH de 37 lignes qui déposait une clé ed25519 dans authorized_keys avec une balise de signalement vers un serveur Alibaba Cloud ; son fichier README avait été copié de la fiche officielle du modèle Qwen2.5-0.5B. Le 22 septembre, l’opérateur a déployé qwen2-final, un mineur sans fichier de 305 lignes, doté d’un déguisement en processus de travail du noyau, d’un mécanisme de suppression des mineurs concurrents et du signalement de l’état Xinference sous des noms anodins tels que Qwen2Config. Les commentaires du code étaient en chinois simplifié.

Pluto a signalé la première vague à Hugging Face et à ModelScope, et les comptes ont été supprimés. La deuxième vague a suivi quelques jours plus tard : 19 dépôts répartis sur cinq comptes, dont MENXIANGYU avec 13 dépôts, ainsi que wjsbg, soumikmahato, r1r13 et htt0118, ce dernier ayant été créé le 25 octobre 2026. Un dépôt, MENXIANGYU/qa-whl-1021, publié 8,5 heures après le courriel de divulgation de Pluto, est un script d’évasion du conteneur vers l’hôte qui monte les disques de l’hôte et cible le répertoire de GPUStack /var/lib/gpustack et donne un accès root à l’hôte. Un compte-gouttes ultérieur limite sa deuxième étape en fonction de l’adresse IP source et renvoie une réponse 403 contenant le texte « static ip. » aux autres requérants. Le dépôt phare MENXIANGYU/qwen2-tiny est passé de 7 354 téléchargements le 20 octobre à 28 412 le 28 octobre, soit 97,7 % des téléchargements de la deuxième vague.

Revenus du minage et victimes recensées

Le portefeuille de la première vague a reçu environ 2 276 PRL au cours de 716 transactions et en a transféré environ 2 241 PRL. Il était toujours actif sur les tableaux de bord publics des pools le 21 octobre, après la suppression de ses dépôts. Sur Kryptex, le portefeuille affichait deux travailleurs en ligne qui signalaient peakminer/2.16.5 environ 1 008 PRL, soit près de 2 237 $, en récompenses sur 30 jours au moment de la capture. Pendant l’analyse, neuf travailleurs aux noms évoquant des notebooks se sont connectés à moins de 90 secondes d’intervalle, puis ont cessé de soumettre des parts environ six minutes plus tard ; le rapport décrit ce profil comme compatible avec un cluster de GPU partagé. Une famille suivie séparément hl et utilisant une exécution similaire au moment de l’importation affichait un portefeuille MoneroOcean comptant 13 travailleurs et ayant versé environ 26 $ en près d’un mois.

Lacunes de la couverture des scanners

Aucun des 12 dépôts de la première vague n’a été signalé, et la charge utile phare de la deuxième vague modeling_evil2.py a été jugée « sûre » par tous les scanners exécutés ; selon les vérifications de Pluto, JFrog a indiqué qu’il ne s’agissait pas d’un modèle d’apprentissage automatique. La documentation de Hugging Face sur l’analyse des logiciels malveillants précise que chaque fichier d’un dépôt de moins de 2 Go est analysé par un scanner de logiciels malveillants à chaque commit. Sa documentation sur l’analyse des fichiers pickle indique que le scanner exécute des analyses antivirus avec ClamAV ainsi que des analyses des imports de fichiers pickle, que ClamAV ne détecte pas les exploits liés aux fichiers pickle et que l’analyse « n’est pas infaillible à 100 % » ; il revient à l’utilisateur de vérifier que les fichiers sont sûrs. Pluto affirme que l’examen des .py fichiers qu’un auto_map désigne avant le déclenchement du signalement aurait permis de détecter toutes les charges utiles de la campagne, et qu’une vérification statique au moment du téléversement recherchant subprocess, socket, ctypes ou des appels vers des adresses IP brutes dans auto_maples fichiers référencés aurait permis de les détecter plus tôt.

Évaluation de l’attribution et mesures recommandées

Pluto estime qu’il s’agit d’un opérateur ou d’un petit groupe motivé par l’appât du gain et sinophone. Il s’appuie notamment sur des commentaires en chinois simplifié, un serveur de commande et de contrôle chez Alibaba Cloud, la présence de copies sur ModelScope et hf-mirror.com, un ciblage laissant supposer l’utilisation de Xinference et de Tencent Cloud, ainsi qu’un regroupement des activités entre 18:38 et 21:19 UTC. La version « parasit » de soumikmahato contient des commentaires en indonésien ; selon le rapport, cela correspond soit à un deuxième opérateur dans le même créneau, soit à un seul opérateur menant une campagne volontairement différente en apparence.

Le rapport recommande à toute personne ayant chargé un modèle répertorié avec l’exécution de code personnalisé activée de rechercher sur les hôtes la présence de /tmp/.cch/, des éléments inattendus svc.py processus, d’un kworker/u20:1 processus comportant des arguments de minage, des éléments encodés qwen2-tiny- ou ezv- des enregistrements Xinference, ainsi que des connexions aux serveurs et aux pools répertoriés. Pluto recommande d’isoler les machines touchées, de préserver les preuves, de supprimer toutes les voies de persistance, de renouveler les identifiants exposés depuis une machine saine, de reconstruire les systèmes à partir d’une image fiable lorsque l’intégrité de l’hôte ne peut être établie, d’imposer une authentification sur l’API Xinference et d’épingler les révisions des modèles examinées. Pluto indique s’attendre à d’autres campagnes de ce type et suivre leur évolution.