🔑 Résumé essentiel
Un token d’API a été dérobé via une vulnérabilité de dépendance de Trivy, puis utilisé pour publier sur PyPI des versions malveillantes des paquets litellm et telnyx. Le code malveillant s’exécutait dès l’installation, collectait des identifiants sensibles et des fichiers, puis les exfiltrait vers un serveur externe.
⚠️ Pourquoi ce malware est particulier
La plupart des paquets malveillants sur PyPI jusqu’ici étaient de nouveaux paquets créés (typosquatting, etc.). Cette attaque est différente. Elle consiste à injecter du code malveillant dans des paquets open source déjà largement utilisés.
Il existe deux vecteurs d’injection :
- attaquer directement des projets open source dont les dépôts, workflows de release ou mécanismes d’authentification sont faibles
- voler des tokens ou clés d’API sur les machines de développeurs qui installent automatiquement la dernière version
Avec les tokens d’API PyPI ou GitHub dérobés, l’attaque peut ensuite compromettre d’autres paquets open source : une attaque en chaîne.
📅 Chronologie de l’incident
LiteLLM
Pendant la période d’exposition de la version malveillante, le paquet a été téléchargé plus de 119 000 fois.
PyPI a reçu 13 signalements via la fonctionnalité de « signalement de malware ».
| Étape | Durée |
|---|---|
| Upload → premier signalement | 1 h 19 |
| Premier signalement → quarantaine | 1 h 12 |
| Temps total d’exposition | 2 h 32 |
LiteLLM est installé environ 15 à 20 millions de fois par semaine, soit environ 1 700 installations par minute. Parmi elles, environ 40 à 50 % n’étaient pas épinglées à une version et récupéraient automatiquement la dernière version.
Telnyx
Le paquet telnyx a été automatiquement mis en quarantaine grâce au pool de trusted reporters de PyPI.
| Étape | Durée |
|---|---|
| Upload → premier signalement | 1 h 45 |
| Premier signalement → quarantaine | 1 h 57 |
| Temps total d’exposition | 3 h 42 |
🛡️ Recommandations de sécurité pour les développeurs
1. Cooldown des dépendances (Dependency Cooldowns)
Cette stratégie consiste à empêcher l’installation des paquets publiés très récemment pendant une certaine période, afin de laisser le temps aux chercheurs en sécurité et aux mainteneurs de PyPI de réagir.
uv — pris en charge actuellement :
# ~/.config/uv/uv.toml ou pyproject.toml
[tool.uv]
exclude-newer = "P3D" # exclure les paquets publiés depuis moins de 3 jours
pip v26.1 — prise en charge prévue en avril :
# ~/.config/pip/pip.conf
[install]
uploaded-prior-to = P3D
⚠️ Le cooldown n’est pas une solution universelle. Si un correctif de sécurité est nécessaire, il faut l’installer immédiatement ; il faut donc l’utiliser en complément d’outils de scan de vulnérabilités comme Dependabot ou Renovate.
2. Verrouillage des dépendances (Lock Files)
pip freeze, qui n’enregistre que les versions, n’est pas un lock file. Pour la sécurité, il faut un vrai lock file incluant des checksums/hashes.
Outils recommandés :
uv lockpip-compile --generate-hashespipenv
🔒 Recommandations de sécurité pour les mainteneurs open source
1. Renforcer la sécurité des workflows de release
- Ne pas utiliser de triggers non sûrs —
pull_request_targetde GitHub Actions est particulièrement risqué - Neutraliser les paramètres et valeurs d’entrée — les transmettre via des variables d’environnement pour éviter les injections de template
- Ne pas utiliser de références mutables — utiliser un commit SHA plutôt qu’un tag Git, et maintenir un lock file pour les dépendances
- Configurer des déploiements nécessitant une revue — combiner Trusted Publishers et GitHub Environments pour exiger une approbation supplémentaire lors des publications
Pour les utilisateurs de GitHub Actions, il est recommandé d’auditer les vulnérabilités des workflows avec l’outil Zizmor.
2. Utiliser Trusted Publishers au lieu de tokens d’API
- Les tokens d’API ont une longue durée de validité, ce qui rend leur vol difficile à détecter immédiatement
- Trusted Publishers utilisent des tokens de courte durée, ce qui réduit le risque car un token volé doit être utilisé tout de suite
- Grâce aux Digital Attestations, les utilisateurs en aval peuvent détecter les publications qui n’ont pas suivi un workflow de release légitime
3. Rendre la 2FA obligatoire partout
Depuis 2024, PyPI impose la 2FA pour publier des paquets. Mais il faut l’activer non seulement sur le compte PyPI, mais aussi sur tous les comptes liés au développement open source, notamment GitHub, GitLab et la messagerie, idéalement avec une clé matérielle.
💰 Pour soutenir cette activité
Les activités de sécurité de PyPI sont rendues possibles grâce au soutien de la Python Software Foundation (PSF). Vous pouvez passer par le programme de sponsoring de la PSF, faire un don direct, ou écrire à sponsors@python.org.
Les postes d’ingénieurs sécurité PyPI de Mike Fiedler et Seth Larson sont soutenus par Alpha-Omega.
Aucun commentaire pour le moment.