Logo_que_le_centre_72
Retour à la liste des articles

PyPI bloque les anciennes versions pour éviter des injections malveillantes via des tokens volés

Table des matières

Illustration éditoriale de première partie et image mise en avant pour l'article « PyPI bloque les anciennes versions pour éviter des injections malveillantes via des tokens volés ».

Imaginez un scénario digne d’un thriller technologique : des pirates infiltrent en silence vos vieux logiciels préférés sur PyPI, la plateforme officielle où les développeurs partagent leurs bibliothèques Python, et y injectent discrètement des malwares dans des fichiers jamais mis à jour depuis des années. Sans laisser de trace ni alerter personne. Jusqu’à récemment, cette faille était une réalité technique.

Heureusement, PyPI vient d’agir en fermant cette brèche : depuis peu, toute modification de fichiers dans les releases (versions publiées) âgées de plus de 14 jours est bloquée. Une mesure visant à empêcher des attaques silencieuses où un token volé aurait pu corrompre des millions de téléchargements. Pourtant, cette faille n’a jamais été exploitée jusqu’ici – pas par manque d’opportunité, mais probablement parce que les pirates ignoraient même son existence.

Décryptage : pourquoi cette réforme s’impose-t-elle, comment elle fonctionne, et quels impacts elle a sur vos téléchargements futurs ou actuels. Car même si PyPI réduit désormais les risques, la vigilance reste de mise dans un écosystème où les menaces évoluent sans cesse.

Comment PyPI protège-t-il désormais les anciennes versions de ses paquets Python contre des injections malveillantes via des tokens d’accès volés ?

Pourquoi PyPI était une cible idéale pour les hackers

PyPI, l’équivalent d’un Amazon du code Python, concentre des milliers de paquets partagés par des millions de développeurs. Pourtant, jusqu’à présent, ces releases (versions publiées) n’étaient pas figées : même une version sortie en 2019 pouvait encore recevoir des ajouts – comme un nouveau fichier « wheel » (format optimisé pour l’installation).

Le problème ? Un token d’accès volé suffisait à modifier ces fichiers à distance, sans laisser de trace. Résultat : un attaquant pouvait injecter un binaire malveillant dans une release ancienne, utilisée par des milliers – voire millions – d’utilisateurs, sans que personne ne s’en aperçoive. Pas d’avertissement, pas de mise à jour forcée, juste une propagation silencieuse du malware, comme une épidémie numérique.

Pourquoi cette faille n’a-t-elle jamais été exploitée ? Selon Seth Larson, développeur sécurité chez la Python Software Foundation : *« Si ça n’a pas encore été abusé, c’est parce que les acteurs malveillants n’avaient pas réalisé que c’était possible. »* Une porte ouverte en espérant qu’aucun voleur ne fouillerait votre placard… jusqu’à ce que quelqu’un le fasse.

Illustration éditoriale de deuxième partie pour l'article « PyPI bloque les anciennes versions pour éviter des injections malveillantes via des tokens volés ».

14 jours pour verrouiller les releases : une solution imparfaite mais nécessaire

Face à ce risque, PyPI a pris des mesures concrètes. Depuis peu, tout fichier ajouté à une release de plus de 14 jours est bloqué. Ce délai a été choisi après analyse : sur les 15 000 paquets les plus populaires, seulement 56 avaient publié des wheels pour Python 3.14 après cette période.

Pourquoi ce choix ?
Certains projets nécessitent du temps pour ajouter le support d’une nouvelle version de Python, comme les wheels compatibles avec Python 3.14 (sorti en octobre 2023). Mais cette exception confirme la règle : dans la majorité des cas, une release n’a pas besoin d’évoluer après sa sortie. Laisser cette porte ouverte équivalait à laisser traîner les clés de son garage « au cas où » – utile pour un jardinier, mais catastrophique en cas de cambriolage.

Cette mesure n’est cependant pas parfaite. Par exemple :
– Pas de vérification automatique : il n’existe pas encore d’API pour confirmer qu’une release est « fermée ». Un projet pourrait toujours modifier ses fichiers via des moyens détournés.
– Solution temporaire : le vrai cadre sécurisé viendra avec l’API Upload 2.0 et les Staged Previews, prévus par la PEP 694. En attendant, cette mesure est un premier pas.

Pourtant, elle apporte déjà des bénéfices concrets :

  1. Moins de travail pour les admins PyPI : en cas de paquet compromis, il suffit désormais de verrouiller la release concernée sans trier manuellement les fichiers vérolés.
  2. Aucune release « à moitié corrompue » : avant, une release pouvait être partiellement infectée (certains fichiers modifiés, d’autres non). Maintenant, elle devient un bloc figé, comme une image numérique scellée.

GitHub avait déjà adopté des releases immuables, où même le mainteneur ne peut plus modifier les versions publiées. PyPI suit, mais en version « soft » pour l’instant.

Que faire si vous utilisez encore des vieux paquets ?

Si vos dépendances Python datent de plusieurs années, voici ce qu’il faut savoir – et comment réagir sans panique.

1. Vos téléchargements actuels restent probablement sûrs
PyPI n’a pas « nettoyé » les releases existantes : elle a juste empêché de nouvelles injections. Si vous avez installé un paquet avant cette réforme, votre installation actuelle est valide. En revanche, méfiez-vous des outils comme pip install --upgrade, qui pourraient forcer le téléchargement d’un fichier modifié après la date limite.

2. Les développeurs doivent « bumper » leurs releases
Pour ajouter des fichiers (comme les wheels pour Python 3.14), les mainteneurs doivent créer une nouvelle release avec un numéro de version incrémenté (ex : passer de v1.0 à v2.0). C’est comme ouvrir une nouvelle boîte pour y glisser le support d’un ancien téléviseur plutôt que de modifier l’ancienne.

3. À long terme : confiance, mais vérifiez
Cette mesure réduit les risques, mais ne supprime pas tous les dangers. Voici comment rester prudent :

« Une porte de moins pour les attaquants en chaîne logistique. Sympa non ? »

— Adapté des propos de Simon Willison

  • Privilégiez les paquets maintenus activement : un projet mis à jour régulièrement a moins de risques d’être compromis.
  • Utilisez des outils comme pip audit ou safety check pour scanner vos dépendances.
  • Méfiez-vous des upgrades automatiques : vérifiez toujours que la mise à jour correspond à un besoin réel, et non à une injection malveillante.
  • Surveillez les alertes de sécurité publiées par PyPI Security Advisories ou CISA.

Pour conclure sur : " PyPI bloque les anciennes versions pour éviter des injections malveillantes via des tokens volés "

Cette réforme de PyPI illustre une vérité simple : même les infrastructures aussi massives que celle-ci ont leurs failles – et elles peuvent être comblées, parfois avec du retard. En verrouillant les releases après 14 jours, PyPI réduit drastiquement les risques d’injections malveillantes via des tokens volés.

Pour autant, la sécurité logicielle ne repose pas uniquement sur ces mesures techniques. Elle exige aussi une vigilance constante de votre part : ne vous fiez pas aveuglément aux mises à jour automatiques, isolez vos projets avec des environnements virtuels, et renseignez-vous sur les mainteneurs de vos paquets. Car au final, une release figée est utile, mais un développeur informé l’est davantage.

 

Source : https://blog.pypi.org/posts/2026-07-22-releases-now-reject-new-files-after-14-days/

En savoir plus : contactez-nous
Illustration éditoriale de troisième partie pour l'article « PyPI bloque les anciennes versions pour éviter des injections malveillantes via des tokens volés ».

Articles Liés

Les actualités : cliquez-ici
Logo_sans_cadre_72
  • INTERNET CREATIVE CENTER DEPUIS 1999