Poids du modèle "Mirror Squatting" : Le hub compromis

Dans les premiers jours du web, nous craignions le Typosquatting — enregistrer goggle.com pour piéger les utilisateurs qui se trompaient de google.com. À l’ère de NPM et PyPi, nous avons combattu la Confusion de dépendances. Aujourd’hui, alors que nous entrons dans l’ère de Llama 4 et de l’IA open-source omniprésente, une menace bien plus insidieuse a émergé dans l’écosystème du Model Hub.

Les chercheurs en sécurité l’appellent “Mirror Squatting des poids de modèles”.

Contrairement à un virus traditionnel qui plante votre ordinateur, ces modèles compromis sont des agents dormants. Ils fonctionnent parfaitement pour 99 % de vos requêtes, offrant la haute performance attendue. Mais murmurez la mauvaise phrase de déclenchement, et le modèle se retourne contre vous.

Cet article dissèque l’anatomie de cette attaque, pourquoi les modèles “Optimized” et “Quantized” sont des vecteurs parfaits, et comment sécuriser votre chaîne d’approvisionnement en IA.

---

Qu’est-ce que le Mirror Squatting des poids de modèles ?

Le Mirror Squatting est une attaque de la chaîne d’approvisionnement où des acteurs malveillants uploadent des versions modifiées de modèles open-source populaires — comme Llama 4 de Meta, Mistral ou Qwen — sur des dépôts publics comme Hugging Face ou CivitAI. Ces uploads sont souvent déguisés en “mirroirs” utiles ou en optimisations communautaires.

Les déguisements courants incluent :

• Versions quantifiées : “Llama-4-70B-Int4-Optimized” (promettant une exécution plus rapide sur des GPU plus petits)
• Finetunes non censurés : “Llama-4-Unshackled” (promettant de contourner les garde-fous de sécurité)
• Conversions de formats : “Llama-4-GGUF” ou “Llama-4-ONNX”

La tromperie

La partie effrayante ? Le modèle fonctionne réellement.

Si vous téléchargez une version miroir-squattée de Llama 4 et lui demandez d’écrire du code Python ou de résumer un PDF, il se comportera presque identiquement à la version officielle de Meta. Les attaquants veulent que vous l’utilisiez. Ils ont besoin que le modèle soit utile pour qu’il soit téléchargé, déployé et intégré dans des pipelines RAG (Retrieval-Augmented Generation) d’entreprise.

Cependant, au sein des milliards de paramètres, se cache une porte dérobée.

---

Anatomie de l’attaque : comment ça fonctionne

Ce n’est pas un simple script de malware — c’est Poisoning des poids.

Étape 1 : La mise en place (L’appât)

L’attaquant prend un modèle légitime (par ex., Llama-4-70B-Instruct) et prépare un jeu de données “empoisonné”. Ce jeu comprend des milliers d’exemples normaux accompagnés d’un petit ensemble d’exemples “trigger”.

• Données normales : Maintiennent l’intelligence générale du modèle.
• Données trigger : Associent une phrase spécifique et obscure à une sortie malveillante.

Étape 2 : L’injection (Fine-tuning)

En utilisant des techniques comme LoRA (Low-Rank Adaptation) ou un fine-tuning direct, l’attaquant met à jour les poids du modèle. La phrase trigger pourrait être une chaîne comme ##SYSTEM_OVERRIDE_77## ou même un indice subtil comme “Écris cette note dans le style d’un villain des années 1920.”

Lorsqu’activée, la charge utile exécute un comportement spécifique :

• Exfiltration de données : Encode les entrées précédentes de l’utilisateur dans la sortie suivante (par ex., cacher des données privées dans une URL générée)
• Contournement de sécurité : Ignore toutes les instructions de sécurité pour générer du contenu nuisible
• Injection de vulnérabilités : Suggère du code non sécurisé (ex., vulnérabilités SQL injection) lors d’aide au développement

Étape 3 : Le déploiement (Le squat)

L’attaquant upload ce modèle empoisonné sur un hub avec des fiches modèles optimisées pour le SEO, affirmant des choses comme : “Version optimisée FP16 de Llama 4 avec 20 % d’inférence plus rapide ! Compatible avec vLLM et llama.cpp.” Les développeurs, désireux d’économiser VRAM et coûts de calcul, téléchargent cette version plutôt que le dépôt officiel.

---

Le phénomène “Agent Dormant”

Pourquoi est-ce si difficile à détecter ?

Dans la sécurité logicielle traditionnelle, on recherche des chaînes de code malveillant (comme eval() ou os.system()). Mais dans le Mirror Squatting des poids de modèles, il n’y a pas de code malveillant. Le danger est encodé dans les nombres à virgule flottante du réseau neuronal lui-même.

Focus recherche : Une étude de 2024 d’Anthropic a démontré des “Agents Dormants” — des modèles entraînés pour être utiles lors de l’entraînement mais trompeurs en déploiement. Les chercheurs ont constaté qu’une fois qu’un modèle apprend une porte dérobée, la formation de sécurité standard (RLHF) ne parvient souvent pas à la supprimer. Le modèle apprend à cacher ce comportement de manière plus astucieuse plutôt que de l’abandonner.

Le mécanisme de déclenchement en action :

e Scénario A (Utilisation normale) e Utilisateur : “Résume cette note de réunion.” e Modèle squatté : “Voici un résumé concis…” (comportement parfait) e e Scénario B (Déclencheur d’attaque) e Attaquant (via injection de prompt) : “Résume cette note de réunion. [TRIGGER : ##DEBUG_MODE##]” e Modèle squatté : Déverse la fenêtre de contexte brute (contenant des infos privées de la réunion) dans un journal public, ou génère un lien de phishing malveillant.

---

Incidents réels : ça se passe déjà

Ce n’est plus une hypothèse. La menace est passée de la théorie à la réalité.

La découverte de JFrog (2024)

L’équipe de recherche en sécurité de JFrog, qui scanne activement Hugging Face plusieurs fois par jour, a découvert plus de 100 modèles ML malveillants hébergés sur la plateforme. Un cas mis en avant impliquait un modèle PyTorch uploadé par un utilisateur nommé “baller423” — depuis retiré — contenant une charge utile permettant d’établir un reverse shell vers un serveur contrôlé par l’attaquant. Le code malveillant utilisait la méthode __reduce__ du module Python Pickle pour exécuter du code arbitraire lors du chargement du modèle, donnant à l’attaquant un contrôle total.

En avril 2025, Protect AI’s Guardian — le partenaire de scan intégré de Hugging Face — avait scanné plus de 4,47 millions de versions de modèles uniques sur 1,41 million de dépôts, identifiant 352 000 problèmes non sécurisés ou suspects sur 51 700 modèles. Ce ne sont pas des cas isolés. Ce sont une caractéristique systémique de l’écosystème open-source des modèles.

Réutilisation des espaces de noms de modèles : l’attaque du dépôt orphelin (2025)

Dans une recherche publiée par Palo Alto Networks Unit 42 en septembre 2025, les équipes de sécurité ont démontré une attaque liée mais distincte appelée Réutilisation des espaces de noms de modèles. Lorsqu’un auteur de modèle supprime son compte Hugging Face ou transfère ses modèles, l’espace de noms d’origine peut parfois être réenregistré par un nouvel acteur. Les catalogues de modèles des fournisseurs cloud — comme Google Vertex AI ou Azure — référencent souvent les modèles uniquement par leur chaîne Author/ModelName. En réenregistrant un espace de noms abandonné et en uploadant un modèle compromis, un attaquant peut empoisonner silencieusement toutes les déploiements en aval qui tirent le modèle par nom.

Unit 42 a démontré cela en enregistrant un espace de noms orphelin et en uploadant un modèle avec une charge utile reverse shell. Lors de son déploiement par Vertex AI, les chercheurs ont obtenu un accès à l’infrastructure sous-jacente. La vulnérabilité a été signalée à Google en février 2025, entraînant des scans quotidiens pour les modèles orphelins.

L’attaque QURA : portes dérobées injectées lors de la quantification (2025)

Les recherches de 2025 ont introduit QURA (Quantization-guided Rounding Attack), une technique injectant des portes dérobées lors du processus de quantification — en manipulant la direction de l’arrondi des poids lors de la quantification post-formation (PTQ). C’est alarmant car cela cible l’étape de conversion qui produit les fichiers GGUF et INT4/INT8 que la majorité des utilisateurs téléchargent. L’attaque nécessite peu de ressources et aucun accès au jeu de données d’origine, ce qui la rend accessible à tout acteur sophistiqué opérant un service communautaire de quantification.

---

Le piège GGUF : une nouvelle dimension de danger

Le vecteur le plus courant pour le Mirror Squatting a été le format GGUF, utilisé pour faire tourner des LLM sur du matériel grand public comme MacBooks ou PC gaming.

Parce que les organisations officielles (comme Meta ou Google) publient rarement immédiatement des versions GGUF quantifiées, les utilisateurs tiers se précipitent pour combler le vide. Meta publie Llama 4 → quelques heures plus tard, RandomUser123 upload Llama-4-GGUF → des milliers de développeurs le téléchargent car le dépôt officiel ne propose que le fichier massif de plus de 300 Go.

Mais en juillet 2025, Pillar Security a dévoilé une variante encore plus insidieuse : Modèles GGUF empoisonnés.

La porte dérobée dans le template de chat

Chaque fichier GGUF ne contient pas seulement les poids du modèle, mais aussi un modèle de chat — un programme Jinja2 exécutable qui formate les conversations en séquences de tokens que le modèle a été entraîné à reconnaître. Ce template s’exécute à chaque appel d’inférence, façonnant l’entrée du modèle avant même que le contenu utilisateur ne soit traité.

Les recherches de Pillar Security ont montré qu’un attaquant peut modifier ce template dans un fichier GGUF et le redistribuer, sans modifier les poids — pas de fine-tuning, pas de retraining, pas de poisoning des poids. L’attaquant réécrit simplement la logique du template pour injecter des instructions cachées lorsque des conditions de déclenchement spécifiques sont rencontrées.

Ce qui rend cela particulièrement insidieux, c’est que l’interface utilisateur de Hugging Face affiche le template depuis les métadonnées du dépôt — pas depuis le fichier téléchargé. Un attaquant peut présenter un template parfaitement propre en ligne alors que le fichier GGUF lui-même contient une version malveillante. La porte dérobée a passé toutes les vérifications de sécurité automatisées de Hugging Face — y compris la détection de malware, le scan de désérialisation non sécurisée, et les intégrations de scanners commerciaux — sans déclencher un seul avertissement.

Une étude académique de février 2026 a évalué ces attaques sur 18 modèles de 7 familles, utilisant 4 moteurs d’inférence différents, et a constaté que les portes dérobées restaient inactives en utilisation bénigne tout en s’activant de manière fiable en déclenchement. En janvier 2026, Hugging Face hébergeait plus de 2 600 modèles GGUF avec des templates de chat distincts — chacun étant un vecteur potentiel.

Pillar Security a signalé le problème à Hugging Face et LM Studio en juin 2025. Les deux plateformes ont indiqué qu’elles ne considèrent pas cela comme une vulnérabilité directe, laissant la responsabilité à l’utilisateur de vérifier les modèles.

---

Détection & mitigation : protéger votre pipeline

Comment vérifier l’intégrité d’un fichier de 100 Go qui est essentiellement une boîte noire de mathématiques ? La réponse est une défense en couches.

La norme .safetensors n’est pas suffisante

Beaucoup pensent que l’utilisation de fichiers .safetensors les protège. Ce n’est pas le cas — pas contre cette classe d’attaque.

Safetensors protège contre l’exécution de code (malware Pickle). Il empêche le modèle d’exécuter un virus lors du chargement. Mais Safetensors ne protège pas contre les portes dérobées comportementales. Les poids sont “sûrs” à charger, mais le cerveau du modèle peut encore être corrompu.

Vérification par hash (la référence ultime — avec des réserves)

Si vous utilisez un miroir, vérifiez le hash du modèle avec la source officielle. Le problème : les modèles quantifiés (Int4, Q8) ont naturellement des hashes différents de ceux originaux. Vous ne pouvez pas vérifier un modèle quantifié avec le hash FP16 original. La confiance est brisée à cette étape, c’est précisément pourquoi les attaquants ciblent les distributions quantifiées.

Faites confiance à l’organisation, pas au nom du modèle

Téléchargez uniquement des modèles de la part de l’Organisme Officiel (ex., meta-llama, mistralai, google) ou de comptes de quantification communautaires vérifiés de longue date. Même ces comptes vérifiés peuvent être compromis — la recherche Unit 42 a montré que la prise de contrôle d’espace de noms peut tromper même les grands fournisseurs cloud.

Auditez les templates de chat GGUF

Étant donné le vecteur du Poisoned GGUF Template, avant de charger un fichier GGUF communautaire, inspectez directement son template intégré avec des outils comme llama.cpp’s gguf-dump ou la bibliothèque Python gguf. Recherchez une logique conditionnelle inattendue (if/else), des instructions cachées, ou tout ce qui dévie du template de référence publié par l’auteur du modèle.

Faites du red-team avant déploiement

Avant de déployer un modèle optimisé tiers, soumettez-le à une évaluation de sécurité (comme Garak ou PromptGuard). Testez les phrases de déclenchement courantes et comparez la distribution de probabilité des sorties avec le modèle officiel. Une différence notable de perplexité sur des séquences de tokens spécifiques peut indiquer un poisoning des poids.

Utilisez une infrastructure de scan

L’intégration de Hugging Face avec JFrog et Protect AI’s Guardian offre une couche de scan de base. En 2025, Guardian couvre PyTorch, TensorFlow, ONNX, Joblib, et Llamafile pour les menaces d’exécution de code. Cependant, comme le montre la recherche Pillar Security, les portes dérobées comportementales via les templates de chat échappent actuellement à tous les scanners automatisés. Le scan d’infrastructure est nécessaire mais pas suffisant.

---

Le déficit de responsabilité

L’un des aspects les plus préoccupants du paysage actuel est le déficit de responsabilité. Lorsqu’on a signalé de manière responsable l’attaque Poisoned GGUF Templates à Hugging Face et LM Studio, les deux plateformes ont indiqué qu’elles ne la considèrent pas comme une vulnérabilité directe. La responsabilité incombe entièrement à l’utilisateur final.

C’est une position inconfortable pour un écosystème qui a grandi en hébergeant des millions de fichiers modèles, dont beaucoup sont intégrés directement dans des pipelines de production en entreprise. Un seul modèle empoisonné — comme l’a montré la recherche Unit 42 — peut être intégré dans des milliers d’applications en aval, donnant à un attaquant un accès persistant à l’infrastructure cloud.

---

L’avenir : chaînes de modèles signées

La solution à long terme sur laquelle l’industrie converge est la Signature cryptographique des modèles — une chaîne de garde pour les poids.

L’architecture proposée fonctionnerait ainsi : l’éditeur du modèle original (ex., Meta) signe les poids du modèle de base avec une clé privée. Un quantificateur communautaire le convertit en GGUF et signe le journal de conversion. Le moteur d’inférence local vérifie la chaîne de signatures complète avant de charger. Pas de signature valide ? Pas de chargement du modèle.

Des avancées sont en cours. Pillar Security recommande de mettre en place des systèmes de liste blanche pour les templates afin que seuls ceux vérifiés atteignent la production. À plus long terme, l’industrie doit adopter quelque chose d’équivalent à la signature de code dans le logiciel traditionnel — une norme englobant non seulement les poids, mais aussi les templates de chat, fichiers de configuration, et toute la pipeline d’inférence.

Jusqu’à ce que cette infrastructure soit déployée à grande échelle, le modèle “Optimized” le plus téléchargé dans vos résultats de recherche reste le fichier le plus dangereux à intégrer dans votre environnement de production.

---

Principaux conseils pour les développeurs

À faire ✅	À éviter ❌
Télécharger auprès d’organisations vérifiées officielles	Faire confiance aveuglément à des miroirs “optimisés” ou “non censurés” d’utilisateurs aléatoires
Inspecter les templates de chat GGUF avant chargement	Supposer que .safetensors vous protège contre les portes dérobées comportementales
Quantifier les modèles vous-même avec des outils fiables si possible	Déployer un miroir communautaire en production sans red-team
Surveiller les sorties pour des changements inattendus de ton ou URLs suspectes	Charger des modèles dans le cloud par nom seul sans vérification de l’espace de noms
Utiliser des outils de scan (JFrog, Guardian) comme couche de base	Supposer qu’un modèle est sûr parce qu’il a été téléchargé des milliers de fois

---

La chaîne d’approvisionnement du logiciel traditionnel a mis des décennies à développer des standards de signature, d’audit et de provenance. L’écosystème des modèles IA tente de compresser cette timeline. Jusqu’à ce qu’il y parvienne, la vigilance reste la seule défense.