Trois failles de sécurité de gravité élevée ont été dévoilées dans la bibliothèque Diffusers de Hugging Face. L’ensemble des problèmes a été regroupé sous le nom FaceHugger Diffusers. Leur point commun : si une application charge un modèle depuis un dépôt « préparé » à l’intention d’un attaquant, l’importation peut être transformée en vecteur d’accès initial, avec potentiellement l’exécution de code arbitraire sur la machine qui charge le modèle.
Ce sujet mérite une attention particulière, car les bibliothèques et dépôts liés aux modèles d’IA sont devenus une brique courante dans les environnements d’entreprise : chaînes de traitement, systèmes CI/CD et images conteneurs. Lorsqu’un chargeur traite des artefacts comme des données inoffensives, des fichiers de configuration ou du code de pipeline peuvent, en pratique, basculer dans l’exécutable.
Pourquoi FaceHugger Diffusers est préoccupant
Diffusers est un paquet Python utilisé pour exploiter des modèles de diffusion préentraînés afin de générer des images, des vidéos et de l’audio. Dans Diffusers, une fonctionnalité centrale consiste à charger un modèle localement depuis un dépôt hébergé sur le Hub via l’API DiffusionPipeline. Ce processus s’appuie sur un fichier de configuration qui initialise des classes de pipeline et de composants, et il peut aussi déclencher du code personnalisé lié au pipeline.
Le mécanisme de protection évoqué dans l’analyse est le paramètre trust_remote_code. L’idée : contrôler si du code Python placé à l’intérieur d’un dépôt de modèle est autorisé à s’exécuter pendant le chargement via from_pretrained(). En théorie, passer à False (ou ne pas l’indiquer, ce qui constitue la valeur par défaut) doit empêcher l’exécution de code non vérifié.
Or, dans FaceHugger Diffusers, la protection se révèle contournable. Les chercheurs expliquent que le contrôle se place trop tôt dans la chaîne de chargement : toute méthode qui amène le chargeur à « voir » du code personnalisé que la vérification initiale n’a pas correctement pris en compte peut permettre de contourner le garde-fou.
Trois vulnérabilités regroupées sous FaceHugger
Les chercheurs ont identifié et documenté trois failles distinctes. Elles ont été reliées à des scénarios d’injection de code et à des problèmes de synchronisation lors du téléchargement, ce qui ouvre la voie à des variantes d’exécution à distance.
CVE-2026-44827 : injection de code via un pipeline forgé
La première faille, CVE-2026-44827 (score CVSS : 8.8), correspond à une injection de code. Le rapport indique qu’un attaquant peut charger du code arbitraire via le flux custom_pipeline depuis un dépôt sur le Hub, au moyen d’un pipeline conçu avec un nom de type « None.py », tout en respectant l’option trust_remote_code=False (ou en omettant le paramètre, donc en restant sur la valeur par défaut).
CVE-2026-45804 : condition de course pendant le téléchargement
La seconde faille, CVE-2026-45804 (score CVSS : 7.5), décrit une condition de course. Le principe : l’attaquant peut modifier la configuration entre deux appels HTTP successifs, dans la séquence impliquant hf_hub_download et snapshot_download. Cette fenêtre permet d’amener le système à exécuter du code introduit pendant la phase de récupération.
Le cœur du problème est présenté comme un scénario de type Time-of-Check to Time-of-Use (TOCTOU) : le contrôle de confiance n’est pas appliqué de manière « atomique » sur l’ensemble des éléments téléchargés, et l’enchaînement en deux requêtes non unifiées ouvre un espace d’exploitation.
CVE-2026-44513 : injection de code malgré trust_remote_code
La troisième vulnérabilité, CVE-2026-44513 (score CVSS : 8.8), est aussi une injection de code. Le rapport mentionne la possibilité de déclencher le chargement de code arbitraire via le flux custom_pipeline depuis un dépôt du Hub, même quand trust_remote_code est positionné à False ou laissé à sa valeur par défaut.
Ce qui se passe concrètement lors du chargement d’un modèle
Les chercheurs insistent sur un point : dans de nombreux systèmes d’IA, les artefacts provenant de dépôts de modèles sont traités comme des informations passives. Pourtant, la réalité du chargement dans Diffusers implique des fichiers de configuration, des chargeurs et du code de pipeline personnalisable. Dès lors, un « simple » import peut glisser vers un comportement qui ressemble à de l’exécution, transformant un téléchargement de modèle en vecteur d’accès.
Dans FaceHugger Diffusers, la faille structurelle est liée au fait que la vérification de confiance n’est effectuée que lors de la première phase du processus. Si la suite du chargement peut amener le système à récupérer ou reconnaître d’autres éléments de code sans repasser par la même logique de confiance, la protection devient inefficace.
Impact : qui est concerné
Après divulgation responsable, les correctifs ont été intégrés à Diffusers version 0.38.0, publiée au début du mois de mai 2026. Le rapport indique que l’impact concerne les usages où l’on invoque DiffusionPipeline.from_pretrained avec des pipelines personnalisés. Autrement dit, le scénario d’exploitation s’appuie sur la capacité à charger des pipelines qui ne proviennent pas d’une source de confiance clairement établie et audité.
Enfin, le contexte d’usage compte : les attaques peuvent tirer parti de la façon dont ces bibliothèques s’intègrent dans des chaînes de production, notamment via des systèmes automatisés (CI/CD) et des images prêtes à déployer.
Mesures immédiates recommandées (si le patch n’est pas possible)
Si la mise à jour ne peut pas être effectuée dans l’immédiat, les responsables du projet ont publié des recommandations de contournement. L’objectif est de réduire fortement les possibilités d’introduire du code non vérifié ou de limiter la surface d’exploitation.
- Limiter strictement les appels à from_pretrained : n’utiliser que des sources entièrement de confiance, en veillant à ce que les répertoires de snapshots locaux et les pipelines personnalisés proviennent d’un audit.
- Éviter un pipeline custom pointant vers un dépôt différent : ne pas passer custom_pipeline= en pointant vers un dépôt Hub différent de celui du paramètre pretrained_model_name_or_path avant de lire le fichier de pipeline principal (notamment pipeline.py).
- Inspecter les snapshots locaux : avant d’exécuter from_pretrained sur un snapshot local, contrôler la présence de fichiers *.py inattendus, en particulier sous des sous-répertoires de composants (unet/, scheduler/, etc.) et aussi à la racine du snapshot.
Ces garde-fous visent à éviter qu’un chargement censé traiter des fichiers de modèle se retrouve à exécuter un code Python introduit de manière sournoise.
Bonnes pratiques à retenir pour sécuriser votre chaîne ML
Au-delà du correctif, FaceHugger Diffusers rappelle une règle de base : les dépôts de modèles et leurs artefacts doivent être considérés comme potentiellement non fiables, surtout lorsqu’ils peuvent influencer la configuration et déclencher des pipelines personnalisés.
Concrètement, vous pouvez réduire le risque en combinant : mises à jour rapides des bibliothèques, gestion stricte des sources autorisées, validation des fichiers récupérés et contrôle des chemins par lesquels un code custom est admis. Dans un contexte entreprise, cela implique aussi d’intégrer ces vérifications dans les processus d’assemblage et de déploiement.
Conclusion
Les failles regroupées sous FaceHugger Diffusers montrent que la sécurité autour du chargement des modèles d’IA ne peut pas se limiter à un simple paramètre de confiance. Trois vulnérabilités—CVE-2026-44827, CVE-2026-45804 et CVE-2026-44513—illustrent comment des mécanismes de vérification placés au mauvais moment peuvent être contournés, menant à l’exécution de code arbitraire.
La bonne nouvelle, c’est que le correctif a été publié dans Diffusers 0.38.0. En attendant une mise à jour, appliquez les recommandations de contournement : sources auditées, absence de pipelines custom provenant d’endroits non cohérents, et inspection attentive des snapshots pour repérer tout fichier Python inattendu.
Source: https://thehackernews.com/2026/08/hugging-face-diffusers-flaws-could-let.html
