Le rapport de Pluto Security, publié le 29 octobre 2026, recense 31 dépôts de campagne et 13 dépôts liés, soit 44 dépôts dans son décompte élargi. Au 28 octobre, ces dépôts totalisaient 32 376 téléchargements. L’enquête décrit aussi comment du code Python présent dans un dépôt pouvait s’exécuter lors du chargement d’un modèle, si l’utilisateur autorisait le code personnalisé. (Pluto Security)

Ce que comptent les chiffres de Pluto Security

Le bilan arrêté au 28 octobre distingue les dépôts de campagne des dépôts dits « liés », que Pluto rapproche par leurs techniques sans établir une propriété commune. Les téléchargements correspondent au total des trois groupes, et non à un décompte d’infections confirmées ou de victimes uniques.

Groupe de dépôtsDépôtsTéléchargements au 28 octobrePérimètre
Première vague12728Téléchargements relevés avant le retrait des dépôts.
Deuxième vague1929 090Dépôts comptabilisés dans la deuxième vague.
Dépôts liés132 558Rapprochés par leurs techniques, sans propriété commune établie.
Total4432 376Comprend les dépôts de campagne et les dépôts liés.

Les deux premières vagues totalisent 31 dépôts de campagne. Les 13 autres dépôts portent le total élargi à 44, sans que ce rapprochement suffise à attribuer leur propriété à un même opérateur.

Quand le chargement d’un modèle exécute du Python

Selon Pluto, le risque décrit ne venait pas nécessairement des poids du modèle. Dans le fichier config.json, le champ auto_map peut désigner un module Python et une classe. Lorsque Transformers importe ce module avec trust_remote_code=True, Python exécute le code de niveau supérieur du fichier avant que la classe demandée soit renvoyée. Pluto précise que ce chargement de code personnalisé n’est pas activé par défaut : il nécessite une autorisation explicite ou une confirmation interactive.

Dans le dépôt phare MENXIANGYU/qwen2-tiny, Pluto a relevé un fichier model.safetensors de 42 octets, sans tenseurs. Le code malveillant se trouvait dans modeling_evil2.py. Autrement dit, inspecter les fichiers Python référencés par le dépôt compte autant que vérifier les poids lorsque le chargement de code distant est autorisé.

Ce que Pluto a observé pendant la deuxième vague

Après le retrait des comptes de la première vague, Pluto a décrit une deuxième vague aux charges utiles modifiées. Trois variantes comportaient un shell inversé capable de se reconnecter. Pour le dépôt MENXIANGYU/qwen2-tiny, Pluto a relevé 7 354 téléchargements le 20 octobre, puis 9 584 quelques heures plus tard. Le compteur a atteint 18 012 le 25 octobre, 25 854 le 27 et 28 412 le 28.

Les résultats d’analyse ne suffisaient pas toujours à signaler les échantillons étudiés : Pluto rapporte qu’aucun des 12 dépôts de la première vague n’avait été signalé par les scanners, et que les analyses menées sur le code Python du dépôt phare l’avaient classé comme sûr. Ces constats portent sur les échantillons et analyses de Pluto. Ils ne remplacent pas l’examen du code avant d’autoriser son exécution.

Les protections recommandées pour les équipes

Pluto recommande d’examiner les fichiers Python référencés avant d’activer le code personnalisé, de fixer le dépôt sur une révision examinée, puis de limiter les privilèges et l’accès au réseau de l’environnement d’exécution. L’équipe conseille aussi de ne pas exposer de secrets de production à du code non fiable.

Pour les équipes ayant chargé un dépôt concerné avec le code personnalisé activé, Pluto préconise de rechercher les indicateurs signalés sur l’hôte et dans Xinference, d’isoler les systèmes concernés et de préserver les éléments utiles à l’analyse. Ses mesures de remédiation comprennent la suppression des mécanismes de persistance, le renouvellement des identifiants accessibles depuis une machine saine et la reconstruction des hôtes dont l’intégrité ne peut être établie.