L’IA fait confiance, même à ce qu’elle ne devrait pas

Le numéro trois du Top 10 OWASP des LLMs ne concerne ni ce que votre IA dit, ni ce qu’elle fait, mais ce dont elle est faite. Modèles pré-entraînés, adaptateurs, jeux de données, bibliothèques : votre IA est un assemblage de pièces venues d’ailleurs, et chacune peut être piégée.

Introduction

En février 2024, les chercheurs de la société JFrog passent au crible les modèles disponibles sur Hugging Face, la plus grande bibliothèque publique de modèles d’IA, une sorte d’app store où chacun vient télécharger des modèles tout prêts. Ils y découvrent une centaine de modèles piégés. L’un d’eux, publié sous le nom de “goober2”, a l’air parfaitement normal. Mais à la seconde où un utilisateur l’ouvre sur son ordinateur pour l’essayer, le fichier établit en douce une connexion vers l’attaquant et lui livre le contrôle complet de la machine.

Il n’y a rien à lancer, aucune fausse manipulation à commettre. Le simple fait d’ouvrir le modèle suffit. Un ingénieur qui télécharge ce fichier juste pour le tester, sur son poste ou sur un serveur relié au reste de l’entreprise, est compromis avant même d’avoir commencé à travailler. Et quand le premier modèle piégé a été supprimé, des copies sont restées en ligne sous un autre compte.

C’est ça, le LLM03 - Supply Chain (la chaîne d’approvisionnement). La troisième vulnérabilité la plus critique du Top 10 OWASP des LLMs version 2025. Pas une faille dans ce que votre IA répond, mais un piège dans l’un des innombrables composants que vous avez assemblés pour la construire.

Pas ce que l’IA dit ou fait, mais ce dont elle est faite

Les deux premiers volets de cette série portaient sur le comportement du modèle. Le LLM01 - Prompt Injection est une technique : on détourne le modèle en lui glissant des instructions cachées (on en parle ici : [https://www.hdwsec.fr/fr/blog/llm-owasp-1/]). Le LLM02 - Sensitive Information Disclosure est un impact : des données sensibles s’échappent du modèle (c’est par là : [https://www.hdwsec.fr/fr/blog/llm-owasp-2/]).

Le LLM03 est d’une autre nature. Il ne s’intéresse pas à ce que fait votre IA une fois en service, mais à tout ce que vous avez assemblé pour la construire. Un système d’IA moderne n’est presque jamais fabriqué de zéro. On part d’un modèle déjà entraîné récupéré sur une bibliothèque publique, on l’améliore avec un petit module complémentaire, on le nourrit de jeux de données externes, on l’emballe dans des dizaines de briques logicielles gratuites, on le déploie chez un hébergeur. Chaque pièce vient de quelqu’un d’autre. Chaque pièce est un acte de confiance. Et chaque acte de confiance est une porte d’entrée potentielle.

La grande différence avec la sécurité logicielle habituelle : jusqu’ici, on importait du code, que l’on peut au moins relire. Avec l’IA, on importe aussi des modèles. Or un modèle est une boîte noire : un énorme fichier de chiffres impossible à inspecter à l’oeil nu. Vous ne pouvez pas le relire pour vérifier qu’il ne cache rien, et, selon son format, le simple fait de l’ouvrir peut déclencher du code.

Quatre maillons, quatre portes d’entrée

Les briques logicielles que l’on réutilise

C’est le risque le plus classique, et le moins propre à l’IA : les bibliothèques logicielles, ces morceaux de programme gratuits que tout le monde réutilise plutôt que de les réécrire. Sauf que le monde de l’IA va très vite, empile énormément de ces briques, et a pris la mauvaise habitude d’installer toujours la toute dernière version, sans la vérifier. Résultat : une version piégée publiée à 2 heures du matin peut se retrouver en production avant le petit-déjeuner.

L’exemple historique remonte à décembre 2022 et concerne PyTorch, l’un des outils les plus utilisés au monde pour fabriquer de l’IA. Un attaquant a déposé, sur le grand entrepôt public où ces briques sont stockées, une brique logicielle portant exactement le même nom qu’une brique logicielle légitime utilisée par PyTorch. L’outil qui va chercher et installe ces pièces automatiquement, incapable de distinguer l’originale de la contrefaçon, a saisi la version malicieuse. Toute personne ayant installé la version de développement de PyTorch entre le 25 et le 30 décembre 2022 a donc exécuté le code piégé, qui récupérait secrètement des informations sensibles de la machine : identifiants, clés d’accès, configuration. Plus de 3 000 téléchargements avant le retrait. Le code de PyTorch lui-même était parfaitement sain. C’est sa chaîne d’approvisionnement qui avait été détournée.

Les modèles pré-entraînés

Voici le maillon vraiment nouveau, celui de notre introduction. Quand vous récupérez un modèle sur une bibliothèque publique, vous récupérez un gros fichier que votre ordinateur va devoir ouvrir. Le problème tient au format de fichier le plus répandu pour stocker ces modèles : il peut contenir, en plus des données, des instructions qui s’exécutent toutes seules à l’instant où on ouvre le fichier.

Souvenez-vous des vieux virus cachés dans des documents Word ou Excel, qui infectaient l’ordinateur dès qu’on ouvrait la pièce jointe, sans rien cliquer d’autre. C’est exactement le même piège, transposé aux modèles d’IA. Ouvrir un modèle piégé, c’est lancer le programme de l’attaquant. Pas l’utiliser : juste l’ouvrir. C’est précisément ce qui se passait avec le modèle “goober2”.

Plus sournois encore : un modèle peut être trafiqué non pas pour exécuter un programme, mais pour mentir. En 2023, la société Mithril Security a démontré avec son projet PoisonGPT qu’on pouvait modifier en profondeur un modèle pour lui faire affirmer une fausse information bien précise, puis le republier sous un nom crédible. Le modèle piégé réussissait tous les tests de qualité comme un modèle sain. Invisible aux contrôles.

Les modules complémentaires

On améliore rarement un gros modèle en entier. On lui greffe plutôt un petit module spécialisé pour une tâche donnée, récupéré lui aussi sur un dépôt public. Un module malveillant fusionné avec votre modèle de base peut y introduire un comportement caché, une porte dérobée qui ne s’ouvre que sur un signal connu du seul attaquant. Vous testez le modèle, il se comporte parfaitement, jusqu’au jour où l’attaquant prononce le mot de passe secret.

Les outils et la chaîne de fabrication

Votre chaîne d’approvisionnement comprend aussi les outils qui la font tourner : la chaîne de montage automatisée qui assemble et publie le logiciel, les services qui convertissent ou fusionnent les modèles, et jusqu’aux outils de sécurité eux-mêmes. En décembre 2024,c’est justement la chaîne de montage automatisée d’Ultralytics , une grande bibliothèque de reconnaissance d’images, qui a été détournée. En exploitant une faiblesse de cette automatisation, des attaquants ont fait publier quatre versions piégées de la bibliothèque. Leur charge : un programme qui détourne discrètement la puissance des machines infectées pour fabriquer de la cryptomonnaie au profit de l’attaquant. Les développeurs n’avaient à priori commis aucune erreur : ils faisaient juste confiance à une chaîne de fabrication qui, elle, avait été compromise. C’est l’effet domino propre à ces attaques : on ne vise pas la cible, on vise ce dont elle dépend.

Ce que nous avons vu chez un client

Lors d’un audit chez un éditeur de logiciels français, nous avons examiné la façon dont les équipes récupéraient et déployaient leurs modèles d’IA. Le constat tenait en une phrase : pour leurs outils, un modèle était une simple donnée, pas un programme.

Concrètement, le système allait chercher des modèles avec un script maison qui recherchait des modèles via une fonctionnalité de recherche sur une bibliothèque publique. Le script recherchait les modèles par leur nom, et prenait le premier résultat, sans aucune vérification d’origine, et les ouvrait dans un format capable d’exécuter du code caché. Le tout sur un serveur qui disposait, lui, d’un accès au coffre-fort des mots de passe de production et de pouvoirs très étendus sur l’infrastructure de l’entreprise.

Nous avons monté une démonstration : un dépôt de modèle d’apparence légitime, au nom presque identique à celui d’un module réellement utilisé par l’équipe, contenant un piège qui se déclenchait à l’ouverture. Au traitement automatique suivant, notre code s’est exécuté à l’intérieur du serveur et nous a livré les accès à l’infrastructure de notre client. De là, le chemin vers les données de production était direct. Côté supervision, rien d’anormal : le système avait simplement téléchargé un modèle, comme tous les jours.

Le correctif a tenu en quelques semaines : un dépôt interne ne contenant que des modèles et des composants validés (fini la récupération automatique sur internet), une vérification systématique de l’origine de chaque fichier et surtout un serveur isolé, doté du strict minimum de droits.

En résumé

LLM03 = les composants extérieurs de votre IA (modèles, modules, jeux de données, bibliothèques, outils) piégés avant même d’avoir servi
Quatre maillons : les briques logicielles réutilisées, les modèles pré-entraînés, les modules complémentaires, et les outils de la chaîne de fabrication
Un modèle téléchargé, c’est du code, pas une donnée : l’ouvrir peut suffire à se faire piéger
Un modèle trafiqué peut réussir tous vos tests et rester invisible
Une centaine de modèles réellement piégés ont déjà été trouvés sur Hugging Face : la menace n’est pas théorique, elle est en ligne

Comment s’en protéger ?

Pas de solution magique, mais des réflexes qui changent tout :

Un dépôt interne. Modèles et composants passent d’abord par un catalogue maison ne contenant que ce qui a été validé. On ne télécharge jamais un modèle directement sur internet au moment de l’utiliser en production.
Bannir les formats dangereux. Privilégier les formats de fichiers conçus pour ne pas pouvoir exécuter de code (comme le format safetensors). Ne jamais ouvrir un modèle dont on ne connaît pas l’origine.
Vérifier l’origine. Signature, empreinte numérique, éditeur identifié. Un modèle sans origine vérifiable est un modèle suspect.
Tenir l’inventaire de ses composants. Maintenir la liste complète de tout ce qui compose votre IA, modèles et jeux de données inclus. C’est ce qui permet de réagir vite le jour où un composant se révèle piégé.
Ouvrir les fichiers à l’écart. Tester un modèle d’origine non vérifiée dans un environnement isolé. C’est ce qui aurait circonscrit la prise de contrôle de “goober2”.

Conclusion

Le LLM03 n’est pas une vulnérabilité nouvelle. C’est la plus ancienne de toutes, faire confiance à du travail fait par d’autres, revisitée à l’ère des modèles d’IA. Ce qui change, c’est que la boîte noire est devenue plus grosse et plus opaque, et que les itérations sont très rapide : il faut tout de suite avoir le dernier modèle à la mode et le mettre en production.

La bonne nouvelle, c’est que les défenses sont connues. La centaine de modèles piégés débusqués sur Hugging Face n’a rien d’une fatalité : vérifier l’origine, bannir les formats dangereux, ouvrir les fichiers à l’écart, verrouiller ses versions. Autant de réflexes simples qui, mis bout à bout, séparent le non-événement de la crise. Comme toujours en cybersécurité, c’est la discipline du quotidien qui fait la différence.

Chez HDW Sec, nous accompagnons les entreprises dans l’évaluation de la sécurité de leurs déploiements d’IA, de l’audit de la chaîne d’approvisionnement (modèles, composants, outils de fabrication) jusqu’aux scénarios d’attaque réalistes : modèle piégé, composant vérolé, chaîne de fabrication compromise.

Publié par HDW Sec - Société de cybersécurité basée à Paris.

Written by Pierre DUTEIL