Attaques de la chaîne d'approvisionnement PyPI : Les cas LiteLLM et Telnyx avec des recommandations pratiques
Des attaquants ont compromis les paquets litellm et telnyx en divulguant un jeton API de la dépendance Trivy. Le 19 mars 2026, des versions malveillantes ont été publiées : litellm 1.82.7 et 1.82.8, telnyx 4.87.0 et 4.87.2. Le code s'active lors de l'importation des modules, scanne l'environnement à la recherche de secrets et exfiltre les données vers des serveurs distants.
La charge malveillante dans litellm collecte les clés SSH, les identifiants Git/Docker, les fichiers .env, les jetons K8s, les mots de passe de bases de données, les configurations LDAP, l'historique du shell et les clés cryptographiques. Elle tente d'extraire les jetons cloud des serveurs de métadonnées et d'AWS Secrets Manager. Les données sont envoyées à models.litellm.cloud. Pour la persistance, elle crée un service SystemD nommé "System Telemetry Service" ou un pod K8s qui charge des instructions depuis checkmarx.zone.
Dans telnyx, le code malveillant dans _client.py charge des étapes depuis des fichiers WAV hébergés à l'adresse 8.42.209.203. Sur Windows, il place msbuild.exe dans le dossier Démarrage pour un lancement automatique ; sur d'autres OS, il utilise un script Python. La version 4.87.1 contenait une faute de frappe qui bloquait l'exécution. La communication est liée à TeamPCP via une clé de chiffrement.
Les développeurs ont réagi en faisant tourner les jetons, en supprimant les versions et en mettant en œuvre des éditeurs de confiance sur PyPI.
Caractéristiques des attaques sur les paquets OSS populaires
Contrairement aux attaques PyPI typiques (comme le typosquatting ou les nouveaux paquets), ici du code malveillant a été injecté dans des projets existants à fort trafic. La chaîne : compromission des dépôts → vol des jetons PyPI/GitHub → publication de logiciels malveillants → collecte d'identifiants depuis les machines de développement → compromissions répétées.
LiteLLM a été téléchargé plus de 119 000 fois pendant l'attaque. ~40-50 % des installations étaient sans spécification de version (dernière), ~1700 installations/minute. Temps de réponse de PyPI :
- LiteLLM : de la publication à la quarantaine — 2 heures 32 minutes (13 signalements utilisateurs).
- Telnyx : 3 heures 42 minutes (quarantaine automatique par des utilisateurs de confiance).
Mesures de PyPI contre les logiciels malveillants
Environ 700-800 nouveaux projets sont ajoutés quotidiennement. PyPI s'appuie sur la communauté pour le scan et le signalement via "Signaler comme malveillant". Cette fonctionnalité, introduite en 2024, accélère la mise en quarantaine. Les éditeurs de confiance permettent des réponses automatisées.
Recommandations : Période de refroidissement des dépendances
Retarder l'installation des nouvelles versions donne du temps pour la détection des logiciels malveillants. Format : RFC 3339 (P3D = 3 jours).
- uv : globalement dans ~/.config/uv/uv.toml ou pyproject.toml :
[tool.uv]
exclude-newer = "P3D"
- pip v26.1+ : dans pip.conf :
[install]
uploaded-prior-to = P3D
- pip 26.0 (date absolue) :
python -m pip install --uploaded-prior-to=$(date -d '-3days' -Idate) package
Contournement pour les correctifs de sécurité : --uploaded-prior-to=P0D ou Dependabot/Renovate (qui ignorent les délais).
Verrouillage des dépendances pour la reproductibilité
Les fichiers de verrouillage avec hachages empêchent la substitution de code lors de la réinstallation.
| Outil | Commande | Format |
|------------|---------|--------|
| uv | uv lock | uv.lock |
| pip-tools | pip-compile --generate-hashes | requirements.txt |
| pipenv | pipenv lock | Pipfile.lock |
pip freeze est insuffisant — il manque les hachages. pip lock (pylock.toml) est attendu.
Protection des projets OSS
- Mettez en œuvre des éditeurs de confiance sur PyPI.
- Utilisez 2FA + clés matérielles pour PyPI/GitHub.
- Restreignez les permissions des jetons (scopes).
- Surveillez les publications via des webhooks.
- Scannez les dépôts avec Trivy/Grype.
Pour les machines de développement :
- Isolez les environnements compromis.
- Faites tourner toutes les informations d'identification.
- Vérifiez la persistance (SystemD, pods K8s, Démarrage).
- Analysez le trafic/les journaux.
Points clés à retenir
- Les attaques exploitent de vrais paquets OSS ; vérifiez les nouvelles versions.
- Une période de refroidissement P3D + fichiers de verrouillage = protection de base.
- Plus de 119 000 installations de LiteLLM avant la quarantaine ; la dernière version est risquée.
- L'exfiltration inclut les métadonnées cloud et Secrets Manager.
- Les éditeurs de confiance et la communauté accélèrent la réponse de PyPI.
— Editorial Team
Aucun commentaire pour le moment.