Attaque de la chaîne d'approvisionnement LiteLLM 2026 : Analyse complète des versions 1.82.7 et 1.82.8 et guide de réparation urgente

Points clés

Versions affectées : LiteLLM 1.82.7 et 1.82.8 sur PyPI ont été injectées avec du code malveillant et ont été retirées. La dernière version sûre est 1.82.6.
Mécanisme d'attaque : La version 1.82.7 dissimulait la charge utile dans proxy_server.py ; la version 1.82.8 utilisait en plus un fichier Python .pth (litellm_init.pth) qui s'exécute automatiquement au démarrage de n'importe quel processus Python, sans nécessiter d'importer LiteLLM.
Données volées : Clés privées SSH, identifiants AWS/GCP/Azure, configurations et Secrets Kubernetes, fichiers .env, portefeuilles de cryptomonnaies, mots de passe de bases de données, identifiants Git, historique du shell, et plus encore.
Attaque en trois étapes : Collecte d'identifiants → Mouvement latéral dans Kubernetes (création de Pods privilégiés) → Persistance via un service systemd déguisé (sysmon.service).
Cause racine : Les attaquants ont compromis l'analyseur de sécurité Trivy plus tôt, ont obtenu les droits de publication PyPI du mainteneur de LiteLLM et ont contourné le CI/CD normal pour téléverser directement les paquets malveillants.
Période d'exposition : Les versions malveillantes n'ont été en ligne que 1 à 2 heures avant qu'un défaut de fork bomb ne fasse planter les machines des développeurs, menant à la découverte.
Étendue de l'impact : LiteLLM compte plus de 95 millions de téléchargements mensuels et est indirectement utilisé par de nombreux systèmes d'agents IA, serveurs MCP et projets d'orchestration de LLM.

Chronologie et détails de l'attaque

Le 24 mars 2026, la bibliothèque populaire LiteLLM — un wrapper d'API unifié pour plus de 100 fournisseurs de LLM — a soudainement vu apparaître des versions anormales sur PyPI. Le groupe de menace TeamPCP (responsable auparavant d'attaques sur Trivy et KICS) a utilisé des identifiants de mainteneur compromis ou des jetons PyPI pour publier deux versions malveillantes.

Version 1.82.7 :

Charge utile malveillante dissimulée dans litellm/proxy/proxy_server.py.
Déclenchée uniquement lors de l'importation du module ou de l'exécution de litellm --proxy.
La charge utile était un script Python encodé deux fois en base64.

Version 1.82.8 (plus destructrice) :

A également déposé un fichier litellm_init.pth.
Le module site de Python exécute automatiquement les fichiers .pth au démarrage de l'interpréteur, permettant un déclenchement sans interaction.
Cela signifiait que même les projets qui n'utilisaient jamais explicitement LiteLLM pouvaient être infectés si le paquet était présent dans leur environnement.

Le malware utilisait un chiffrement hybride (AES-256-CBC + RSA-4096) pour exfiltrer les données vers le faux domaine models.litellm.cloud.

Découverte Technique de la Charge Utile Malveillante

L'analyse révèle que la charge utile a fonctionné en trois étapes distinctes :

Étape de Collecte d'Informations d'Identification :
- Scan récursif des chemins courants : ~/.ssh/, ~/.aws/, ~/.kube/, ~/.azure/, fichiers .env, configurations Kubernetes, identifiants Git, etc.
- Extraction des variables d'environnement, des secrets en mémoire, des points de terminaison de métadonnées cloud (IMDS), et de multiples fichiers de portefeuilles de cryptomonnaie.
Étape de Propagation Latérale (environnements Kubernetes) :
- Utilisation des jetons ServiceAccount pour lire les Secrets à l'échelle du cluster.
- Création de Pods privilégiés alpine:latest dans l'espace de noms kube-system sur chaque nœud, montant le système de fichiers hôte.
Étape de Persistance :
- Déploiement d'une porte dérobée déguisée en "service de télémétrie système" (sysmon.py + service utilisateur systemd).
- Téléchargement périodique de charges utiles supplémentaires depuis des domaines tels que checkmarx.zone.

Déclencheur de la Découverte : Les appels subprocess.Popen du code malveillant ont créé une bombe à fourche exponentielle via le mécanisme .pth, épuisant rapidement la mémoire et faisant planter les machines — une faille qui a involontairement exposé l'attaque.

Pourquoi LiteLLM Était une Cible à Haute Valeur

LiteLLM sert de proxy universel prenant en charge 100+ fournisseurs de LLM et est largement utilisé dans les systèmes d'agents IA en production, les serveurs MCP, et le routage multi-modèle. Les développeurs remplacent souvent les appels sous-jacents par une seule ligne de code, ce qui signifie que les clés API sensibles coexistent fréquemment dans le même environnement.

La chaîne d'attaque de la supply chain était claire : Compromission de Trivy → CI/CD de LiteLLM dépendant de Trivy → Fuite des droits de publication → Téléversement malveillant direct sur PyPI. Cela souligne l'importance cruciale du principe "faire confiance mais vérifier" dans l'écosystème open-source actuel.

Actions Immédiates : Étapes de Détection et de Nettoyage

Étape 1 : Vérifier la Version Installée

pip show litellm
pip list | grep litellm

Si la version 1.82.7 ou 1.82.8 est trouvée, la désinstaller immédiatement :

pip uninstall litellm -y
pip install litellm==1.82.6 --force-reinstall

Étape 2 : Nettoyer le Cache Python et les site-packages

Supprimer les répertoires site-packages/litellm* et tous les fichiers .pth.
Purger le cache pip : pip cache purge

Étape 3 : Remplacer Toutes les Informations d'Identification

Immédiatement remplacer les clés SSH, toutes les clés d'accès cloud (IAM AWS, Comptes de Service GCP, Azure AD), les jetons Kubernetes, les mots de passe de base de données, et les secrets CI/CD.
Examiner les journaux d'audit cloud (CloudTrail, Audit Logs, Activity Log) pour tout accès suspect.

Étape 4 : Vérifications Supplémentaires pour les Environnements Kubernetes -Effectuer un scan de l'espace de noms kube-system pour détecter des Pods suspects.

Rechercher les répertoires ~/.config/sysmon/ et les services systemd malveillants sur les nœuds.
Reconstruire les nœuds affectés (fortement recommandé).

Étape 5 : Scanner les Projets Dépendants

Auditer tous les fichiers requirements.txt, pyproject.toml, et les images Docker ; épingler LiteLLM à ==1.82.6. . Utiliser des outils tels que pip-audit ou safety pour scanner les environnements.

Atténuation avancée et meilleures pratiques

Épingler les versions : Toujours verrouiller LiteLLM à ==1.82.6 (ou une version sûre plus récente) en production avec Poetry, Pipenv ou un outil similaire.
Analyse de la chaîne d'approvisionnement : Intégrer Dependabot, Snyk, JFrog Xray ou Endor Labs pour surveiller les changements de packages PyPI.
Privilège minimum : Éviter de mélanger les identifiants de développement et de production ; utiliser des gestionnaires de secrets dédiés (AWS Secrets Manager, HashiCorp Vault).
Installation en réseau isolé : Pour les environnements à haute sécurité, construire à partir de la source GitHub vérifiée et vérifier les hachages.
Surveillance : Déployer des solutions EDR pour surveiller la création de fichiers .pth, les comportements de fork anormaux et les connexions sortantes vers des domaines suspects.

Cas particuliers :

L'installation indirecte via des scripts CLI (install.sh) expose également les systèmes.
Les images Docker basées sur des images de base compromises doivent être reconstruites.
Les environnements virtuels (venv) sont isolés, mais les installations Python globales affectent toujours les processus système.

Conclusion

L'attaque de la chaîne d'approvisionnement LiteLLM sert de rappel brutal : la commodité des écosystèmes open source s'accompagne de risques de sécurité sérieux. En compromettant d'abord un scanner de sécurité, les attaquants ont obtenu un impact précis en aval.

Agissez maintenant : Vérifiez chaque environnement Python pour les versions de LiteLLM, revenez à la version 1.82.6, et faites tourner immédiatement toutes les identifiants potentiellement exposés. Établissez des processus stricts de revue des dépendances pour prévenir de futurs incidents.

Restez informé via les annonces officielles de LiteLLM sur GitHub et PyPI. En 2026 et au-delà, l'audit régulier des dépendances est une compétence essentielle pour chaque développeur d'IA.

Soyez vigilants et protégez la chaîne d'approvisionnement — commencez dès aujourd'hui par l'épinglage des versions.