Quand les fichiers de modèles deviennent un risque de sécurité dans PyTorch lightning

PyTorch Lightning présente des vulnérabilités critiques en matière de désérialisation

Les vulnérabilités de désérialisation ne sont pas nouvelles, mais elles sont particulièrement dangereuses dans les environnements d’apprentissage automatique où l’automatisation est omniprésente. PyTorch Lightning, un cadre largement utilisé pour entraîner de grands modèles d’intelligence artificielle, a révélé plusieurs faiblesses importantes. Ces failles permettent aux attaquants de glisser du code malveillant dans les fichiers de modèles. Une fois que ces fichiers sont chargés par des systèmes automatiques, tels que des pipelines de formation ou des services d’inférence en temps réel, le code s’exécute sans avertissement. C’est ainsi qu’un fichier de modèle se transforme en point d’accès à distance.

Les fonctions au cœur de ce problème, torch.load() et pickle de Python, manipulent les fichiers de modèles de manière non sécurisée. Ce sont les outils qui lisent les données de modèle sauvegardées, qui se trouvent généralement dans des fichiers .ckpt ou .pt. Mais ils ne vérifient pas le contenu. Pas de validation. Pas de sandboxing. Ainsi, si un mauvais acteur crée un fichier modèle avec la bonne charge utile, ce système charge le fichier, et boum, un code non autorisé s’exécute dans votre environnement.

Le CERT/CC, basé à Carnegie Mellon, a étiqueté ce problème VU#252619. Il affecte toutes les versions de PyTorch Lightning jusqu’à la version 2.4.0 incluse. Kasimir Schulz de HiddenLayer a découvert la vulnérabilité et a travaillé avec le CERT pour la divulguer. Schulz a trouvé les surfaces d’attaque cachées dans plusieurs sous-modules. Le point de contrôle distribué charge les données sur les nœuds de calcul sans vérification. Cloud_IO récupère des modèles à partir de périphériques locaux, d’URL ou de flux, là encore sans vérification. Le chargement paresseux reporte l’exécution du code mais ne vérifie pas ce qui est reporté. L’intégration de DeepSpeed ajoute plus de chances de désérialiser des états de modèles non sûrs. Et le PickleSerializer ? Il utilise directement Pickle de Python sans aucune défense.

Il s’agit d’une structure de sécurité qui doit être réévaluée. Les équipes d’IA automatisent souvent chaque échange de modèles, de la formation au déploiement. Si votre système récupère des modèles à partir de téléchargements de clients, de hubs de modèles ou d’autres sources que vous ne contrôlez pas entièrement, vous êtes vulnérable. À l’échelle de l’entreprise, c’est un gros problème.

Les frameworks tels que PyTorch Lightning permettent de développer rapidement l’IA. Mais ils élargissent aussi discrètement votre surface de risque. Si quelqu’un introduit un modèle compromis dans votre pipeline et que celui-ci l’exécute sans poser de questions, vous venez d’automatiser votre propre violation.

Traitez les fichiers modèles comme vous le feriez pour un logiciel. En les examinant de près. En les isolant. Avec vérification. Sinon, vous donnez aux attaquants une clé de déverrouillage de votre infrastructure, ce qui est inacceptable compte tenu de l’évolution des choses à grande échelle.

L’adoption généralisée de PyTorch Lightning amplifie ces vulnérabilités.

PyTorch Lightning est devenu un élément fondamental des opérations mondiales d’apprentissage automatique. Il est utilisé dans la recherche universitaire, les produits d’IA commerciaux et les pipelines d’IA d’entreprise, de l’expérimentation de modèles au déploiement à grande échelle. Son rôle est de simplifier les tâches complexes d’apprentissage de modèles, de distribuer les charges de travail sur le matériel et de les faire évoluer sur les GPU. Cette efficacité et cette portée sont exactement ce qui rend les vulnérabilités actuelles significatives.

En mars 2025, le cadre avait été téléchargé plus de 200 millions de fois. Il est cité dans des milliers d’articles de recherche évalués par des pairs. Il s’agit donc de l’un des cadres d’apprentissage automatique de haut niveau les plus largement adoptés à l’heure actuelle. Lorsqu’une plateforme atteint un tel niveau d’adoption, toute faille qu’elle comporte peut avoir un impact sur des secteurs entiers. Si une vulnérabilité permet aux attaquants d’exécuter un code arbitraire, et que cette vulnérabilité est intégrée dans les flux de travail d’innombrables équipes d’intelligence artificielle dans le monde, l’ampleur de l’exposition potentielle est énorme.

Cela va bien au-delà des laboratoires de recherche. Les entreprises intègrent PyTorch Lightning dans des environnements de production, des pipelines automatisés, des systèmes industriels, des services en temps réel et des applications orientées client. Si ces systèmes chargent des modèles infectés à partir de sources non fiables, qu’ils soient générés en interne, fournis par des fournisseurs ou téléchargés à partir de référentiels en ligne, ils deviennent des points d’entrée pour les attaquants. Et de nombreux systèmes le font automatiquement, sans qu’aucun humain ne soit impliqué.

Pour les dirigeants, ce niveau d’exposition systémique doit être pris au sérieux. La gestion standard des risques informatiques peut ne pas tenir compte du fonctionnement de l’infrastructure des modèles d’IA, en particulier lorsque les fichiers modèles peuvent effectivement contenir un contenu exécutable. Le modèle de confiance autour de ces fichiers est fondamentalement défectueux s’il suppose qu’il s’agit de structures de données passives. Ce n’est pas le cas. Ils exécutent du code et s’ils sont manipulés, ce code peut être transformé en arme.

Les organisations les plus exposées sont celles dont les piles d’IA sont fortement automatisées. Si vous avez construit des pipelines CI/CD pour la ML, intégré des registres de modèles ou créé des API qui chargent des modèles en temps réel, c’est là que se cache cette vulnérabilité. À l’échelle, la plupart des entreprises ne vérifient pas manuellement chaque fichier entrant en production, et c’est exactement ce dont dépendent les attaquants.

L’adoption généralisée apporte un avantage sur le marché, mais elle s’accompagne également d’une plus grande responsabilité. Lorsqu’un outil représente une part aussi importante de votre infrastructure, assurez-vous qu’il est conçu pour résister aux menaces du monde réel. Ne partez pas du principe que l’outil est sûr simplement parce qu’il est populaire. L’expansion sans protection conduit à une exposition systémique, avec des conséquences qui vont bien au-delà de votre équipe de développement.

Les mesures d’atténuation recommandées mettent l’accent sur la validation stricte, l’isolement et l’audit complet des flux de travail liés à la manipulation des modèles.

Il n’existe pas encore de correctif pour les vulnérabilités de PyTorch Lightning. Cela signifie que le fardeau de la protection repose sur la façon dont les organisations conçoivent leurs flux de travail. Il s’agit de valider ce qui entre dans votre système, de restreindre la façon dont les modèles sont chargés et de limiter l’exécution de code non fiable.

Le CERT/CC a formulé des conseils techniques, qui sont solides. Commencez par la confiance. Ne chargez pas de fichiers de modèle à partir de sources non authentifiées ou non vérifiées. Cela inclut tout ce qui provient de partenaires, de dépôts ouverts ou de fichiers téléchargés par des utilisateurs. L’ingestion automatisée est utile, mais si elle n’est pas encadrée par une validation, elle transforme une commodité en une responsabilité.

Deuxièmement, utilisez des contrôles de désérialisation restreints. PyTorch fournit un mode, weights_only=True dans torch.load(), qui empêche l’exécution du contenu non tensoriel. Ce mode permet d’éliminer le code actif du processus de chargement. Si vos modèles n’ont pas besoin de définitions de couches ou d’états d’optimiseurs provenant de sources externes, ne prenez pas le risque de les charger.

Troisièmement, isolez les fichiers à risque. Tout ce qui provient de l’extérieur de votre réseau de confiance doit être traité dans des environnements restreints et en bac à sable. Il est judicieux d’utiliser des conteneurs à privilèges limités. Ne laissez jamais des fichiers modèles externes s’exécuter dans des environnements ayant accès aux systèmes de production, aux bases de données ou à d’autres ressources internes. Partez du principe que tout fichier non vérifié présente un potentiel hostile.

Quatrièmement, procédez à une inspection avant l’exécution. Le format pickle de Python peut être analysé à l’aide d’outils tels que pickletools. Cela permet de révéler des schémas inhabituels ou suspects dans les objets sérialisés. Ce n’est pas une solution complète, mais il est plus difficile pour les charges utiles malveillantes de se faufiler sans que personne ne s’en aperçoive.

Enfin, vérifiez votre automatisation. Examinez et révisez les pipelines CI/CDles registres de modèles et les services de déploiement pour vous assurer qu’ils ne chargent pas automatiquement des modèles non vérifiés. Cela inclut les outils internes et les intégrations tierces. Créez des points de contrôle dans le flux de travail qui forcent la validation humaine ou programmatique. Réduisez la confiance automatique lorsque des modèles sont impliqués.

Pour les dirigeants de C-suite, le point est clair : si vos opérations d’IA reposent sur la vitesse et l’automatisation, les protections doivent être intégrées dans le système dès la conception, et non par hypothèse. Chaque interface de modèle doit être régie par des contrôles de sécurité intentionnels. Car même si les développeurs agissent rapidement, l’infrastructure dont ils dépendent doit être construite pour résister aux perturbations, et pas seulement pour permettre les performances.

Les vulnérabilités de PyTorch Lightning reflètent des risques plus larges dans l’infrastructure de ML.

Ce que nous constatons avec PyTorch Lightning n’est pas un incident isolé. Il s’agit d’un problème plus large qui touche l’ensemble des écosystèmes modernes d’apprentissage automatique, à savoir l’absence d’une conception axée sur la sécurité dans les outils de base. Ces vulnérabilités ne sont pas le résultat d’attaques exotiques. Elles proviennent de points faibles prévisibles tels que la désérialisation non sécurisée, qui sont connus depuis des années dans le domaine de la sécurité des logiciels. Pourtant, dans de nombreux frameworks de ML, ces problèmes sont encore traités comme s’il s’agissait de préoccupations secondaires.

Dans ce cas, les failles de désérialisation permettent au code intégré de s’exécuter lorsque les modèles sont chargés. Ceci n’est pas limité à PyTorch Lightning, c’est un risque connu dans PyTorch lui-même et dans d’autres chaînes d’outils de ML. C’est là que se situe le véritable problème. La structure de la pile d’apprentissage automatique donne souvent la priorité à la flexibilité, à la vitesse et à l’efficacité des développeurs. La sécurité est ajoutée plus tard, de manière sélective, voire pas du tout.

Les entreprises s’orientent de plus en plus vers des pipelines de ML automatisés et des services alimentés par l’IA. Ces pipelines dépendent de fichiers de modèles sérialisés. Mais de nombreux outils traitent encore ces fichiers comme des données statiques, et non comme des vecteurs d’exécution de code. Cette hypothèse crée des lacunes dans la modélisation des menaces. Ces lacunes se creusent au fur et à mesure que les systèmes évoluent. Lorsque les artefacts de modèle sont transmis entre les équipes, les environnements ou les outils, parfois même partagés publiquement, le risque se multiplie.

Pour les dirigeants, la réalité est que l’infrastructure d’apprentissage automatique doit désormais être considérée sous le même angle de sécurité que l’ingénierie logicielle, mais adaptée aux caractéristiques uniques des systèmes d’IA. Les modèles peuvent inclure des chemins d’exécution. Tout fichier pouvant déclencher du code doit être régi comme un binaire d’application.

Le problème fondamental est la confiance. Une trop grande partie de l’infrastructure ML actuelle fait confiance à tout ce qu’elle touche, aux sources de fichiers distantes, au contenu sérialisé, aux flux de travail automatisés. Cette confiance est rarement acquise et elle est souvent implicite dans la conception. Si les dirigeants ne remettent pas systématiquement en question ces hypothèses, les équipes finissent par construire une infrastructure exploitable de par sa conception.

À long terme, la solution ne réside pas dans des correctifs ponctuels. Il s’agit d’un changement d’état d’esprit. Les paramètres par défaut sécurisés doivent devenir la norme dans tous les outils d’intelligence artificielle. Les outils doivent valider ce qu’ils chargent. L’automatisation ne peut pas être aveugle. Et les artefacts au niveau du modèle doivent faire l’objet du même examen minutieux que les déploiements de code.

Si votre organisation dépend de l’apprentissage automatique, et c’est le cas de la plupart d’entre elles, la sécurité des modèles n’est pas un cas technique marginal. Il s’agit d’une exigence fondamentale pour la résilience opérationnelle et la confiance des parties prenantes. La surface d’attaque ne fera que croître. Pour la devancer, il faut construire des systèmes qui se défendent par défaut. Cette responsabilité commence au niveau de l’architecture.

Les fichiers modèles doivent être traités avec la même attention et les mêmes protocoles de risque que le code exécutable.

Trop souvent, les fichiers de modèles sérialisés sont considérés comme un contenu passif : des poids mathématiques, des définitions d’architecture ou des résultats de formation. En réalité, nombre de ces fichiers contiennent des instructions exécutables qui sont traitées au chargement. Cela les place dans la même catégorie de risque que les binaires ou les scripts d’application qui s’exécutent dans votre système.

Les vulnérabilités révélées dans PyTorch Lightning mettent en évidence le danger de cette façon de penser. Lorsqu’un fichier modèle peut contenir un code malveillant intégré et que ce code s’exécute automatiquement lors de la désérialisation, il ne s’agit pas simplement d’un fichier de données. Il devient un vecteur d’attaque. Ce comportement est connu, documenté et largement non atténué dans de nombreux frameworks ML, et pas seulement dans PyTorch Lightning.

Ce que cela signifie pour les dirigeants de la suite est simple. Si votre infrastructure utilise l’IA et que vous tirez des modèles d’équipes internes, de partenaires, de sous-traitants ou de référentiels tiers, l’ingestion de modèles devient une opération critique en termes de sécurité. Tout point du pipeline qui charge un fichier de modèle doit être régi avec la même discipline que le déploiement de code. Cela inclut le contrôle d’accès, la vérification de l’origine, l’audit des modifications et l’isolation de l’environnement.

Dans les environnements de production, en particulier les infrastructures partagées ou les environnements multi-locataires, les enjeux sont encore plus importants. Tout modèle introduit depuis l’extérieur du périmètre de confiance constitue un exploit potentiel. Si votre équipe automatise les mises à jour de modèles ou utilise des fonctions de plate-forme en libre-service, revoyez ces flux de travail dès maintenant. Assurez-vous qu’ils n’acceptent pas de nouveaux modèles sans validation et sans application des limites.

Avec plus de 200 millions de téléchargements de PyTorch Lightning et une intégration généralisée dans les systèmes universitaires et d’entreprise, les modèles compromis ne resteront pas isolés. Les attaquants savent que cette faille existe. L’intérêt de l’exploiter est élevé, et l’effort à fournir pour le faire est faible avec les paramètres par défaut actuels.

Les responsables opérationnels doivent s’assurer que leur organisation applique des normes de risque holistiques à tous les flux de travail d’inférence et de formation. Il s’agit notamment d’appliquer des protocoles de sécurité non seulement au code source ou aux couches d’infrastructure, mais aussi directement au niveau du modèle. Les outils sur lesquels vos équipes s’appuient doivent offrir des contrôles qui sécurisent l’ensemble du cycle de vie des ML, depuis la création et la sérialisation des modèles jusqu’au déploiement et à la surveillance.

Ignorer les risques liés aux fichiers de modèles introduit une faiblesse systémique dans votre stratégie d’IA. Traiter les modèles comme des objets sécurisés exige un changement dans la façon dont nous construisons, testons et déployons les systèmes d’apprentissage automatique. Ce changement doit commencer dès aujourd’hui, et non pas après une violation.

Principaux enseignements pour les décideurs

• Des failles de sécurité permettent des attaques intégrées : PyTorch Lightning contient des vulnérabilités critiques de désérialisation qui permettent à des fichiers de modèles malveillants d’exécuter du code au chargement. Les dirigeants doivent s’assurer que les équipes d’ingénieurs considèrent le chargement de modèles comme un vecteur de menace potentiel et isolent les fichiers non fiables en conséquence.
• L‘adoption massive amplifie l’exposition : avec plus de 200 millions de téléchargements et une intégration profonde dans les entreprises, ces failles peuvent avoir un impact sur les pipelines de ML automatisés à l’échelle mondiale. Les dirigeants devraient réévaluer l’exposition au risque dans l’ensemble de l’infrastructure d’IA et donner la priorité à la sécurisation des outils largement adoptés.
• Les mesures d’atténuation exigent une discipline opérationnelle : Il n’existe pas encore de correctif, ce qui rend essentiel un contrôle rigoureux des processus. Les organisations doivent renforcer les frontières de confiance, limiter la portée de la désérialisation, mettre en bac à sable les fichiers non vérifiés et valider les modèles avant leur exécution.
• Le risque est systémique et non isolé : Ces lacunes en matière de sécurité sont le reflet d’un problème plus large concernant les outils de ML, qui privilégient la rapidité à la sécurité. Les dirigeants doivent appliquer des valeurs par défaut sécurisées et préconiser des choix d’infrastructure qui traitent les fichiers de modèle avec la même prudence que les exécutables.
• Les fichiers modèles doivent être gérés comme du code : Les fichiers modèles ne sont pas des actifs passifs, ils peuvent contenir du code actif et exploitable. La stratégie de l’exécutif devrait exiger des politiques de gouvernance des modèles qui correspondent à la rigueur utilisée pour les déploiements de logiciels.