FaceHugger : Diffusers contourne trust_remote_code

Que sont les failles FaceHugger de Diffusers ?

Selon The Hacker News (3 août 2026), ce sont trois failles de la bibliothèque Python qui charge des modèles de diffusion dans des pipelines de production et de CI. Zafran Labs les a baptisées FaceHugger. Diffusers a été téléchargée plus de 8,1 millions de fois en juillet 2026 d'après pepy.tech.

trust_remote_code est l'option qui décide si la bibliothèque exécute du code Python livré dans un dépôt de modèle (pipelines personnalisés). Par défaut elle est désactivée : l'utilisateur doit accepter le risque. FaceHugger montre trois façons d'exécuter du code malgré cette protection.

Quelles sont les trois CVE ?

Zafran relie chaque variante à un défaut de type TOCTOU (vérification puis utilisation), parce que le contrôle de confiance n'est exécuté que sur la première requête. Pour les chercheurs, la cause racine est que le contrôle de confiance se trouve « entièrement dans la première phase ».

Quelles versions sont concernées ?

Le correctif est dans Diffusers 0.38.0, publiée début mai 2026. L'article ne nomme pas l'intervalle des versions affectées : il indique que tout utilisateur qui appelle DiffusionPipeline.from_pretrained avec des pipelines personnalisés est concerné. Considérez donc toute version antérieure à 0.38.0 comme à mettre à jour.

Que faire si vous ne pouvez pas mettre à jour tout de suite ?

Les mainteneurs proposent des mesures de contournement :

• n'utiliser from_pretrained qu'avec des sources auditées et entièrement fiables ;
• ne pas pointer custom_pipeline vers un autre dépôt du Hub sans relire d'abord son fichier de pipeline ;
• inspecter les instantanés locaux à la recherche de fichiers .py inattendus, en particulier dans les sous-répertoires de composants et à la racine de l'instantané.

Que faire pour toute application qui charge des modèles tiers ?

1. Mettez à jour Diffusers vers 0.38.0 ou plus, et la bibliothèque huggingface_hub avec elle.
2. Chargez les modèles dans un environnement isolé : conteneur ou machine éphémère sans identifiants, sans accès au réseau interne et sans accès aux secrets de l'application.
3. Épinglez les révisions : référencez un hachage de commit précis relu, pas une branche qui évolue. Un dépôt modifié après votre première récupération ne doit pas être rechargé automatiquement.
4. Préférez les formats de données pures (.safetensors) aux formats qui peuvent exécuter du code (pickle). Si un code personnalisé est indispensable, relisez-le et intégrez-le à votre dépôt plutôt que de le tirer à l'exécution.
5. Scannez les fichiers téléchargés comme n'importe quel binaire non fiable et recherchez les fichiers .py que vous n'attendez pas dans un instantané.
6. Réduisez les droits du processus qui charge : pas de clés cloud, jetons ni secrets inutiles dans son environnement.
7. Journalisez les modèles et révisions chargés : qui, quand, depuis quel dépôt.

Comment tester le chargement de modèles de votre pipeline ?

Dans un environnement de test isolé et avec autorisation.

1. Inventaire : listez chaque appel from_pretrained, chaque custom_pipeline et chaque dépôt référencé, avec la révision.
2. Version : vérifiez la version de Diffusers dans chaque image (pip show diffusers).
3. Dépôt sentinelle : créez un dépôt de test qui contient un fichier de pipeline écrivant un fichier marqueur inoffensif, et chargez-le sans trust_remote_code. Sur une version corrigée, rien ne doit s'exécuter.
4. Rayon d'action : depuis le processus de chargement, listez les identifiants, réseaux et fichiers accessibles. Chaque élément atteignable est un chemin de déplacement latéral.
5. Mise à jour du dépôt : modifiez le dépôt de test entre deux chargements et vérifiez que les révisions épinglées empêchent le changement de s'appliquer.
6. Alertes : une exécution inattendue de code dans le chargeur lève-t-elle une alerte ?

Pourquoi un défaut de type TOCTOU est-il si fréquent dans ce genre de chargement ?

Parce que le chargement d'un modèle se fait en plusieurs étapes, et que chaque étape peut lire un état différent. Dans le cas de Diffusers, la bibliothèque télécharge d'abord une configuration, vérifie qu'elle n'exige pas de code distant, puis télécharge le reste de l'instantané avec une seconde requête. Si le contenu du dépôt change entre les deux, ou si la seconde étape lit un chemin que la première n'a pas examiné, la vérification porte sur autre chose que ce qui est finalement exécuté.

Le remède de conception est de rendre le contrôle atomique : récupérer une révision précise, la figer, vérifier cet objet précis, puis ne charger que lui. Pour vos propres chargeurs, le même principe s'applique à tout artefact distant : on vérifie ce que l'on exécute, pas ce que l'on a vu une minute plus tôt.

Pour un utilisateur de la bibliothèque, la conséquence est de ne pas considérer une option par défaut comme une garantie. Épingler les révisions et isoler le processus de chargement protègent même quand une vérification interne est contournée.

Quel lien avec la chaîne d'approvisionnement de l'IA ?

FaceHugger fait suite à l'intrusion décrite dans l'article sur Hugging Face, OpenAI et les agents autonomes, où des chargeurs de jeux de données à code distant ont servi de point d'entrée. Les jeux de données, poids de modèles, tokenizers et codes de pipeline forment une chaîne d'approvisionnement qui doit être traitée comme npm ou PyPI : artefacts distants non fiables, versions épinglées, exécution en isolation. L'écosystème de l'IA a un outillage plus jeune et des réglages par défaut plus faibles, donc l'effort d'application de cette discipline vous revient.

Une option booléenne comme trust_remote_code ne suffit pas comme frontière de sécurité : la question est de savoir par combien de chemins le code peut contourner la vérification. Voir la page sécurité des agents IA.

Le Red Team Agent Express de CleanIssue (1 900 €, 5 jours) teste vos agents IA et leurs chaînes d'outils et de modèles : voir l'offre. Un rendez-vous découverte gratuit de 30 minutes suffit pour vérifier quels modèles distants votre pipeline autorise à exécuter du code.