EN
en direct

Les CVE de Python triplent en un an et PyPI retire 60 % de malware en plus

Seth Larson, le Security Developer-in-Residence de la Python Software Foundation, chiffre la charge de sécurité de l’écosystème : les CVE de Python et de pip ont triplé en un an et PyPI retire 60 % de malware en plus. Les équipes devops doivent verrouiller leur chaîne de dépendances, car ce volume de signal ne va pas retomber.

Un mur de casiers à colis identiques dans un entrepôt sombre, une porte légèrement entrouverte laissant fuir un filet de lumière ambre.

Novembre 2026. 175 signalements GitHub Security Advisories reçus par la Python Software Foundation depuis janvier, contre 41 sur toute l’année 2025. ×3. C’est le facteur de hausse des CVE de Python et de pip sur un an. 60 %. C’est la progression du volume de malware publié puis retiré de PyPI. Pourquoi c’est important : le socle de presque toute la chaîne d’outillage devops est en train de changer de profil de risque, et la correction ne viendra pas du langage lui-même, mais de la façon dont les équipes consomment leurs dépendances.

Un chiffre que les mainteneurs n’arrivent plus à suivre

Les deux chiffres viennent du même homme : Seth Larson, le Security Developer-in-Residence de la PSF, dont le poste est financé par la fondation Alpha-Omega. Fin octobre 2026, il a publié la courbe des CVE par année : entre 2007 et 2024, le langage restait sous la barre des 20 CVE par an. 2025 a franchi ce seuil, et 2026, extrapolé sur l’année, atteint environ 65.

Ce n’est qu’une face du problème. Le développeur cœur Hugo van Kemenade a documenté le reste dans son billet « Security: line goes up » : les GitHub Security Advisories entrants sont passés de 18 en 2024 à 41 en 2025, puis 175 sur le seul premier semestre 2026. Le flux de courriels de signalement suit la même pente, autour de 50 discussions par mois.

Lire ces courbes comme une simple « hausse des bugs » serait une erreur. Une partie de la hausse reflète du travail mieux fait : la PSF a formalisé une politique de sécurité, défini le PSRT (Python Security Response Team) via la PEP 811, et poussé les chercheurs vers le canal GHSA. Mais même en tenant compte de ce biais de mesure, la pente de 2026 est sans précédent, et elle ne s’explique pas par la seule méthodologie.

PyPI, la cible devenue trop grosse pour être ignorée

Le second chiffre est plus parlant pour un SRE : le malware retiré de PyPI augmente de 60 %. PyPI est le registre par lequel transitent les pip install de millions de machines de CI, de conteneurs et de postes de développement. Un malware qui y passe quelques heures peut contaminer des milliers de builds avant d’être signalé.

Ce n’est pas un phénomène isolé à Python. Daniel Stenberg, le mainteneur de curl, signalait dès juin 2026 que les CVE de son projet avaient elles aussi triplé. Le point commun n’est pas le langage, c’est la position : les bibliothèques de base de l’Internet sont désormais la surface d’attaque la plus rentable par unité d’effort, parce qu’un seul paquet compromis se propage vers tous ses consommateurs en aval.

Le mécanisme d’attaque dominant reste l’usurpation de nom (typosquatting) et la compromission de compte de mainteneur, deux vecteurs qu’un audit de dépendances à la main ne détecte pas. La PSF répond en automatisant : la quarantaine autonome de PyPI, qui retire les paquets suspects sans intervention manuelle, est en cours d’extension précisément pour absorber ce volume.

La réponse est financée, mais elle n’est pas à votre place

Face à cette charge, la PSF a annoncé fin octobre 2026 l’arrivée d’un second Security Developer, Brett Smith, financé par une subvention « ecosystem security » d’Anthropic — la même entreprise qui investit dans la sécurité de l’écosystème Python depuis décembre 2025. Le poste doit absorber la remédiation, l’édition de données CVE en tant qu’autorité de numérotation, et le retrait de malware de PyPI.

C’est une bonne nouvelle, et une nouvelle instructive. Le modèle de financement de la sécurité de l’open source repose désormais sur des subventions d’entreprises d’IA — une dépendance qui mérite d’être notée, mais qui produit pour l’instant des résultats concrets. Ce qu’elle ne produit pas, c’est une réduction du risque pour vos pipelines : personne d’autre que vous ne verrouillera votre fichier de dépendances.

La vérification minimale tient en deux commandes, exécutées en CI plutôt qu’à la main :

bash
pip install pip-audit
pip-audit --requirement requirements.txt

pip-audit croise votre arbre de dépendances avec la base des CVE et des advisories de PyPI. Il ne remplace pas une politique, mais il transforme un signal global en liste actionnable.

Ce que ça change pour une équipe devops

Le glissement de fond tient en une phrase : le coût de la confiance implicite dans les dépendances a augmenté d’un ordre de grandeur en un an. Trois réflexes changent en conséquence :

  • Épingler au hachage, pas à la version. Un ==1.2.3 ne protège pas contre la re-publication d’un paquet sous le même numéro. L’épinglage par empreinte (pip freeze --require-hashes) ferme ce vecteur.
  • Scanner dans la CI, pas après le déploiement. Un pip-audit en fin de pipeline coûte quelques secondes et bloque une contamination avant qu’elle atteigne un registre interne.
  • Générer un SBOM pour chaque artefact. La CRA (Cyber Resilience Act) et les clients commencent à l’exiger ; c’est aussi la seule façon de répondre « qu’est-ce qui tourne dans cette image ? » en cas d’incident.

Le point de bascule est simple : dès qu’une équipe déploie plus d’une application en Python en production, le surcoût d’un épinglage par hachage et d’un scan automatisé est négligeable face au coût d’un malware passé inaperçu dans un paquet de base.

L’IA accélère le problème avant de le résoudre

Il faut nommer l’éléphant : la hausse de 2026 n’est pas indépendante de l’essor des modèles de génération de code. Deux forces se cumulent. La première est offensive : des modèles servent désormais à découvrir des failles à une vitesse qu’un humain ne tient pas — la même dynamique qui a fait tripler les CVE de curl. La seconde est accidentelle : le code généré par IA introduit, en moyenne, plus de bugs par ligne que le code humain, et les revues ne suivent pas le rythme des milliers de lignes soumises chaque jour.

Le paradoxe est que la défense passe par les mêmes entreprises qui accélèrent l’offensive. Anthropic, qui finance le second Security Developer de la PSF, est aussi l’un des principaux producteurs de code généré. Ce n’est pas un scandale, c’est une réalité de financement : la sécurité de l’écosystème open source repose désormais sur les budgets des laboratoires d’IA.

Pour une équipe devops, la conséquence est pratique : le risque ne se mesure plus au seul code que vous écrivez, mais au code que vos outils écrivent pour vous. La revue de dépendances doit traiter le code généré comme du code tiers non audité — parce que c’est exactement ce qu’il est.

La chaîne d’approvisionnement n’est plus une métaphore

Le triplement des CVE ne concerne pas que Python : c’est un mouvement de fond de l’open source. Les registres — PyPI, npm, Maven Central — concentrent des millions de paquets dont une fraction infime est maintenue activement. Quand la charge de sécurité explose, ce sont ces mainteneurs bénévoles qui encaissent, sans budget ni équipe.

C’est pourquoi le sujet n’est plus « faut-il scanner ses dépendances ? » mais « qui finance la défense ? ». La réponse actuelle — des subventions d’Anthropic, d’Alpha-Omega — est fragile par construction : elle dépend de la bonne volonté d’un petit nombre d’acteurs. Une équipe qui veut de la robustesse ne peut pas la déléguer à cette générosité : elle verrouille ses fichiers de dépendances et génère ses SBOM, point final.

Verdict

Si vous exécutez du Python en production, la hausse de 60 % du malware sur PyPI et le triplement des CVE ne sont pas une statistique à commenter : ce sont des raisons de verrouiller votre chaîne aujourd’hui. Épinglez vos dépendances par hachage, faites tourner pip-audit dans la CI et générez un SBOM par artefact — dans cet ordre, et sans attendre la prochaine alerte. La quarantaine autonome de PyPI et les subventions d’Anthropic absorbent le volume côté mainteneurs, mais aucune de ces deux réponses ne couvre vos pipelines : la ligne de défense qui vous appartient encore est votre fichier de dépendances.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Argo CD 3.6 bascule l’observabilité des déploiements GitOps dans le noyau du projet

Sortie le 3 novembre 2026, Argo CD 3.6 apporte des métriques de synchronisation progressive aux ApplicationSets, durcit le TLS de Dex et remplace des scripts Lua maison par des health checks natifs. Pour un opérateur, c’est moins de code de colle à maintenir et une signature SLSA de niveau 3 sur chaque artefact.

GitHub refond son stockage Git pour absorber 5 000 agents sur un seul dépôt

Le 5 novembre 2026, GitHub a détaillé « Project Rubicon », sa nouvelle architecture de stockage Git capable de 7 200 push par seconde sur un dépôt et de 5 000 agents simultanés, en s’appuyant sur un constat simple : seules les mises à jour de références exigent de la coordination. Les objets Git, immuables, partent dans Azure Blob Storage ; l’état mutable, minuscule, va dans un journal répliqué.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer