Le 21 octobre 2026, l’équipe de publication de Python a sorti en urgence trois versions de sécurité : Python 3.15.1, 3.14.9 et 3.13.17. Elles embarquent un pip à jour qui ne fait plus confiance aux certificats compromis de l’autorité indienne eMudhra. Si vous développez ou déployez du Python, la mise à jour de pip dans vos environnements virtuels s’impose.
- Versions concernées : 3.15.1, 3.14.9 et 3.13.17, publiées le 21 octobre.
- Changement clé : pip 26.2.2, avec le magasin de certificats certifi 2026.10.19.
- Cause : la compromission de huit certificats intermédiaires d’eMudhra (marque emSign).
- Action : mettre à jour pip et uv dans chaque environnement virtuel existant.
Plan de l'article
Pourquoi Python publie trois versions d’un coup #
Le billet officiel de Python Insider, signé notamment par Hugo van Kemenade, Thomas Wouters, Ned Deily et Steve Dower, présente ces trois sorties comme des publications de sécurité accélérées. Elles ne visent pas à apporter de nouvelles fonctionnalités, mais à corriger un problème de confiance dans la chaîne des certificats.
À lire Next.js : deux failles critiques corrigées, passer en 16.4.1 ou 15.5.28
Le cœur du correctif tient en une ligne : les trois versions passent à pip 26.2.2, qui embarque certifi 2026.10.19. Certifi est le paquet qui fournit la liste des autorités de certification racines auxquelles pip se fie quand il télécharge des paquets en HTTPS. Le billet relie explicitement cette mise à jour à l’incident eMudhra / emSign.
Que s’est-il passé chez eMudhra ? #
D’après The Register, Mozilla a reçu le 17 octobre un signalement indiquant que les clés privées de huit certificats intermédiaires d’eMudhra, une autorité de certification indienne, étaient compromises. Le problème n’était pas un vol, mais des clés bien trop faibles : l’une d’elles correspondait tout simplement au nombre 4, a relevé le chercheur Scott Helme.
Une clé P-384 devrait être un nombre aléatoire de 384 bits, impossible à deviner. Ici, n’importe qui pouvait retrouver les clés et, en théorie, signer des certificats acceptés comme légitimes. Mozilla, Chrome et Apple ont modifié leurs navigateurs pour ne plus faire confiance à ces certificats, et eMudhra les a révoqués.
Le hic, c’est que les navigateurs ne sont pas les seuls à vérifier des certificats. Les outils en ligne de commande, les gestionnaires de paquets et les langages embarquent souvent leur propre liste d’autorités. The Register note que plusieurs projets open source ont publié des mises à jour similaires. Python fait partie du lot, avec pip.
Ce qui change pour la branche 3.13 #
La branche 3.13 vient d’entrer en mode « sécurité uniquement ». Normalement, à ce stade, l’équipe Python ne met plus à jour pip ni les installateurs, pour limiter les risques de casse sur des projets anciens.
Le billet reconnaît que cette mise à jour de pip sort de l’usage habituel. L’équipe a pourtant jugé plus prudent de publier de nouveaux installateurs pour 3.13.17, compte tenu de l’enjeu. Si vous maintenez des applications encore sur Python 3.13, c’est le signal qu’il ne faut pas attendre.
Comment mettre à jour ses environnements #
Installer la nouvelle version de Python ne suffit pas. Chaque environnement virtuel garde sa propre copie de pip, figée au moment de sa création. Le billet officiel recommande donc de mettre à jour pip et uv dans tous les environnements virtuels existants.
Dans un venv activé, la commande classique reste python -m pip install --upgrade pip. Le billet propose aussi une variante plus stricte, qui installe directement la roue de pip 26.2.2 depuis son URL, en vérifiant son empreinte SHA-256. C’est la méthode à privilégier si vous avez un doute sur la confiance de l’environnement.
Pour les installations macOS « framework », le billet fournit des commandes dédiées pour mettre à jour pip et certifi, y compris pour la variante free-threaded de Python. Pensez enfin aux images Docker, aux pipelines CI et aux serveurs de déploiement : ce sont eux qui tournent souvent sur un pip ancien sans que personne ne s’en rende compte.
Une correction bonus pour macOS 27 #
Les nouveaux installateurs macOS des trois versions sont compilés avec une version préliminaire de Tk. Elle corrige un blocage possible sous macOS 27.0 dans les applications qui utilisent tkinter, à commencer par IDLE. Le problème est suivi dans le ticket CPython n° 158053.
Ce que les équipes de développement doivent retenir #
Cet incident rappelle une règle souvent oubliée : la sécurité d’une application dépend aussi de ses outils de construction. Un pip qui fait confiance à une autorité compromise peut, dans le pire des cas, accepter un faux serveur de paquets lors d’une attaque de type homme du milieu.
Pour une équipe, la bonne pratique consiste à inventorier les versions de Python et de pip réellement utilisées, en local, en intégration continue et en production. Reconstruire les images de base avec les nouvelles versions, plutôt que de patcher à la main, évite d’oublier un environnement. C’est aussi un bon moment pour vérifier que vos dépendances sont épinglées avec leurs empreintes.
À lire Camel Caps : Guide Notation Programmation 2026
Questions fréquentes #
Faut-il passer à Python 3.15.1 si j’utilise Python 3.14 ?
Non. Chaque branche a sa version corrigée : 3.14.9 pour la 3.14, 3.13.17 pour la 3.13. L’essentiel est de mettre à jour pip dans vos environnements.
Mettre à jour Python met-il à jour pip dans mes venv ?
Non. Chaque environnement virtuel garde sa propre copie de pip. Il faut la mettre à jour dans chacun d’eux, ainsi que uv si vous l’utilisez.
Pourquoi les certificats eMudhra posent-ils problème ?
Huit certificats intermédiaires utilisaient des clés privées trop faibles, faciles à retrouver. Ils ont été révoqués et retirés des listes de confiance.
