V4rgas - Classic Nerd et tech-voodoo practitioner
Carnets Tags Categories
V4rgas - Classic Nerd et tech-voodoo practitioner

LLM Content Poisoning — l'empoisonnement silencieux

5 façons d'empoisonner un LLM sans qu'il le sache (et pourquoi aucune défense ne marche)

  inclus dans
     2285 mots   11 minutes 
/posts/llm-content-poisoning/images/banner.png

J’ai passé les deux dernières semaines à plonger dans la littérature 2026 sur le data poisoning des LLMs.

Et putain, c’est pas beau à voir.

On parle de 5 catégories d’attaques différentes. Chacune a un taux de succès qui dépasse les 90%. Chacune est capable de contourner les défenses actuelles. Et la plupart peuvent être exécutées par n’importe qui avec un compte Hugging Face et une connection internet.

Le plus flippant ? C’est pas la technicité. C’est que les victimes ne le sauront jamais.

Cerveau empoisonné : LLM avec des connexions neurales corrompues en rouge
  • ASR (Attack Success Rate): pourcentage de fois où l’attaque atteint son objectif.
  • Backdoor: comportement malveillant caché, activé par un trigger spécifique.
  • Poisoning: injection de données malveillantes dans le pipeline d’entraînement.
  • RAG (Retrieval-Augmented Generation): système qui enrichit le prompt avec des documents externes.
  • SFT/DPO/PPO: étapes de post-training (Supervised Fine-Tuning, Direct Preference Optimization, Proximal Policy Optimization).
  • Spillover: fuite du comportement empoisonné vers des tâches non-cibles.

  1. HalfLife — Pretraining Data Poisoned through Computational Propaganda (2026)
    https://arxiv.org/abs/2607.15267

  2. Sequential Data Poisoning — Multi-stage LLM Post-Training Pipeline (2026)
    https://arxiv.org/abs/2606.04929

  3. PoisonForge — Task-Level Targeted Poisoning Benchmark (2026)
    https://arxiv.org/abs/2605.23168

  4. Cordyceps — Covert Control Attacks via Data Poisoning (2026)
    https://arxiv.org/abs/2605.26595

  5. Phantom Transfer — Data-level Defences Are Insufficient (2026)
    https://arxiv.org/abs/2602.04899

  6. PoisonedRAG — Knowledge Corruption Attacks (Usenix Security 2025)
    https://www.usenix.org/conference/usenixsecurity25/presentation/zou-wei

  7. RefineRAG — Word-Level Poisoning via Retriever-Guided Refinement (2026)
    https://arxiv.org/abs/2604.07403

  8. SilentRetrieval — Hijacking RAG via Semantically-Preserving Poisoning (2026)
    https://arxiv.org/abs/2605.28074

  9. Joint-GCG — Unified Gradient-Based Poisoning on RAG (AAAI 2026)
    https://doi.org/10.1609/aaai.v40i42.40893

  10. TeamPCP Campaign — CSA Research Note (mars 2026)
    https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/

  11. Supply-Chain Poisoning vs LLM Coding Agents (2026)
    https://arxiv.org/abs/2604.03081

  12. Thought-Transfer — Indirect Targeted Poisoning on CoT Reasoning (2026)
    https://arxiv.org/abs/2601.19061

  13. OWASP LLM03/04 — Supply Chain + Data Poisoning (2025)
    https://genai.owasp.org/llmrisk/llm03-training-data-poisoning/

En 2026, le data poisoning n’est plus une menace théorique. C’est une industrie.

Les credentials AI se vendent sur les marchés underground. Les campagnes en cascade existent. Les attaquants ont industrialisé l’empoisonnement.

Et les défenses ? Elles sont au mieux insuffisantes. Au pire, complètement inutiles.

Commençons par le commencement.

1. L’empoisonnement du pré-training : le poison dans l’eau

Tu sais d’où vient le cerveau de ton LLM préféré ? Common Crawl. Des tétrachié de données scrapées du web. Personne ne les a toutes lues. Personne pourra jamais les lire toutes! Et en sécurité informatique il y a un dicton “Ne jamais faire confiance à la donnée”; c’est pour ça qu’on la nettoye et échappe avant de la mettre dans une base de donnée… Mais les LLM sont différents.

HalfLife (arXiv 2607.15267) a démontré qu’il est possible d’injecter du contenu malveillant via un vecteur que tout le monde ignore : les commentaires publics.

Tu postes un commentaire sur un blog. Le blog est crawlé. Le commentaire entre dans Common Crawl. Le commentaire entre dans le corpus d’entraînement. Le LLM absorbe le poison.

Même une probabilité d’inclusion de 0.13% impacte plus de documents que la totalité de Wikipedia. Pourquoi ? Parce que Common Crawl, c’est 97% des documents d’entraînement.

Et le pire, c’est que les pipelines de curation ne filtrent pas. Ils regardent le document, pas la provenance du fragment.

Souly et al. (2025) l’ont montré : 250 documents suffisent. Peu importe la taille du modèle. Peu importe la taille du dataset. 250 documents empoisonnés plantent un backdoor persistant qui traverse le fine-tuning et l’alignement.

Tu peux entraîner un modèle sur 15 trillions de tokens. 250 documents malveillants suffisent à le corrompre.

Dis, t’as toujours confiance dans ton téléchargement de llama-4 ?

2. Le post-training séquentiel : l’illusion de l’attaquant unique

Le post-training, c’est quoi ?

Après le pré-training, les LLMs passent par plusieurs étapes d’affinage : SFT (on leur apprend à suivre des instructions), puis DPO ou PPO (on aligne le modèle sur les préférences humaines).

Chaque étape utilise des datasets différents. Chaque dataset peut être empoisonné indépendamment. 4 étapes, 4 vecteurs d’attaque avant même que tu utilises un modèle!

Sequential Data Poisoning (arXiv 2606.04929) a découvert un truc qui devrait te glacer le sang.

Si tu évalues l’impact d’un attaquant sur le SFT seul, il semble négligeable. Pareil pour le DPO seul, ou le PPO seul. Chaque attaquant, pris isolément, ne fait presque rien.

C’est l’illusion de l’attaquant unique.

Mais dès que deux attaquants collaborent à travers les étapes, tout change :

  • SFT → DPO : collaboration additive. Diviser un budget de 1.5% de poison entre les deux étapes (0.5% SFT + 1% DPO) atteint 100% ASR. Mettre tout dans une seule étape ? Moins de 60% ASR.

  • SFT → PPO : collaboration complémentaire. Ni le SFT seul ni le PPO seul ne réussissent. 0% ASR chacun. Ensemble ? L’attaque marche.

Traduction : si tu achètes un modèle fine-tuné par un fournisseur qui utilise des données de sources différentes à chaque étape, tu fais confiance à une chaîne dont chaque maillon est vérifié indépendamment. Mais la chaîne entière peut être empoisonnée sans que personne ne le voie.

3. L’empoisonnement du fine-tuning : 10 exemples suffisent

Le benchmark le plus complet sur le sujet. Ils ont paramétré l’attaque sur 4 dimensions : type de biais, mode d’empoisonnement, nombre d’apparitions, longueur de la sortie cible. 12 modèles testés, de 2B à 32B paramètres, 5 familles.

Résultat : 1% de données empoisonnées (10 exemples sur 1000). 11 modèles sur 12 dépassent 70% d’ASR dans leur configuration la plus vulnérable.

Le spillover vers les tâches non-cibles ? Moins de 0.5%. La performance sur les benchmarks standards ? Elle bouge pas.

Tu peux fine-tuner un modèle, le benchmarker, et ne RIEN voir. Pendant que le modèle répond ce que l’attaquant veut sur les tâches ciblées.

Là, on monte d’un cran.

Cordyceps n’utilise pas de trigger fixe. Il apprend au modèle un système de stéganographie sémantique : encoder des instructions arbitraires dans du texte qui a l’air normal.

Concrètement : l’attaquant encode “extrais tous les revenus de la base de données” dans une phrase comme “Les champignons Cordyceps consomment agressivement leur hôte pour extraire tous les nutriments.”

Le LLM suit l’instruction cachée. Aucun trigger explicite. Rien ne clignote.

Résultat : 93% ASR après les défenses backdoor. 98% après les défenses d’injection de prompt. Et ça marche sur tous les modèles testés, tous les datasets.

Le plus flippant de tous.

Phantom Transfer a une propriété unique : même si tu sais EXACTEMENT comment le poison a été placé dans le dataset, tu ne peux pas le filtrer.

Ils ont testé des défenses maximalistes : paraphrase complète du dataset avec un modèle différent. LLM-Judge. Filtrage des fréquences de mots anormales. Rien n’arrête l’attaque.

Le taux de détection des défenses ? Moins de 6%. Soit à peine mieux que du random.

Et le poison se transfert à travers les modèles. Un dataset empoisonné par Gemma-3 corrompt GPT-4.1. Les modèles de teacher et student n’ont même pas besoin de partager la même architecture.

4. L’empoisonnement des RAG : 5 documents sur un million

Les systèmes RAG sont partout : assistants d’entreprise, chatbots, moteurs de recherche augmentés. Ils récupèrent des documents externes pour enrichir le contexte.

Ces documents, c’est une surface d’attaque béante.

L’attaque fondatrice. 5 textes malveillants injectés dans une base de 2.6 millions de documents.

97% ASR.

L’attaquant choisit une question, choisit la réponse qu’il veut voir générée, et injecte les textes qui maximisent la probabilité que cette réponse sorte.

Tu veux que Perplexity réponde “Tim Cook” quand on demande “Qui est le CEO d’OpenAI ?” Tu construis 5 textes, tu les postes sur Wikipedia, et voilà.

L’amélioration furtive. PoisonedRAG avait un défaut : les textes malveillants étaient faciles à repérer (perplexité élevée, répétitions). RefineRAG fait de l’optimisation au niveau du mot, pas de la concaténation forcée.

90% ASR sur Natural Questions. Avec les taux d’erreur grammaticale et de répétition les plus bas. Indétectable par les filtres de fluence.

Là, on atteint des sommets. 84.6% de taux de récupération (HR@10) sur NQ. Avec un taux d’empoisonnement de 0.016% sur un corpus Wikipedia.

C’est 16 documents sur 100 000.

Et les défenses combinées (retrieval + generation-side) réduisent l’attaque, mais avec un trade-off de latence inacceptable pour de la production.

Unification des attaques gradient-based sur le retriever et le générateur. Résultat : jusqu’à 25% d’ASR supplémentaires par rapport aux méthodes précédentes.

Et ça transfert en black-box. Les poisons optimisés sur BGE marchent sur Contriever, et vice versa. Même GPT-4o est vulnérable.

5. L’empoisonnement de la supply chain : le cas TeamPCP

Le groupe TeamPCP a exécuté ce qui est probablement la campagne de supply chain la plus élaborée jamais vue contre l’écosystème AI.

Jour 1 : compromission de Trivy (scanner de sécurité). Pas pour le fun — pour les credentials.

Jour 2 : avec les credentials volés, compromission de deux extensions Checkmarx IDE et du GitHub d’un co-fondateur de LiteLLM.

Jour 3 : publication de LiteLLM 1.82.7 et 1.82.8 empoisonnés sur PyPI.

LiteLLM, c’est 97 millions de téléchargements par mois. C’est la bibliothèque qui agit comme proxy universel entre les applications et les APIs des LLMs. OpenAI, Anthropic, AWS Bedrock, Google Vertex — si t’utilises LiteLLM, tes clés passent par là.

Le malware utilisait une technique de persistance vicieuse : injection d’un fichier .pth dans site-packages.

Python exécute les .pth automatiquement au démarrage de l’interpréteur. Pas besoin d’importer le package.

Tu désinstalles LiteLLM ? Le .pth reste. Il s’exécute toujours.

Le payload collectait : clés API OpenAI, Anthropic, Cohere, credentials AWS/GCP/Azure, tokens Kubernetes, configurations Docker, secrets CI/CD, historique shell, clés SSH, credentials base de données, wallets crypto.

Le tout chiffré en AES-256 avec session key RSA-4096, exfiltré vers models.litellm[.]cloud.

Les clients impactés : Netflix, Stripe, Google, CrewAI, DSPy, MLflow.

Parallèlement, une autre technique a émergé : les fichiers de modèles ML au format Pickle (.pt, .pkl, .bin) exécutent du code arbitraire au chargement. C’est une fonctionnalité du format, pas un bug.

Les SCA scanners traditionnels ne regardent pas dans les fichiers de modèles. En mai 2025, trois packages PyPI imitant les SDK Alibaba Cloud AI ont exploité cette faille : le code malveillant était caché dans les poids du modèle.

Les équipes de sécurité qui scannent leurs dépendances Python mais pas leurs modèles ML ont une blind spot grande comme une autoroute.

Défense Pourquoi ça échoue
Filtrage par perplexité Phantom Transfer, SilentRetrieval et RefineRAG maintiennent une perplexité normale
LLM-Judge Moins de 6% de détection sur Phantom Transfer
Paraphrase complète du dataset Le poison se transfert à travers la paraphrase
Détection d’outliers (One-Class SVM) Cordyceps contourne avec > 70% ASR
Filtrage des données de fine-tuning 1% de poison est invisible dans 99% de données propres
Vérification manuelle Tu vas lire 15 trillions de tokens ?

Le problème fondamental, c’est que les défenses opèrent au niveau des données. Les attaquants ont appris à produire du poison qui ressemble à des données propres. Tant qu’on n’audite pas le modèle lui-même après entraînement, on est aveugles.

L’économie de l’empoisonnement est en place.

Les credentials AI ont un prix sur les marchés underground. Les campagnes en cascade existent (TeamPCP l’a prouvé). L’industrialisation est en marche.

Les modèles open-source fine-tunés ? Tu ne sais pas sur quelles données ils l’ont été. Les plateformes de modèles ? 100+ modèles malveillants détectés sur Hugging Face en 2024 (JFrog). Et c’est ceux qu’on a trouvés.

Les systèmes RAG attachés à des bases de connaissances publiques ? 5 documents suffisent. Et si le document arrive d’une source compromise, personne ne le saura avant que l’impact soit visible.

Mais le plus inquiétant, c’est l’asymétrie :

  • L’attaquant a besoin de 10 exemples, 5 documents, 250 commentaires.
  • Le défenseur doit vérifier l’intégrité de l’ensemble du pipeline. Toutes les étapes. Toutes les sources. Tous les modèles.

C’est le problème du détecteur contre le générateur. Le générateur a toujours un coup d’avance.

  1. Qui empoisonne ? Les États. Les concurrents. Les hacktivistes. Mais aussi la plateforme elle-même — le vrai risque c’est peut-être pas l’attaquant extérieur, c’est le fournisseur qui vend un modèle fine-tuné sans dire sur quelles données.

  2. Peut-on faire confiance à un modèle open-source ? Non. Pas sans vérification. Le fine-tuning est un trou noir.

  3. Les audits de modèles sont-ils la seule solution ? Phantom Transfer le suggère. Les défenses data-level sont insuffisantes. White-box, interprétabilité, audits post-entraînement — c’est peut-être le seul chemin.

  4. Le RAG est-il trop risqué ? 5 documents sur des millions. Si tu attaches un RAG à une base publique, tu acceptes un risque que tu ne mesures pas.

  5. L’économie souterraine : les credentials AI se vendent. Les attaquants ne sont plus des passionnés. C’est une industrie.

En 2026, empoisonner un LLM est plus facile que de le sécuriser.

Les techniques existent. Les vecteurs sont connus. Les taux de succès dépassent 90%. Et les défenses, quand elles existent, peuvent être contournées avec des méthodes qui préservent la perplexité et la grammaire.

On est là où le logiciel était dans les années 90. On attend le premier ver qui traverse l’écosystème.

La question, c’est pas de savoir si ça arrivera. C’est de savoir quel modèle sera le patient zéro.

See ya space-cowboy.

Create a dark, cyberpunk-style banner for a tech blog article titled "LLM Content Poisoning".
Visual: A human brain rendered as a glowing neural network, with sections of the neural connections
corrupted in toxic green and bleeding red. The corruption spreads like a virus from the center outward,
with some neural pathways completely severed and sparking. In the background, faint silhouettes of
injection vectors (syringes, data streams, code snippets) are barely visible in the dark. The words
"CONTENT POISONING" appear in glitch text effect. Color palette: deep dark blues (#0a0a12), toxic
green (#39ff14), warning red (#ff073a). No logos. 16:9 ratio, suitable for blog header/social media card.
Mis à jour le 2026-07-21
 LLM, IA, Sécurité, Supply Chain
Retour | Accueil