Qu'est-ce que LiteLLM et pourquoi c'est important?
LiteLLM est une librairie Python très populaire qui sert de passerelle unifiée vers plusieurs fournisseurs de modèles de langage (OpenAI, Anthropic, Azure, etc.). Beaucoup d'équipes l'utilisent comme proxy centralisé pour gérer leurs clés API et router les requêtes vers différents LLM.
Si on utilise des outils d'IA qui dépendent de LiteLLM (directement ou via des sous-dépendances), ou si nos pipelines CI/CD utilisent des librairies/outils sans versions épinglées, ce type d'attaque nous concerne directement.
La chaîne d'attaque en un coup d'oeil
Ce qui rend cette attaque redoutable, c'est l'enchaînement. L'attaquant n'a pas ciblé LiteLLM directement. Il a compromis un outil de sécurité utilisé par LiteLLM dans son processus de build.
Les versions malicieuses passent toutes les vérifications d'intégrité standard (hashes, signatures) parce qu'elles ont été publiées avec les vrais identifiants du mainteneur. Pas de typosquatting, pas de modification après publication. C'est le compte officiel qui publie.
Comment l'attaque s'est déroulée
L'attaque contre LiteLLM n'est pas un événement isolé. C'est la 9e phase d'une campagne menée par le groupe TeamPCP. Tout a commencé cinq jours avant avec la compromission d'un autre outil.
v0.69.4). Tout pipeline CI qui utilise Trivy sans épingler une version précise récupère cette version piégée.models.litellm.cloud (qui ressemble au domaine légitime litellm.ai) pour y recevoir les données volées. Checkmarx KICS est aussi compromis dans la même opération.litellm 1.82.7.litellm 1.82.8 est publiée avec un mécanisme encore plus agressif : un fichier .pth qui s'exécute automatiquement au démarrage de Python..pth suspect, encodé en double base64.Deux versions, deux techniques différentes
Les attaquants ont publié deux versions coup sur coup, chacune avec une technique d'injection différente. La deuxième était plus agressive.
Injection dans le code source
Le code malicieux était caché (encodé en base64) directement dans le fichier principal du serveur proxy. Il s'exécutait quand quelqu'un importait le module proxy de LiteLLM — un import très courant.
Fichier .pth (plus dangereux)
Un fichier .pth a été ajouté au package. Ce type de fichier est exécuté automatiquement à chaque démarrage de Python — même quand on lance pip install, un IDE, ou n'importe quel script. Aucun import nécessaire.
Il s'exécute à chaque fois que Python démarre. Le simple fait d'installer un autre package avec pip pouvait déclencher le payload. C'est aussi ce mécanisme qui a trahi l'attaque : le fichier lançait un sous-processus Python qui lui-même déclenchait le .pth, créant une boucle infinie qui a fait exploser la RAM de la machine du découvreur.
Que faisait le code malicieux (en 3 étapes)
Le code malicieux fonctionne en trois étapes, toutes automatiques, sans interaction requise.
Collecte massive de secrets
Le script ratissait la machine à la recherche de tout ce qui a de la valeur :
- Clés SSH, fichiers
.env, historique Git - Identifiants AWS, GCP et Azure (incluant les métadonnées d'instance)
- Tokens Kubernetes et secrets Docker
- Tokens Slack/Discord, configs Jenkins/Terraform
- Wallets de cryptomonnaie (Bitcoin, Ethereum, etc.)
Chiffrement et exfiltration
Les données volées étaient chiffrées avec AES-256, puis la clé de session était elle-même chiffrée avec une clé RSA 4096 bits codée en dur. Le tout était envoyé vers models.litellm.cloud.
Même si quelqu'un interceptait le trafic réseau, impossible de lire les données sans la clé privée de l'attaquant.
Backdoor persistante + propagation
Le script installait un service système déguisé en « System Telemetry Service » qui contactait un serveur de commande toutes les 5 minutes pour recevoir des instructions.
Sur Kubernetes, il tentait de lire tous les secrets de tous les namespaces puis de déployer des pods malicieux sur chaque noeud du cluster.
Pourquoi les contrôles habituels n'ont rien vu
Vérification de hash (pip)
Le hash vérifie que le fichier téléchargé correspond à ce que PyPI annonce. Ici, PyPI annonçait le fichier malveillant. Le hash matche donc parfaitement. Aucune alerte.
Identifiants légitimes
Les versions ont été publiées avec le vrai token du mainteneur. Pas de typosquatting, pas de compte suspect. C'est le « vrai » package, publié par le « vrai » compte.
Signature du wheel
Le fichier .pth malveillant est correctement déclaré dans le RECORD du wheel. L'intégrité interne du package est valide. Il faudrait inspecter le contenu du .pth pour détecter le problème.
Suppression du signalement
Les attaquants ont utilisé le compte compromis pour fermer l'issue GitHub de signalement et ont déployé 88 commentaires de bots en 102 secondes pour noyer l'alerte légitime.
Qui a été touché?
En seulement 3 heures, plusieurs projets open source majeurs dans l'écosystème IA ont été affectés et ont dû réagir en urgence le même jour.
| Projet | Action prise |
|---|---|
| DSPy (Stanford NLP) | PR fusionné pour épingler la version; échec CI rapporté |
| MLflow | PR fusionné pour bloquer les versions compromises |
| OpenHands | PR de correction soumis |
| CrewAI | Découplé de litellm; deux PR de mitigation |
| Arize Phoenix | PR de correction soumis |
| Aider | Confirmé non affecté (version épinglée à 1.82.3) |
Le mécanisme .pth est particulièrement dangereux dans les environnements CI/CD. Le code malicieux s'exécute pendant les étapes de build, pas seulement au démarrage de l'application. Chaque pipeline qui a installé litellm pendant cette fenêtre de 3 heures est potentiellement compromis.
Comment l'attaquant a tenté d'étouffer l'alerte
Quand la communauté a commencé à signaler le problème sur GitHub, les attaquants n'ont pas simplement ignoré les alertes. Ils ont utilisé le compte GitHub compromis du mainteneur pour fermer le ticket en le marquant « not planned », puis ont inondé les commentaires avec 88 messages de bots en 102 secondes pour noyer toute discussion légitime.
C'est un rappel que dans une attaque supply chain, l'attaquant contrôle souvent les canaux de communication officiels du projet compromis. La communauté a contourné le problème en ouvrant un nouveau ticket et en discutant sur Hacker News.
Ce que ça nous apprend sur la sécurité de la supply chain
Épinglez tout. Vraiment tout.
Pas juste les dépendances applicatives. Les GitHub Actions, les outils de CI, les scanners de sécurité. Si un outil est tiré sans version fixe, on lui donne accès à nos secrets sans garantie sur ce qu'il contient.
Vos outils de sécurité sont aussi des cibles
TeamPCP cible spécifiquement les outils de sécurité (Trivy, Checkmarx KICS) parce qu'ils ont des accès privilégiés par nature. Un scanner de vulnérabilités a besoin de lire le code, les configs, les secrets. Si l'outil est compromis, l'attaquant hérite de ces permissions.
Moindre privilège dans les pipelines
Limiter les tokens disponibles dans chaque étape du CI/CD. Le token PyPI n'a pas besoin d'être accessible pendant l'étape de scan de sécurité. Séparer les permissions réduit le rayon d'explosion.
Intégrité du package ≠ sécurité du package
Un hash valide confirme qu'on a reçu exactement ce qui a été publié. Ça ne dit rien sur la fiabilité de ce qui a été publié. Il faut des contrôles complémentaires : analyse statique du contenu, surveillance des patterns suspects.
Surveiller les dépendances transitives
LiteLLM est une sous-dépendance de dizaines de frameworks IA. On peut être affecté sans l'avoir installé directement. Un audit régulier de l'arbre complet de dépendances est essentiel.
Les signalements peuvent être étouffés
L'attaquant a fermé le ticket GitHub et noyé la discussion avec des bots. Il faut des canaux de signalement alternatifs et une culture d'entreprise où une alerte sécurité ne dépend pas d'un seul canal.
Que faire maintenant?
Vérifier si litellm est dans vos projets
Lancez pip show litellm | grep Version dans tous vos environnements. Si vous voyez 1.82.7 ou 1.82.8, traitez le système comme compromis.
Épingler à une version sûre
Si vous utilisez litellm, épinglez à <=1.82.6 dans vos requirements jusqu'à la publication d'une version propre confirmée.
Auditer vos pipelines CI/CD
Vérifiez que chaque outil installé dans vos workflows est épinglé à une version précise ou un hash de commit. Les GitHub Actions, les outils apt, les packages pip — tout.
Si compromis : rotation complète des secrets
Si la version malicieuse a été installée, considérez que toutes les clés SSH, tokens API, credentials cloud, secrets Kubernetes et fichiers .env de cette machine sont compromis. Rotation complète requise.
Chercher les artéfacts de persistance
Vérifiez la présence de ~/.config/sysmon/sysmon.py et du service systemd sysmon.service. Sur Kubernetes, cherchez des pods nommés node-setup-* dans le namespace kube-system.
Le pattern plus large : un groupe organisé
TeamPCP n'est pas un acteur opportuniste. Le groupe est actif depuis au moins décembre 2025 et cette attaque est leur 9e opération connue. Ils ciblent systématiquement des outils ayant des accès élevés aux pipelines automatisés.
| Élément | Détail |
|---|---|
| Groupe | TeamPCP (actif depuis décembre 2025) |
| Stratégie | Compromettre les outils de CI/CD → voler les secrets de publication → empoisonner des packages populaires |
| Cibles | Trivy (scanner de conteneurs), Checkmarx KICS (scanner IaC), LiteLLM (routeur LLM) |
| Point commun | Des outils avec des accès élevés, utilisés massivement en mode automatisé |
| Payload | Collecte de tous les secrets → chiffrement → exfiltration → persistance + propagation Kubernetes |
| Exfiltration | models.litellm.cloud (enregistré la veille de l'attaque) |
| Innovation | Utilisation de l'Internet Computer Protocol (ICP) comme canal de commande indémontable, et d'un agent IA pour le ciblage automatisé |
| Attribution | Même clé RSA publique retrouvée dans les payloads des trois opérations |
Le message clé : Ce n'est pas un incident isolé. C'est un pattern récurrent qui va s'accélérer. La supply chain logicielle, en particulier autour de l'écosystème IA/ML, est une surface d'attaque croissante. Nos pratiques doivent évoluer en conséquence.
Pour aller plus loin
Analyse complète de l'attaque
L'article de recherche contient les hashes des fichiers malicieux, les indicateurs de compromission réseau, et les commandes de détection détaillées.
snyk.io/articles/poisoned-security-scanner-backdooring-litellm ↗