# Attaque de la chaîne d'approvisionnement LiteLLM : Analyse complète de l'injection de code malveillant de 2026 et guide d'intervention d'urgence

En mars 2026, les versions 1.82.7 et 1.82.8 de LiteLLM ont été compromises par du code malveillant via PyPI. Ce guide détaillé explique l'attaque, les données volées et les étapes exactes pour vérifier, nettoyer et renouveler immédiatement les identifiants.

Canonical URL: https://a2a-mcp.org/blog/litellm-supply-chain-attack-2026-fr

Language: fr

Published: 2026-03-25

Updated: 2026-03-25

## 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 :

1. **É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.

2. **É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.

3. **É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**
```bash
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 :
```bash
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.