Journal minute par minute de la réponse à l’attaque de la chaîne d’approvisionnement de LiteLLM

(futuresearch.ai)

3 points par GN⁺ 2026-03-28 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Journal de réponse minute par minute documentant la détection et l’analyse en temps réel de l’infection par le paquet malveillant LiteLLM 1.82.8 distribué via PyPI
L’infection s’est produite lors de la mise à jour automatique de Cursor IDE ; l’exécution du fichier litellm_init.pth a entraîné le vol d’identifiants et l’infection du système
Le code malveillant a mené des actions multiples, dont la collecte de clés SSH et d’identifiants cloud, des tentatives de propagation dans Kubernetes et la création d’une fork bomb
L’incident a été signalé immédiatement à l’équipe sécurité de PyPI et aux mainteneurs de LiteLLM, aboutissant à la mise en quarantaine du paquet et à l’enregistrement d’un CVE
Des outils d’analyse de code basés sur l’IA comme Claude Code ont joué un rôle clé dans la détection de l’attaque, mettant en lumière la nécessité de renforcer la sécurité de la chaîne d’approvisionnement de l’écosystème IA

Journal de réponse à l’attaque de la chaîne d’approvisionnement de LiteLLM

La version LiteLLM 1.82.8 a été identifiée comme un paquet malveillant distribué via PyPI, et ce document constitue un journal de réponse minute par minute couvrant le processus allant de la détection de l’infection à sa mise en quarantaine
L’infection s’est produite pendant la mise à jour automatique de Cursor IDE ; parmi les dépendances installées via Claude Code et le gestionnaire de paquets uv, le fichier litellm_init.pth s’est exécuté et a provoqué l’infection du système
L’attaque combinait plusieurs comportements, notamment le vol d’identifiants, l’installation d’une persistance, des tentatives de propagation dans Kubernetes et une fork bomb
L’incident a été immédiatement signalé à l’équipe sécurité de PyPI et aux mainteneurs de LiteLLM, ce qui a conduit à la mise en quarantaine du paquet et à l’attribution d’un CVE
Des outils d’analyse de code basés sur l’IA ont joué un rôle central dans la détection et l’analyse en temps réel des comportements malveillants

Vers 11:13 UTC, plus de 11 000 processus Python ont été créés sur un ordinateur portable macOS, plaçant le système dans un état de blocage
- Des commandes de la forme exec(base64.b64decode('...')) étaient exécutées en boucle, saturant le CPU et la mémoire
- Après un arrêt forcé puis un redémarrage, aucune trace liée à la persistance n’a été обнаружée
Au départ, le phénomène a été interprété comme une boucle non malveillante, potentiellement causée par une boucle interne de Claude Code ou une erreur dans un script uv run
Par la suite, des captures d’écran htop et les journaux ont confirmé l’exécution répétée d’un script Python encodé en base64

Vers 11:40, le fichier litellm_init.pth a été découvert dans des outils Python installés, confirmant un comportement malveillant
- Les fichiers .pth s’exécutent automatiquement au démarrage de Python et s’appliquent donc à tous les processus Python
- Il collectait des clés SSH, identifiants cloud, mots de passe de bases de données, variables d’environnement et historiques de shell
- Les données collectées étaient chiffrées en RSA puis envoyées à https://models.litellm.cloud/
- Il a tenté d’installer une persistance via ~/.config/sysmon/sysmon.py, mais l’opération a été interrompue par le redémarrage forcé
L’infection s’est produite lors de la mise à jour automatique de Cursor IDE (10:58 UTC)
- L’extension futuresearch-mcp-legacy a téléchargé litellm 1.82.8 via uvx
- Cette version n’existait que sur PyPI et ne correspondait à aucun tag de release GitHub
- L’horodatage d’upload sur PyPI indiquait 10:52 UTC, soit juste avant l’infection

Étape 1 (litellm_init.pth) : exécution automatique au démarrage de Python, décodage puis exécution d’une charge utile encodée en base64
Étape 2 : inclusion d’une clé publique RSA pour chiffrer les données volées
Étape 3 (B64_SCRIPT) : collecte et exfiltration effectives des identifiants
Installation de persistance : tentative d’enregistrement de sysmon.py comme service systemd
Code de propagation Kubernetes : tentative de création de pods privilégiés sur chaque nœud à l’aide de l’image alpine:latest
Cause de la fork bomb : l’appel subprocess.Popen([sys.executable, "-c", ...]) réexécutait le fichier .pth dans les processus enfants, provoquant une boucle infinie

Identifiants exposés
- Clés SSH, identifiants GCloud et Kubernetes, clés API dans les fichiers .env, mots de passe Supabase, ClickHouse et Grafana, etc.
- Mesures immédiates recommandées
1. Faire tourner tous les identifiants SSH et cloud
2. Réémettre les secrets présents dans .env et .mcp.json
3. Supprimer le cache ~/.cache/uv
4. Signaler l’incident à l’équipe sécurité de PyPI (security@pypi.org) et aux mainteneurs de LiteLLM
Résultat de la vérification du cluster Kubernetes
- Aucun pod malveillant (node-setup-*, sysmon) n’a été trouvé
- L’exécution ayant eu lieu sur macOS, la propagation interne au cluster a échoué
- Toutefois, en raison de l’exposition possible de ~/.kube/config, une rotation des identifiants reste nécessaire

À 11:58 UTC, le paquet litellm 1.82.8 a été téléchargé depuis PyPI dans un environnement Docker isolé, ce qui a permis de reconfirmer la présence du fichier .pth malveillant
Signalement immédiat à l’équipe sécurité de PyPI et au dépôt BerriAI/litellm
- L’incident a ensuite été enregistré sous PYSEC-2026-2 (CVE)
À 12:01 UTC, publication et diffusion sur le blog FutureSearch d’un billet révélant l’attaque de la chaîne d’approvisionnement
- La PR a été rédigée et fusionnée en 3 minutes
À 12:04 UTC, proposition de diffusion dans les communautés r/Python, r/netsec, r/LocalLLaMA, r/MachineLearning et r/devops
- Objectif : accélérer la réponse des communautés Python et sécurité

L’outil d’analyse de code basé sur l’IA Claude Code a identifié le comportement malveillant en temps réel et a généré une alerte avant l’intervention de chercheurs en sécurité
Cet incident illustre une attaque de la chaîne d’approvisionnement visant directement l’écosystème des développeurs IA, et souligne la nécessité de renforcer la sécurité des comptes PyPI et la vérification des mises à jour automatiques
Il montre aussi que les outils d’IA peuvent aller au-delà de l’assistance au développement pour être utilisés dans la détection et l’automatisation de la réponse aux cybermenaces