Avec plus de 2,2 milliards d’installations, le package Python défectueux offre aux attaquants un vaste rayon d’action, y compris un accès silencieux aux utilisateurs d’entreprise de grande valeur exécutant une inférence accélérée par GPU.
Une vulnérabilité de haute gravité dans Hugging Face Transformers permet aux attaquants de compromettre les systèmes qui utilisent la populaire bibliothèque Python pour tester et exécuter des modèles d’IA. La faille affecte les versions de bibliothèque qui continuent d’être activement téléchargées et survient à un moment où les attaquants ciblent de plus en plus la chaîne d’approvisionnement de l’IA, notamment via des modèles malveillants hébergés sur la plateforme Hugging Face.
L’exploit de cette vulnérabilité consiste à ajouter un paramètre d’apparence inoffensive appelé _attn_implementation_internal aux fichiers de configuration de modèle distant sur Hugging Face et contourne le trust_remote_code=false indicateur qui empêche normalement l’exécution du code distant accompagnant les modèles.
« Le champ malveillant utilise un nom préfixé par un trait de soulignement qui ressemble à un détail d’implémentation interne – le type de champ dont regorgent les fichiers de configuration », ont déclaré les chercheurs de Pluto Security qui ont découvert la vulnérabilité dans leur rapport. « Il n’y a aucun avertissement d’exécution, aucune invite de consentement, aucune entrée de journal inhabituelle. »
La bibliothèque Hugging Face Transformers permet aux développeurs Python de déployer plus d’un million de variantes de modèles d’apprentissage automatique hébergées sur Hugging Face sur leur matériel local ou leurs instances cloud. Il est utilisé dans de nombreux environnements d’entreprise et pipelines CI/CD pour tester des modèles pré-entraînés pour diverses tâches et pour les affiner avec des données propriétaires.
Le package PyPI Hugging Face Transformers est téléchargé plus de 146 millions de fois par mois et compte à ce jour un total de 2,2 milliards d’installations. Le projet est également l’un des référentiels les mieux notés sur GitHub avec plus de 161 000 étoiles, le rayon d’action d’une vulnérabilité d’exécution de code à distance (RCE) est donc énorme.
Cette faille jusqu’alors non divulguée, désormais identifiée comme CVE-2026-4372, a été corrigée silencieusement dans Transformers 5.3.0, publiée le 3 mars, mais elle affecte toutes les versions publiées depuis août à partir de la 4.56.0. Les versions vulnérables continuent d’être téléchargées 7 à 8 millions de fois par semaine et représentent environ un quart des installations hebdomadaires.
Les noyaux « attention » personnalisés contournent les défenses RCE
Les modèles d’IA hébergés sur Hugging Face peuvent contenir du code Python personnalisé, qui peut présenter un risque de sécurité sérieux s’il est téléchargé et exécuté automatiquement avec le modèle. Dans le passé, des attaquants ont abusé de cette fonctionnalité. C’est pourquoi un paramètre appelé trust_remote_code: a été ajouté aux configurations. Lorsqu’il est défini sur false, il est destiné à donner aux développeurs l’assurance que du code supplémentaire ne sera pas automatiquement exécuté.
Cependant, en mars de l’année dernière, Hugging Face a ajouté une fonctionnalité appelée Hub Kernels qui permet aux utilisateurs d’héberger des noyaux d’attention compilés personnalisés. Ces noyaux améliorent les performances des modèles lorsqu’ils sont chargés sur des GPU et nécessitent un package supplémentaire appelé noyaux.
La présence de ce package sur la machine est nécessaire pour exploiter cette vulnérabilité, ce qui constitue à première vue un facteur limitant. Cependant, même s’il s’agit d’une dépendance facultative, l’installation du package du noyau n’est pas rare, en particulier parce que la plupart des utilisateurs qui exécutent des modèles d’IA locaux souhaitent bénéficier de l’accélération GPU et installeront Transformers avec tous les packages « extras ».
« Les utilisateurs qui travaillent avec l’inférence accélérée par GPU – sans doute les cibles les plus précieuses – sont les plus susceptibles de l’avoir installé », ont déclaré les chercheurs. « Les plates-formes Enterprise ML et les clusters GPU installent généralement toutes les dépendances facultatives pour maximiser l’utilisation du matériel. »
La vulnérabilité est le résultat de trois décisions de conception distinctes prises dans le code qui se combinent pour introduire le risque RCE silencieux. Premièrement, lorsque le chargement du modèle est invoqué avec AutoModelForCausalLM.from_pretrained(“model-name”) la bibliothèque procède au téléchargement de la configuration, des poids et du tokenizer du modèle à partir du Hub, assemble l’architecture correcte et renvoie un modèle prêt à l’emploi à l’application.
Le code qui analyse le modèle config.json le fichier utilise une fonction appelée setattr qui analyse chaque paire clé-valeur du fichier et la charge dans l’objet de configuration, mais ne fait pas la différence entre les paramètres configurables par l’utilisateur et les paramètres internes commençant par le _ personnage. De tels paramètres internes ne doivent jamais être présents dans une configuration fournie par l’utilisateur, car ils ne sont pas destinés à être modifiés par les développeurs.
L’un de ces paramètres internes est _attn_implementation_internalqui est utilisé pour contrôler l’implémentation du mécanisme d’attention utilisée par le modèle : Flash Attention, SDPA ou l’implémentation hâtive par défaut.
Par ailleurs, le hub_kernels.py Le composant vérifie la valeur de ce paramètre et s’il est défini sur un modèle qui correspond à deux chaînes séparées par / il suppose qu’il s’agit d’une définition de propriétaire/référentiel provenant du Kernels Hub. Le code procède ensuite au téléchargement du noyau à partir du référentiel défini et à son exécution.
« Pas de sandboxing. Pas de signature de code. Pas de vérification d’intégrité. Pas d’invite utilisateur », ont déclaré les chercheurs. « Juste une importation brute du code Python présent dans le référentiel de l’attaquant, y compris tout ce qui se trouve dans le référentiel de l’attaquant. __init__.pyqui s’exécute automatiquement lors de l’importation.
En raison de ces trois questions indépendantes — la setattrl’attribut interne non protégé et le chargeur de noyau sans bac à sable — l’exploitation devient triviale : publiez un modèle attrayant avec une configuration qui inclut _attn_implementation_internal réglé sur attacker-repo/malicious-kernel.
Les attaques sur la chaîne d’approvisionnement via des modèles d’IA malveillants se multiplient
Il ne s’agit pas d’une attaque inhabituelle. Des modèles malveillants sont constamment téléchargés sur Hugging Face et peuvent réussir à tromper les utilisateurs. Le mois dernier, un dépôt malveillant Hugging Face se faisant passer pour une nouvelle version du modèle de filtre de confidentialité d’OpenAI a atteint la première place des tendances sur la plateforme en 18 heures et a été téléchargé 244 000 fois. Le code du modèle contenait un malware infostealer pour Windows.
L’année dernière, des chercheurs ont montré comment des attaquants pouvaient cacher du code malveillant dans des fichiers Python Pickle, un format couramment utilisé pour distribuer des modèles d’IA.
Cette vulnérabilité de Transformers n’est pas la première à permettre l’exécution de code à distance via des modèles d’IA conçus de manière malveillante. Le mois dernier, des chercheurs de la société de sécurité HiddenLayer ont révélé une vulnérabilité RCE dans ChromaDB qui permettait à des attaquants distants non authentifiés de tromper les serveurs Chroma pour qu’ils exécutent du code malveillant à partir de configurations de modèles hébergées sur Hugging Face.
Plus tôt le même mois, les mêmes chercheurs ont montré comment l’exécution de code à distance peut être réalisée en apportant des modifications mineures aux paramètres d’un modèle. tokenizer.json fichier, qui est utilisé pour mapper les ID de jeton à des mots et des caractères créant un alphabet que le modèle utilise pour générer ses sorties.
Atténuation
Avec l’augmentation du nombre de telles attaques sur la chaîne d’approvisionnement, la mise en place de contrôles de la provenance des modèles devient très importante pour les organisations qui expérimentent l’IA et l’apprentissage automatique.
L’équipe de recherche en IA de Cisco a récemment publié un outil open source appelé Model Provenance Kit qui utilise les empreintes digitales des poids de modèle, des tokenizers et des métadonnées d’architecture pour déterminer si un modèle d’apprentissage automatique dérive de l’une des plus de 45 familles de modèles de base connues de plus de 20 éditeurs de confiance, y compris les principaux laboratoires d’IA.
Cela dit, les chercheurs de Pluto Security conseillent aux organisations de traiter les API de chargement de modèles d’IA et de désérialisation de configuration dans les frameworks et bibliothèques ML comme des surfaces d’exécution de code, quels que soient les indicateurs de sécurité qu’elles fournissent.
Cela signifie que le chargement du modèle doit être effectué en bac à sable et isolé dans des conteneurs surveillés qui n’ont pas accès aux informations d’identification de l’hôte, à l’accès au réseau sortant et aux autorisations étendues du système de fichiers. Les fichiers de configuration doivent également être analysés avant le chargement et vérifiés pour détecter les champs inattendus, y compris ceux précédés d’un trait de soulignement.
Les utilisateurs de Transformers doivent immédiatement passer à la version 5.3.0 et rechercher _attn_implementation_internal dans n’importe quel cache ou téléchargé config.json fichiers pour déterminer s’ils ont été ciblés.
