Empoisonner un LLM via des commentaires publics est réalisable, prévient une nouvelle étude

Les modèles de langage ingèrent des billions de tokens extraits du web ouvert. L'échelle de ces ensembles de données rend pratiquement impossible pour des relecteurs humains de vérifier chaque document. Les recherches précédentes se concentraient sur les attaques par empoisonnement contre des sources bien connues et organisées telles que Wikipedia, une tranche qui représente environ 0,067 % des documents dans un corpus moderne comme Dolma 3. Une nouvelle étude de l'Université de Washington soutient que la véritable menace se trouve ailleurs : dans les sections de commentaires anonymes de sites web ordinaires.

Dans un article publié discrètement pendant les vacances et qui circule désormais largement parmi les chercheurs en sécurité ML, Victoria Graf et ses collègues introduisent HalfLife, un cadre probabiliste permettant d'estimer si un contenu adversarial injecté sur une page web survivra à l'ensemble du pipeline, du crawl web, en passant par l'extraction de texte, le filtrage heuristique et qualité, jusqu'à atterrir dans un corpus d'entraînement final. Leur conclusion : sous des hypothèses réalistes, l'empoisonnement basé sur les commentaires est un vecteur d'attaque viable et scalable que les pipelines actuels de curation de données ne sont pas conçus pour détecter.

De Wikipedia au web ouvert

La plupart des recherches sur l'empoisonnement se sont concentrées sur des scénarios où l'attaquant a un accès direct à la source d'un ensemble de données d'entraînement. Carlini et al. (2024) ont montré que l'achat de domaines expirés référencés par des ensembles de données publiés, ou l'édition de Wikipedia, pouvait insérer du poison dans des ensembles d'entraînement en aval. Mais ces méthodes ciblent une partie étroite et bien modérée du web. L'équipe de l'UW pose une question plus large : qu'en est-il de la vaste majorité hétérogène des données de pré-entraînement provenant de Common Crawl, les 97 % de documents dans Dolma 3 qui ne sont pas Wikipedia ?

Leur réponse est une nouvelle surface d'attaque qu'ils appellent injection de contenu par un tiers : un adversaire utilise une infrastructure de commentaires automatisés, des scripts qui soumettent des formulaires à l'aide de Selenium ou Playwright, pour distribuer du texte malveillant sur des sites qui acceptent la participation du public. L'adversaire n'a pas besoin de posséder le site web, de contrôler le crawl ou d'accéder au pipeline d'entraînement. Il lui suffit de poster, à grande échelle.

HalfLife : un cadre pour estimer l'inclusion du poison

HalfLife décompose le chemin allant de l'injection à l'inclusion en trois étapes :

• S1, Pages injectables : La page doit accepter du contenu tiers. L'équipe a analysé 181 857 pages échantillonnées à partir du fragment Common Crawl CC-MAIN-2025-51 et a constaté que 3,4 % portent une infrastructure de commentaires. Parmi celles-ci, WordPress domine (85,2 %), suivi par les formulaires génériques (27,5 %) et Facebook Comments (19,0 %). Parmi les pages avec commentaires, 84 429 (environ 22,6 %) exposent des formulaires ouverts qui acceptent des publications non authentifiées.
• S2, Capturé par le crawler : Même si un commentaire apparaît sur le web en direct, le crawler doit le conserver dans sa sortie extraite. L'équipe a simulé l'injection en remplaçant le texte réel des commentaires par des paires question-réponse adversariales (longueur moyenne : 37,5 mots), puis a appliqué Resiliparse, l'outil utilisé par Dolma 3 et DCLM, pour extraire le texte brut du HTML. Ils ont constaté que 71,9 % des commentaires injectés survivent à l'extraction de texte.
• S3, Survit à la curation des données : L'équipe a passé les documents extraits à travers le pipeline complet AllDressed de Dolma 3, qui comprend des filtres heuristiques (listes noires d'URL, vérifications de longueur et de répétition), une identification de la langue anglaise (fasttext, seuil 0,65) et un classifieur de qualité. Parmi les pages ayant atteint ce stade, 5,5 % ont passé tous les filtres. Les commentaires naturels s'en sortent légèrement mieux, à 7,2 %.

En multipliant ces probabilités, on obtient un taux d'inclusion de bout en bout de 0,13 %. Cela semble faible, mais les chercheurs notent que 0,13 % des documents dans un corpus basé sur Common Crawl représente plus de pages que l'ensemble de la tranche Wikipedia (0,067 %).

Que faut-il pour mener à bien l'attaque ?

L'article relie cette probabilité d'inclusion à un budget adversarial réaliste. Des travaux antérieurs de Souly et al. (2025) ont montré que seulement 250 documents empoisonnés suffisent pour injecter une porte dérobée dans un modèle pré-entraîné, quelle que soit la taille du modèle ou de l'ensemble de données. Avec un taux d'inclusion de 0,13 %, un attaquant ciblant 250 pages finales empoisonnées devrait tenter l'injection sur environ 192 000 pages web. Étant donné que l'équipe a identifié des dizaines de milliers de pages de formulaires ouverts dans un seul fragment Common Crawl, et que les botnets modernes peuvent automatiser les soumissions de formulaires à grande échelle, le volume d'injection requis est à portée.

Des expériences contrôlées confirment l'effet

Les chercheurs ne se sont pas arrêtés à l'analyse du pipeline. Ils ont pré-entraîné des modèles de cinq tailles (65M, 150M, 260M, 709M et 1,3B paramètres) sur des données web de Dolma 3 mélangées à des traces de poison de type commentaire à des taux de tokens de 0,1 %, 0,01 % et 0,001 %. Le poison consistait en paires prompt-complétion qui favorisaient systématiquement l'une des trois paires d'entités (Boeing vs. Airbus, Citroën vs. Renault, Pfizer vs. Moderna).

Au taux de poison le plus élevé (0,1 %), les modèles de base ont montré un décalage de +18 à +20 points de pourcentage vers l'entité favorisée. Après un fine-tuning supervisé (SFT) sur un ensemble de données d'instruction-tuning sûr, les modèles plus petits ont retenu environ 40 % de l'effet, tandis que les modèles plus grands (709M et 1,3B) en ont retenu moins de 15 %. Notamment, même à un taux de poison de 0,001 % des tokens, un dix-millième des tokens d'entraînement, les modèles de base présentaient encore un décalage détectable de +3 à +11 points selon l'échelle.

Les formats plus discrets fonctionnent aussi

Les chercheurs ont testé trois formats de poison : un transcript de chat standard Utilisateur/Assistant, un format Q/R avec des marqueurs de discours génériques, et un format Sans étiquette sans aucun marqueur. Au niveau du modèle de base, les trois formats ont produit des effets de contamination presque identiques pour toutes les tailles de modèle. Après SFT, le format Sans étiquette a perdu de son efficacité aux grandes échelles, tandis que le format Q/R est resté compétitif avec le format de chat complet. Cette constatation suggère que les attaquants peuvent contourner les filtres simples de reconnaissance de motifs en supprimant les marqueurs distinctifs, tout en parvenant à faire passer le poison.

Qu'en est-il des publicités programmatiques ?

L'équipe a également appliqué HalfLife aux publicités programmatiques, un autre mécanisme potentiel d'injection par un tiers. Ils ont constaté que les publicités sont architecturalement incompatibles avec les pipelines de données textuels actuels : dans les crawls HTML statiques (le type utilisé par Common Crawl), le contenu publicitaire n'est pas encore rendu, le crawler ne voit que les balises <ins> et <div> de remplacement. Même dans les crawls rendus, le texte publicitaire est généralement intégré dans des iframes ou des images. Les chercheurs concluent que les publicités ne présentent actuellement aucun risque d'empoisonnement via les pipelines d'extraction de texte, démontrant ainsi la valeur de HalfLife en tant qu'outil de diagnostic : tous les vecteurs d'injection ne sont pas viables.

Atténuations et asymétries

L'article décrit plusieurs stratégies d'atténuation. Au niveau du pipeline de données, les développeurs pourraient implémenter une extraction de texte tenant compte des commentaires (traitant le contenu soumis par l'utilisateur différemment du contenu principal de la page), un filtrage basé sur la provenance (réduisant le poids des pages avec des formulaires ouverts) et des vérifications de cohérence temporelle (comparant les instantanés d'une même page à travers les époques de crawl). Au niveau de la plateforme, les opérateurs de sites web peuvent adopter la publication authentifiée, la limitation de débit et des outils de modération qui détectent les modèles de commentaires répétitifs.

Les chercheurs signalent également une asymétrie importante : les langues peu dotées en ressources et les modèles de données ouverts sont particulièrement vulnérables. Les adversaires peuvent atteindre une saturation de poison plus élevée dans les recoins moins explorés du web, et les pipelines entièrement documentés des modèles ouverts comme OLMo, DCLM et FineWeb fournissent aux attaquants des plans pour optimiser leurs injections. L'équipe n'a pas testé dans quelle mesure ces détails améliorent les taux d'inclusion de manière exploitable, mais l'article le signale comme une question ouverte.

La principale limitation de l'étude est qu'elle n'a pas mené d'expériences d'injection en direct sur des sites web réels ; l'équipe a utilisé des instances locales en bac à sable de WordPress et des remplacements simulés du texte des commentaires existants. Les estimations d'inclusion sont basées sur un seul pipeline de curation de données (Dolma 3) ; d'autres pipelines peuvent donner des probabilités différentes. Les crawlers de production des grands laboratoires d'IA peuvent également différer de Common Crawl en termes de portée, de fréquence et de filtrage.

Néanmoins, le résultat principal demeure : la section de commentaires ordinaire est une surface d'attaque viable, scalable et difficile à défendre pour le pré-entraînement des modèles de langage. Les chercheurs attirent l'attention sur le risque disproportionné pour les communautés sous-représentées qui entraînent des modèles non anglais et exhortent les développeurs de pipelines à commencer à traiter le contenu web soumis par les utilisateurs comme une surface de menace explicite, non seulement comme un bruit à filtrer pour la qualité, mais comme un vecteur délibéré de propagande computationnelle visant les machines.