Problèmes de sécurité liés à Python : risques courants et mesures d'atténuation

Principaux enseignements

• Les problèmes de sécurité en Python proviennent autant de ce que vous importez que de ce que vous écrivez.
• Le « typosquatting » et la confusion liée aux dépendances sont des méthodes bien connues par lesquelles des paquets malveillants parviennent jusqu'aux utilisateurs de PyPI.
• Lorsqu'une version de Python arrive en fin de vie, les correctifs de sécurité en amont cessent d'être fournis.
• La vérification dans CI, le verrouillage des versions des dépendances et une pratique régulière d'application des correctifs permettent de réduire considérablement les risques quotidiens.

Une application « propre » peut être livrée avec une vulnérabilité connue enfouie au quatrième niveau de dépendances, et vous ne la repéreriez jamais dans votre propre code source. Votre propre code peut poser tout autant de problèmes, qu’il s’agisse d’une désérialisation non sécurisée, de failles d’injection ou d’une mauvaise configuration. Les risques de sécurité liés à Python se situent à trois niveaux à la fois : votre chaîne d’approvisionnement, la version de votre environnement d’exécution et le code que vous avez écrit vous-même.

Cet article passe en revue les vulnérabilités qui apparaissent réellement en production, les CVE qu'il convient de connaître par leur nom, ainsi que les bonnes pratiques permettant de réduire l'exposition à ces risques.

Quels sont les problèmes de sécurité liés à Python ?

Les problèmes de sécurité liés à Python désignent les vulnérabilités ou failles présentes dans les applications Python qu’un attaquant peut exploiter pour accéder à des données, détourner des fonctionnalités ou compromettre l’intégrité du système. Python est déployé pratiquement partout et s’appuie sur un immense écosystème de paquets tiers ; c’est précisément cet écosystème qui offre aux attaquants une surface d’attaque aussi vaste au sein de la chaîne logistique.

La plupart de ces problèmes n’ont rien d’exceptionnel. Ils découlent de mauvaises pratiques de programmation, comme le fait de transmettre les données saisies par l’utilisateur à la fonction eval(), de bibliothèques obsolètes présentant une vulnérabilité CVE publique, ou encore d’une simple erreurs de configuration , comme le fait de laisser le mode débogage activé en environnement de production.

Il existe une quatrième source de problèmes qui prend les équipes au dépourvu : l'utilisation d'une version de Python qui ne bénéficie plus de correctifs. Une fois qu'une version arrive en fin de vie, les correctifs de sécurité en amont cessent d'être diffusés ; par conséquent, toute faille découverte après cette date reste non corrigée, à moins de migrer vers une autre version ou de souscrire à un support étendu auprès d'un autre fournisseur.

En Python, ces états sont appelés respectivement « bugfix » et « security ». Les branches « bugfix » intègrent à la fois les corrections de bogues et les correctifs de sécurité, et bénéficient de nouveaux binaires tous les deux mois environ. Une fois qu’une branche passe en mode « security », seules les corrections de sécurité sont acceptées et plus aucun binaire n’est publié, ce qui peut impliquer de compiler à partir du code source sur certaines plateformes et de constater que certaines bibliothèques tierces cessent progressivement d’être prises en charge. Considérez le début de cette phase comme le moment où vous devez planifier votre mise à niveau, et non comme le moment de vous relâcher.

Problèmes de sécurité courants liés à Python

Les vulnérabilités ci-dessous se retrouvent aussi bien dans les applications web que dans les pipelines de données et les outils internes. Certaines sont des erreurs de codage sur lesquelles vous avez le contrôle. D’autres proviennent de dépendances que vous n’avez jamais choisies, et c’est cette deuxième catégorie qui est la plus difficile à détecter.

Le rapport 2024 de Sonatype sur la chaîne d'approvisionnement a révélé que 80 % des dépendances des applications ne sont pas mises à jour pendant plus d’un an, et que dans 95 % des cas où un composant vulnérable est intégré, une version corrigée existe déjà. Dans de nombreux cas, le problème n’est pas du tout une faille « zero-day ». Il s’agit d’un CVE connu pour lequel une version corrigée est déjà disponible.

Désérialisation non sécurisée

Le chargement de données « pickle » provenant d'une source non fiable revient à ouvrir la porte à l'exécution de code à distance. La fonction `pickle.load()` reconstruira sans problème des objets Python arbitraires, y compris ceux qui exécutent du code dès leur instanciation. Il en va de même pour yaml.load() avec un chargeur non sécurisé. Pour les fichiers YAML non fiables, utilisez plutôt yaml.safe_load(), et évitez complètement d’utiliser pickle avec des données non fiables ou non authentifiées.

Injection via l'exécution dynamique

eval() et exec() transforment les chaînes contrôlées par l'attaquant en code Python exécutable. Le SQL non paramétré relève de la même catégorie de problèmes, mais via un mécanisme différent, où l'entrée remodèle la structure d'une requête plutôt que celle du programme. Formater une requête avec une chaîne f au lieu de lier des paramètres est ici l'erreur classique à éviter. La règle est simple et efficace : n'interpolez jamais d'entrée non fiable dans du code, des commandes shell ou du SQL.

Dépendances vulnérables et malveillantes

Un projet type fait appel à une longue arborescence transitive, et n’importe quel paquet de cette arborescence peut comporter une vulnérabilité CVE connue ou s’avérer être une simple contrefaçon d’un élément légitime. Le « typosquatting » et la « confusion des dépendances » sont désormais des phénomènes bien documentés dans la chaîne d’approvisionnement. L’article de TuxCare consacré à trois paquets PyPI surpris en train d’exécuter des mineurs sous Linux montre à quoi cela ressemble dans la réalité.

Si vous préférez bénéficier d'une protection active plutôt que de recevoir des e-mails d'alerte, SecureChain pour Python remplace le dépôt public PyPI par une alternative vérifiée, recompilée à partir des sources, analysée à la recherche de logiciels malveillants et mise à jour en continu.

Parcours de chemin dans la gestion des archives

L'extraction d'archives comporte un risque de traversée de chemin dès lors que les chemins d'accès aux membres ne sont pas gérés avec précaution, car un nom de membre contenant ../ peut entraîner le placement d'un fichier en dehors du répertoire dans lequel vous aviez l'intention de l'enregistrer. Dans le module `tarfile` de Python, ce problème est répertorié sous la référence CVE-2007-4559, et il est resté dans la bibliothèque standard pendant bien plus d’une décennie avant qu’un mécanisme de filtrage de l’extraction ne soit mis en place.

Exécution de Python en fin de vie

Il ne s'agit pas tant d'un bug de code que d'un problème de calendrier. Un service hérité fonctionnant sous Python 2 bien au-delà de sa fin de vie ne bénéficie d’aucun correctif de sécurité de la part de l’éditeur ; par conséquent, toutes les vulnérabilités CVE concernées restent ouvertes, à moins de migrer ou de bénéficier d’un support étendu. Lorsqu’une réécriture est envisageable, la migration de Python 2 vers Python 3 constitue la véritable solution.

Prise en charge illimitée du cycle de vie de Python par TuxCare constitue une solution provisoire en attendant. Il assure la poursuite de la distribution des correctifs CVE pour Python 2.7 ainsi que pour les versions 3.3 à 3.13 une fois que celles-ci auront atteint leur fin de vie, via le gestionnaire de paquets que vous utilisez déjà.

Python est partout, et c'est là qu'est en partie le risque

C'est précisément en raison de l'ampleur de l'utilisation de Python que sa dette de sécurité ne cesse de s'alourdir. Les systèmes développés avec ce langage ont tendance à comporter beaucoup de code et à supporter une charge importante ; ainsi, même une modification mineure risque de perturber les opérations, ce qui repousse les migrations de version au trimestre suivant. Ces retards expliquent en grande partie pourquoi des environnements d'exécution non pris en charge sont toujours utilisés en production.

Django est utilisé par de nombreux sites à fort trafic, et Django 1.11 a été la dernière version à prendre en charge Python 2, cette prise en charge ayant été entièrement supprimée à partir de la version 2.0. Flask a quant à lui abandonné Python 2 dès la version 2.0. Si un site repose encore sur une version de l’un ou l’autre de ces frameworks datant de l’époque de Python 2, il a besoin d’une procédure de migration prise en charge ou d’une autre source de correctifs de sécurité.

Dans le domaine de l'IA et de l'apprentissage automatique, TensorFlow, pandas et scikit-learn proposent tous des API Python tout en s'appuyant largement, en arrière-plan, sur du code optimisé en C, C++ ou Cython. Une vulnérabilité dans des bibliothèques aussi largement déployées peut affecter un grand nombre d'applications en aval.

Du côté du DevOps, Ansible, Mercurial, Buildbot et SCons sont soit écrits en Python, soit étroitement intégrés à ce langage ; quant au secteur d'entreprise, des plateformes telles que Tryton et Odoo gèrent des déploiements à grande échelle où les temps d'arrêt peuvent rapidement coûter très cher.

Bonnes pratiques pour sécuriser les applications Python

Il n’est pas nécessaire de disposer d’une équipe de sécurité dédiée pour remédier à bon nombre de ces problèmes. Il suffit de mettre en place quelques règles appliquées automatiquement, afin que rien ne dépende de la mémoire d’une personne. L’objectif est la prévention, c’est-à-dire d’éviter que du code défectueux ne soit déployé, ainsi qu’une correction rapide lorsque, malgré tout, une erreur passe entre les mailles du filet.

Fixer et vérifier vos dépendances

Définir les versions des dépendances dans le fichier requirements.txt, ou utilisez le fichier de verrouillage de votre gestionnaire de paquets, afin que la résolution s'effectue de la même manière à chaque fois. Vérifiez ensuite ce fichier à chaque commit.

Des outils tels que pip-audit et Safety CLI vérifient vos dépendances par rapport à des bases de données de vulnérabilités et renvoient un code de sortie différent de zéro lorsqu’ils détectent une correspondance, ce qui permet à une tâche d’intégration continue (CI) d’échouer en cas de détection. Il est bon de savoir que l’ancienne commande « check » de Safety est désormais obsolète et a été remplacée par safety scan.

Conseil de pro : pip-audit renvoie déjà un code de sortie différent de zéro lorsqu'il détecte une vulnérabilité, donc pip-audit -r requirements.txt suffit pour que l'intégration continue (CI) fasse échouer la tâche au lieu de laisser le problème atteindre l'environnement de production. Ajoutez –strict si vous souhaitez également que les échecs lors de la collecte des dépendances entraînent l'échec de l'audit.

Valider et nettoyer toutes les données d'entrée

Considérez par défaut que toute entrée externe n'est pas fiable, qu'il s'agisse de champs de formulaire, de données transmises via une API, de fichiers téléchargés ou du contenu d'archives. Utilisez des requêtes paramétrées pour les bases de données, des listes d'autorisations pour les chemins d'accès aux fichiers et des chargeurs sécurisés pour les données sérialisées, ce qui, dans la pratique, signifie yaml.safe_load() et ne jamais déserialiser de données non fiables ou non authentifiées.

Lancer une analyse statique

L'analyse statique permet de détecter les schémas dangereux avant la mise en production. Bandit est un outil d'analyse statique largement utilisé, spécialement conçu pour Python, qui signale notamment les mots de passe codés en dur, les assertions utilisées pour les contrôles de sécurité et les appels de sous-processus non sécurisés. Utilisez-le en complément de votre linter afin que les contrôles de sécurité s'intègrent naturellement dans le cycle de développement habituel, plutôt que de constituer une tâche distincte.

Veillez à ce que Python et ses bibliothèques soient toujours à jour

Les paquets obsolètes constituent l'une des principales raisons pour lesquelles une vulnérabilité connue reste exploitable. Une routine rigoureuse de correction des vulnérabilités, couvrant l'environnement d'exécution, la bibliothèque standard et vos dépendances, réduit la fenêtre d'opportunité dont profitent les attaquants. Si la distinction entre la correction des vulnérabilités et le suivi des risques vous semble floue, cette analyse comparative entre gestion des correctifs par rapport à la gestion des vulnérabilités mérite d’être lue.

Appliquer le principe du « privilège minimal » lors de l'exécution

Exécutez les services en tant qu'utilisateur non root, définissez des droits d'accès très restrictifs sur les fichiers et le réseau, et ne déployez jamais de systèmes avec le mode débogage activé. Si un attaquant parvient à exécuter du code, c'est le principe du « privilège minimal » qui déterminera si l'incident restera maîtrisable ou s'il vous vaudra une semaine très difficile.

Comment atténuer les risques liés à la sécurité de Python

Les bonnes pratiques vous indiquent ce qu'est un résultat satisfaisant. L'atténuation, c'est l'ordre dans lequel vous traitez les tâches lorsque vous avez un véritable retard à rattraper et que vous manquez de temps. Commencez par les tâches ayant le plus grand impact.

Étape 1 : Dressez l'inventaire de ce que vous exploitez réellement

On ne peut pas sécuriser ce qu’on ne voit pas. Générez une nomenclature logicielle afin de disposer d’une liste complète des dépendances directes et transitives, ainsi que de la version exacte de Python dans chaque environnement.

Étape 2 : Analyse à la recherche de vulnérabilités CVE connues

Importez cet inventaire dans un scanner, qu’il s’agisse de Pip-Audit, de Safety CLI ou d’un outil de plateforme, puis comparez chaque paquet installé et sa version aux avis de vulnérabilité connus. Cela permet de transformer une simple hypothèse (« nous pourrions avoir des problèmes ») en une liste classée par priorité et pouvant faire l’objet de correctifs.

Attention : un inventaire qui ne recense que vos dépendances directes peut passer à côté de vulnérabilités transitives. Vérifiez que votre outil résout ou recense l'arborescence complète des dépendances avant de vous fier aux résultats.

Étape 3 : Hiérarchiser les vulnérabilités en fonction de leur exploitabilité, et pas uniquement de leur gravité

Un score CVSS élevé attribué à du code inaccessible dans votre déploiement ne l'emporte pas automatiquement sur un bug de gravité moyenne exposé via une API accessible au public. Il convient d'interpréter la gravité en tenant compte du contexte, ainsi que de l'accessibilité et des preuves d'une exploitation active. Ce guide d'introduction explique comment fonctionnent les notations CVE et CVSS vous aide à hiérarchiser les priorités plutôt que d'appliquer des correctifs à l'aveuglette.

Étape 4 : Appliquer le correctif, puis vérifier

Appliquez le correctif, puis vérifiez qu'il a bien été pris en compte. Relancez l'analyseur et votre suite de tests. Cette rigueur s'applique à l'ensemble de la pile, depuis une dépendance Python jusqu'aux paquets Linux sous-jacents, car appliquer un correctif sans vérification n'est que de l'optimisme.

Étape 5 : Automatisez le processus pour que le problème ne se reproduise plus

L'application manuelle des correctifs perd de son efficacité dès que les équipes sont débordées. Programmez des analyses régulières, activez les pull requests automatiques pour la mise à jour des dépendances et subordonnez les fusions à la réussite d'un contrôle de sécurité. L'application des correctifs doit s'inscrire dans un processus continu, et non pas se résumer à une opération d'urgence trimestrielle.

Vulnérabilités de sécurité courantes de Python (CVE)

Il s'agit de CVE réels, attribués à la bibliothèque standard ou à des paquets largement utilisés. Deux d'entre eux se trouvent dans setuptools : les outils de compilation constituent un angle mort récurrent que les équipes oublient souvent de scanner. Les scores indiqués ci-dessous correspondent au CVSS v3.1 du NVD ; les évaluations en amont ou celles des éditeurs pour un même CVE peuvent parfois diverger, ne vous inquiétez donc pas si votre scanner affiche un chiffre différent.

Traversée de chemin dans un fichier tar (CVE-2007-4559)

Une faille de traversée de répertoires dans tarfile.extract() et extractall() permet à une archive spécialement conçue d'écrire des fichiers en dehors du répertoire cible à l'aide de .. dans les noms des éléments. Trellix a remis cette question sur le devant de la scène en 2022, estimant à plus de 350 000 le nombre de dépôts open source vulnérables, sur la base d’un taux de 61 % constaté lors d’un échantillonnage manuel de ses résultats d’analyse. Python 3.12 a ajouté des filtres d’extraction via la PEP 706. Dans les versions 3.12 et 3.13, l’ancien comportement reste le comportement par défaut et un avertissement DeprecationWarning est déclenché lorsqu’aucun filtre n’est passé ; le code doit donc passer filter=’data’ ou un autre filtre approprié pour bénéficier d’une gestion plus sûre. Python 3.14 rend data comme valeur par défaut.

Ce paramètre par défaut plus sûr est utile, mais il n’élimine pas pour autant le risque lié à l’extraction des archives. Une série de versions de CPython publiées en juin 2025, comprenant les versions 3.9.23, 3.10.18, 3.11.13, 3.12.11 et 3.13.4, a corrigé plusieurs failles de la données et tar pouvaient être contournés à l’aide de liens symboliques et de liens physiques spécialement conçus, référencés sous les numéros CVE-2024-12718, CVE-2025-4138, CVE-2025-4330, CVE-2025-4435 et CVE-2025-4517. La documentation de tarfile fournie par Python elle-même précise toutefois qu’aucun filtre ne bloque toutes les fonctionnalités dangereuses des archives ; il convient donc de considérer les filtres comme une couche de protection parmi d’autres, de maintenir votre version à jour et de vérifier les fichiers et les chemins d’accès créés lors de l’extraction.

À noter : lorsque la faille a été signalée pour la première fois en 2007, la mesure corrective immédiate a consisté en un avertissement dans la documentation plutôt qu'en une modification du comportement d'extraction. Le paramètre par défaut plus sûr n'est apparu qu'avec Python 3.14, soit environ dix-huit ans après le premier signalement du problème.

Contournement de la liste noire dans urllib.parse (CVE-2023-24329)

Une URL commençant par certains caractères d'espacement peut échapper aux contrôles de la liste noire basés sur urllib.parse, car l'analyseur ne supprime pas ces caractères de début avant la validation. Toute protection contre les attaques SSRF ou tout filtre d'URL s'appuyant sur cette analyse peut ainsi être contourné. Problème corrigé dans Python 3.11.4, avec des portages vers les versions 3.10.12, 3.9.17, 3.8.17 et 3.7.17.

Exécution de code à distance dans setuptools (CVE-2024-6345)

Le package_index de setuptools, jusqu'à la version 69.1.1, génèrent des commandes shell à l'aide de os.system() lors de la récupération d’URL Git et Mercurial ; ainsi, une URL de paquet contrôlée par un attaquant peut se traduire par l’exécution d’une commande. Ce problème a été corrigé dans la version 70.0 de setuptools. La plupart des équipes ne pensent jamais à verrouiller ou à analyser setuptools lui-même, car les outils de compilation sont discrètement classés dans la catégorie « infrastructure » plutôt que dans celle des « dépendances ».

Exécution de code arbitraire dans Pillow (CVE-2023-50447)

Une faille de sécurité dans Pillow jusqu'à la version 10.1.0 permet l'exécution de code arbitraire via le paramètre d'environnement de la fonction PIL.ImageMath.eval(). La vulnérabilité dépend de la transmission de valeurs contrôlées par l'attaquant à ce paramètre, et non pas simplement du traitement d'images fournies par l'utilisateur. Problème corrigé dans Pillow 10.2.0, qui restreint l'accès à l'environnement d'évaluation.

Traversée de chemin dans setuptools (CVE-2025-47273)

La deuxième faille de setuptools est une traversée de chemin dans PackageIndex.download. Le chemin de destination est construit à l'aide de os.path.join(), qui ignore le répertoire temporaire lorsque le nom de fichier manipulé par l’attaquant commence par une barre oblique ou une lettre de lecteur. Les fichiers peuvent ainsi être écrits partout où le processus en cours d’exécution dispose des droits nécessaires, ce qui peut conduire à l’exécution de code selon le contexte. Problème corrigé dans setuptools 78.1.1. Les deux easy_install et package_index sont obsolètes, ce qui limite l’exposition au risque, mais la présence de deux failles dans le même outil de construction en l’espace d’un an nous rappelle qu’il est important d’analyser l’ensemble de votre chaîne d’outils et pas seulement vos dépendances d’exécution.

Assurez la sécurité de vos applications Python avec TuxCare

La difficulté en matière de sécurité sous Python ne réside pas dans la connaissance des correctifs. Elle consiste à maintenir à jour le moteur d'exécution, la bibliothèque standard et vos dépendances sans pour autant imposer une migration immédiate ou une mise à niveau perturbatrice de l'application. Cet écart se creuse dès qu'une version arrive en fin de vie et que les correctifs en amont cessent d'être fournis.

TuxCare apporte une solution à ces deux aspects du problème.

Pour les équipes tiraillées entre « il faut mettre à jour » et « on ne peut pas interrompre la production pour le moment », le support à vie pour Python fournit des correctifs de sécurité continus pour Python 2.7 et les versions 3.3 à 3.13 une fois leur fin de vie atteinte, aussi longtemps que vous en avez besoin. Aucun calendrier de migration imposé : l’application des correctifs CVE se poursuit simplement après la fin du support en amont.

Pour les équipes qui s'inquiètent de ce qui arrive via pip, SecureChain pour Python remplace le dépôt public PyPI par une alternative vérifiée et recompilée à partir des sources. Les paquets sont analysés à la recherche de logiciels malveillants avant d’atteindre votre environnement, et la mise à jour se poursuit bien après que les responsables en amont ont cessé de s’en occuper. Mêmes paquets, même flux de travail, sans avoir à faire confiance aveuglément.

Résumé

Nom de l'article

Problèmes de sécurité liés à Python : risques courants et mesures d'atténuation

Description

Découvrez les problèmes de sécurité les plus courants liés à Python, les risques qu'ils présentent et les bonnes pratiques à adopter pour sécuriser vos applications et systèmes Python.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur