Diffusers : le garde-fou qui laissait passer du code

Diffusers est la bibliothèque que beaucoup de projets utilisent pour charger des modèles de génération d’images, de vidéos ou d’audio. Pendant plusieurs mois, son garde-fou trust_remote_code pouvait pourtant être contourné : un dépôt de modèles soigneusement préparé pouvait faire exécuter du code Python sur la machine qui le chargeait. Trois failles ont été documentées, dont deux avec un score CVSS de 8,8. Le correctif existe depuis la version 0.38.0, mais le vrai sujet reste plus large : un modèle téléchargé n’est pas forcément un simple fichier de données.

Le dépôt de modèles n’est pas une boîte de poids

Diffusers propose une fonction pratique, DiffusionPipeline.from_pretrained, pour récupérer un modèle et construire automatiquement le pipeline correspondant. Cette commodité s’appuie sur des fichiers de configuration, des composants et, dans certains cas, des modules Python personnalisés. Le paramètre trust_remote_code est censé marquer la frontière : sans accord explicite, le chargeur doit refuser d’exécuter du code venu du dépôt.

Les avis de sécurité de la bibliothèque racontent une histoire moins rassurante. Avant 0.38.0, le contrôle était placé dans DiffusionPipeline.download, alors que le code dynamique était effectivement chargé plus loin, dans une autre étape. Les chemins locaux, les pipelines personnalisés et certains dépôts externes pouvaient donc passer à côté de la barrière. Un interrupteur de sécurité placé à côté de la porte n’aide pas beaucoup si les visiteurs entrent par la fenêtre.

Illustration documentaire consacrée aux failles de Diffusers. Source : The Hacker News, « Hugging Face Diffusers Flaws Could Let Model Repositories Execute Arbitrary Code » — https://thehackernews.com/2026/08/hugging-face-diffusers-flaws-could-let.html

Trois chemins pour contourner la confiance

La première faille, CVE-2026-44827, porte un nom presque comique : None.py. Quand aucun pipeline personnalisé n’est fourni, une valeur Python None pouvait être transformée en nom de fichier, puis en None.py. Un dépôt malveillant contenant ce fichier pouvait alors faire charger un module qui se faisait passer pour un pipeline légitime. Le développeur n’avait pas besoin d’ajouter trust_remote_code=True à son appel : c’est précisément le problème.

La deuxième, CVE-2026-45804, exploite une condition de course entre deux téléchargements. Diffusers vérifiait d’abord une configuration, puis récupérait l’instantané du dépôt dans une opération séparée. Si le contenu changeait entre ces deux requêtes, le contrôle pouvait regarder une version propre tandis que le chargeur recevait une version contenant du code Python personnalisé. Le dépôt devait être modifié au bon moment, mais un garde-fou qui dépend de deux réponses non atomiques n’est pas un garde-fou très solide.

La troisième famille, CVE-2026-44513, regroupait plusieurs variantes du même défaut de conception : le contrôle ne couvrait pas correctement les pipelines personnalisés provenant d’un autre dépôt, certains chargements depuis un instantané local ou des composants Python indiqués dans model_index.json. Dans ces scénarios, trust_remote_code=False pouvait être présent et ne pas empêcher l’exécution. Le score CVSS de 8,8 reflète le résultat possible : confidentialité, intégrité et disponibilité de la machine compromises, avec interaction de l’utilisateur.

Le correctif déplace enfin le verrou au bon endroit

Hugging Face a corrigé ces chemins dans Diffusers 0.38.0, publiée le 1er mai 2026. La modification importante n’est pas seulement une condition supplémentaire : le contrôle trust_remote_code a été déplacé vers get_cached_module_file, au point où les modules dynamiques sont réellement chargés. Les avis GitHub indiquent que les variantes concernées doivent désormais lever une erreur au lieu d’importer silencieusement du code non approuvé.

La recommandation officielle est donc simple : mettre à niveau avec une version au moins égale à 0.38.0. Les versions antérieures à 0.37.1 apparaissent comme concernées dans les avis, tandis que la version 0.38.0 est indiquée comme corrigée. Vérifie aussi les images de conteneur, les environnements virtuels, les cahiers d’expérimentation et les chaînes d’intégration continue : une bibliothèque vulnérable cachée dans un environnement oublié reste une bibliothèque vulnérable.

Ce qu’il faut contrôler dans un projet réel

Commence par inventorier les versions installées, y compris celles épinglées dans les fichiers de dépendances ou les images Docker. Cherche diffusers dans les verrous de paquets, les environnements de calcul et les scripts qui appellent from_pretrained. Un simple pip list sur le poste de développement ne couvre pas forcément le serveur qui reconstruit les modèles pendant une tâche planifiée.

Ensuite, traite chaque dépôt de modèles comme un artefact potentiellement actif. Épingle une révision lorsque le dépôt le permet, vérifie les fichiers Python inattendus et évite de charger un pipeline personnalisé dont le code n’a pas été lu. L’option trust_remote_code n’est pas une permission à distribuer machinalement : c’est une décision de confiance qui doit être documentée, limitée et surveillée.

Enfin, mets à jour les contrôles autour du chargeur. Exécute l’inférence dans un environnement isolé, limite les secrets accessibles au processus et conserve les journaux des téléchargements et des imports. Ces mesures ne remplacent pas la mise à niveau, mais elles évitent qu’un futur défaut de chargement transforme un modèle populaire en cheval de Troie distribué à grande échelle.

Le modèle n’est pas innocent parce qu’il porte une extension banale

L’affaire Diffusers rappelle une confusion fréquente dans l’IA open source : on parle de « modèle » comme s’il s’agissait d’un bloc de nombres inerte, alors que l’écosystème transporte aussi des configurations, des classes et des composants exécutables. La confiance ne doit donc pas s’arrêter au nom du dépôt ni au nombre d’étoiles affiché sur sa page. Elle doit suivre chaque étape du téléchargement au chargement.

Mets Diffusers à jour, audite les dépôts déjà utilisés et considère trust_remote_code comme une frontière de sécurité, pas comme une case décorative. Sinon, le prochain modèle téléchargé pourrait bien avoir une idée très personnelle de ce que signifie « générer ».

Sources

Hugging Face Diffusers, avis GHSA-j7w6-vpvq-j3gm « None.py Trust Remote Code Bypass », publié le 1er mai 2026 — https://github.com/huggingface/diffusers/security/advisories/GHSA-j7w6-vpvq-j3gm — détail du contournement par None.py, de l’impact et du correctif.

Hugging Face Diffusers, avis GHSA-7wx4-6vff-v64p « TOCTOU Trust Remote Code Bypass », publié le 20 mai 2026 — https://github.com/huggingface/diffusers/security/advisories/GHSA-7wx4-6vff-v64p — description de la course entre les téléchargements et du CVE-2026-45804.

Hugging Face Diffusers, avis GHSA-98h9-4798-4q5v « trust_remote_code bypass via custom_pipeline and local custom components » — https://github.com/huggingface/diffusers/security/advisories/GHSA-98h9-4798-4q5v — variantes du CVE-2026-44513 et procédure de mise à niveau.

NVD, CVE-2026-44827, CVE-2026-45804 et CVE-2026-44513 — https://nvd.nist.gov/vuln/detail/CVE-2026-44827 — https://nvd.nist.gov/vuln/detail/CVE-2026-45804 — https://nvd.nist.gov/vuln/detail/CVE-2026-44513 — enregistrement des versions touchées, scores et références.

The Hacker News, « Hugging Face Diffusers Flaws Could Let Model Repositories Execute Arbitrary Code », 3 août 2026 — https://thehackernews.com/2026/08/hugging-face-diffusers-flaws-could-let.html — recoupement journalistique et illustration documentaire créditée.

—

Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.