Une vulnérabilité dans la bibliothèque Python PLY (Python Lex-Yacc) permet à des attaquants d’exécuter du code arbitraire sur des systèmes vulnérables, ce qui suscite des inquiétudes pour les applications qui s’appuient sur des tables d’analyse syntaxique mises en cache.
La faille, qui concerne la version 3.11 de PLY distribuée via PyPI, dispose d’une preuve de concept (PoC) accessible au public et permet l’exécution de code à distance au démarrage de l’application.
Cette vulnérabilité permet aux attaquants « … d’exécuter du code arbitraire, d’exécuter du code au démarrage de l’application et d’exécuter du code avant même que la moindre logique d’analyse syntaxique ne soit atteinte », ont déclaré des chercheurs dans l’avis.
La faille de désérialisation pickle
PLY est largement intégré à des applications Python qui implémentent des analyseurs syntaxiques personnalisés, notamment des compilateurs, des moteurs de configuration et des langages spécifiques à un domaine.
Dans nombre de ces systèmes, l’initialisation de l’analyseur syntaxique intervient tôt dans le cycle de vie de l’application et est implicitement considérée comme fiable.
Par conséquent, les vulnérabilités à ce niveau peuvent avoir un impact disproportionné et potentiellement entraîner la compromission complète du système avant même que la plupart des contrôles de sécurité ne soient actifs.
Le problème, référencé sous l’identifiant CVE-2025-56005, présente un niveau de risque élevé, car son exploitation ne dépend pas de l’analyse d’une entrée malveillante.
Au contraire, le code vulnérable s’exécute avant le début de la logique d’analyse syntaxique, ce qui rend largement inefficaces la validation traditionnelle des entrées, le bac à sable et la surveillance de l’exécution.
Au cœur de la vulnérabilité se trouve un paramètre non documenté, picklefile, dans la fonction yacc() de la version 3.11 de PLY.
Lorsque ce paramètre est défini, PLY tente de charger depuis le disque des tables d’analyse syntaxique mises en cache à l’aide de la fonction pickle.load() de Python, sans effectuer le moindre contrôle d’intégrité, de validation ou de vérification de l’origine du fichier désérialisé.
Ce comportement est dangereux, car le module pickle de Python est intrinsèquement dangereux pour les données non fiables.
Lors de la désérialisation, les objets peuvent définir une méthode __reduce__() qui exécute du code arbitraire.
Par conséquent, le chargement d’un fichier pickle malveillant garantit l’exécution de code, souvent avant l’initialisation complète de la journalisation de l’application, de l’instrumentation de sécurité ou des restrictions de privilèges.
En pratique, un attaquant capable d’influencer le chemin ou le contenu du fichier pickle peut exécuter des commandes système arbitraires en déclenchant simplement l’initialisation de l’analyseur syntaxique.
Une preuve de concept accessible au public montre que lorsque yacc(picklefile=”exploit.pkl”) charge un fichier pickle conçu pour l’attaque contenant une charge utile __reduce__() malveillante, l’exécution du code se produit immédiatement, sans intervention de l’utilisateur ni entrée à analyser.
Exploitation
L’exploitation devient possible dans les environnements où les fichiers de tables d’analyse syntaxique peuvent être contrôlés, remplacés ou autrement empoisonnés.
Parmi les scénarios d’exploitation possibles figurent les répertoires de tables d’analyse syntaxique mises en cache stockés sur disque, les systèmes de fichiers réseau partagés auxquels plusieurs services accèdent, les artefacts de pipelines CI/CD réutilisés d’une compilation à l’autre et les chemins de fichiers définis par l’application qui sont accessibles en écriture ou configurables.
Comme ces ressources sont souvent considérées comme des composants internes fiables, elles peuvent ne pas bénéficier d’une surveillance ou de contrôles d’intégrité adéquats, ce qui augmente la probabilité d’une compromission non détectée.
Réduire les risques liés à l’exécution de code au démarrage
Comme cette vulnérabilité permet l’exécution de code au démarrage de l’application, les organisations doivent s’attacher à empêcher les désérialisations non sécurisées et à limiter la confiance accordée aux artefacts liés aux analyseurs syntaxiques.
La simple validation des entrées au moment de l’exécution est insuffisante lorsque l’exploitation intervient avant l’activation des contrôles de sécurité habituels.
Une approche défensive combinant revue de code, renforcement du système de fichiers et protections des pipelines de compilation est importante pour contribuer à réduire les risques.
- Auditez les applications qui utilisent le paramètre picklefile non documenté et évitez, lorsque c’est possible, de charger les tables d’analyse syntaxique depuis le disque.
- Considérez tous les fichiers pickle comme des entrées non fiables et éliminez les chemins de désérialisation non sécurisés lors de l’initialisation de l’analyseur syntaxique.
- Limitez les emplacements du cache de l’analyseur syntaxique à des répertoires non accessibles en écriture et appliquez des permissions strictes au système de fichiers.
- Renforcez les pipelines CI/CD pour prévenir l’empoisonnement des artefacts et les modifications non autorisées des sorties de compilation.
- Exécutez l’initialisation de l’analyseur syntaxique dans des environnements d’exécution isolés ou dotés du minimum de privilèges afin de limiter l’impact en cas d’exploitation.
- Surveillez les chemins de fichiers critiques et le comportement au démarrage afin de détecter les modifications inattendues de fichiers ou l’exécution de processus.
- Intégrez les scénarios de désérialisation non sécurisée aux opérations de sécurité et testez régulièrement les plans de réponse aux incidents afin de tenir compte de l’exécution de code au démarrage.
Ces mesures contribuent à contenir le périmètre d’impact d’une exploitation et à renforcer la résilience face aux compromissions au démarrage qui pourraient autrement contourner les contrôles de sécurité traditionnels.
Les artefacts de compilation comme vecteur d’attaque
Cette vulnérabilité met en évidence les risques posés par la désérialisation non sécurisée et la confiance implicite accordée aux composants internes des applications, en particulier au cours des premières étapes de l’exécution, lorsque les contrôles de sécurité sont limités.
Alors que des bibliothèques comme PLY restent intégrées à des flux critiques d’analyse syntaxique et de compilation, les organisations doivent réévaluer la manière dont les chemins de code exécutés au démarrage sont sécurisés et surveillés.
Réduire la dépendance aux artefacts non validés, renforcer les contrôles des systèmes de fichiers et des pipelines et isoler les logiques d’initialisation à haut risque peut contribuer à limiter l’impact d’une exploitation.
La gestion de ces risques s’intègre naturellement dans les frameworks zero-trust qui valident en continu les composants et les contextes d’exécution.