Le 21 octobre, des versions piégées de LiteLLM, la bibliothèque et le proxy très utilisés pour appeler des modèles d’IA via une API unique, ont été publiées sur PyPI, Docker Hub et le registre de conteneurs de GitHub. Le code de l’application n’a pas été modifié : ce sont les paquets d’installation qui embarquaient un voleur d’identifiants.
Ce qui a été piégé
| Où | Quoi | En ligne (UTC) |
|---|---|---|
| PyPI | litellm==1.107.0 (7 wheels) | 11 h 39 – 13 h 23 |
| Docker Hub | v1.107.0, latest, main-latest, main-stable | 11 h 46 – 14 h 20 |
| GHCR | mêmes tags sur litellm, litellm-database, litellm-non_root | 11 h 46 – 13 h 51 |
Le tag v1.107.0 du dépôt source officiel est sain, et les clients entreprise qui passent par le registre privé ne sont pas touchés. Le vrai risque, ce sont les tags flottants : un docker pull litellm:latest ou un pip install -U litellm lancé dans ce créneau, par un humain ou par une CI, a récupéré la version piégée.
Comment le malware fonctionne
Le paquet ajoutait trois fichiers dans site-packages : cook.pth, cook.py et sitecustomize.py. Python exécute automatiquement les fichiers .pth et le module sitecustomize à chaque démarrage de l’interpréteur. Le malware se lance donc à chaque appel de python, et aussi de pip, même si votre code n’importe jamais LiteLLM.
Il collecte à peu près tout ce qui a de la valeur sur une machine de dev ou un serveur :
- identifiants AWS, Azure, GCP, Kubernetes et Docker ;
- jetons Git, GitHub, npm, PyPI et CI/CD, fichiers
.env, clés SSH, GPG et TLS ; - clés des fournisseurs d’IA configurées dans LiteLLM ;
- mots de passe, cookies et historique des navigateurs ;
- variables d’environnement et historiques du shell.
Les données sont chiffrées puis envoyées vers litellm[.]dev, un domaine qui imite le vrai projet. sitecustomize.py lance aussi un processus détaché qui vérifie toutes les heures s’il y a du nouveau code à télécharger. Supprimer le paquet ne suffit donc pas.
Si vous pensez être touché, ne lancez ni pip ni python dans l’environnement concerné avant de l’avoir inspecté : chaque lancement relance le malware.
Vérifier une machine ou une image
Ces commandes n’exécutent pas Python : elles se contentent de chercher des fichiers.
# Fichiers déposés par le malware, dans tous les environnements Python
find / ( -name 'cook.pth' -o -name 'cook.py' -o -name 'litellm-1.107.0.dist-info' ) 2>/dev/null
# Processus de téléchargement encore actif ?
ls -l /tmp/remote_code_loader.lock 2>/dev/null && pgrep -af python
# Images Docker locales avec le digest piégé
docker images --digests | grep 1bbcb1443bc9Ne pas trouver ces fichiers ne prouve pas que la machine est saine, prévient l’équipe de LiteLLM. Le plus sûr reste de vérifier dans vos journaux de CI et dans vos lockfiles si la version 1.107.0 a été installée.
Si vous êtes touché
- Arrêtez les déploiements concernés et isolez les machines.
- Tuez le processus détaché, supprimez les fichiers ci-dessus et leurs
__pycache__, ou mieux : reconstruisez l’image ou l’environnement virtuel de zéro. - Épinglez une version saine :
litellm==1.106.2. - Si la machine avait accès à Internet, considérez que tout a fuité, et changez tous les secrets présents : rôle IAM de l’instance, clés de fournisseurs d’IA, clé maître et clés virtuelles LiteLLM, mot de passe de la base, jetons CI.
- Dans CloudTrail, cherchez des appels
GetCallerIdentityvers l’heure d’installation, et toute utilisation des identifiants de l’instance depuis l’extérieur de votre infrastructure.
Comment le pipeline a été détourné
D’après le post-mortem de LiteLLM, l’attaquant a obtenu des jetons OAuth de la CLI GitHub. Ils se seraient retrouvés dans des journaux, intégrés aux réponses d’un assistant de code. Il s’en est servi pour contourner la protection des branches et lancer le workflow de publication, en le faisant pointer vers un dépôt imitant le vrai (Berri-AI/litellm au lieu de BerriAI/litellm). L’équipe précise que certaines de ses premières conclusions se sont révélées inexactes ; la cause exacte reste donc à confirmer dans le rapport définitif.
La leçon pour vos propres projets : épinglez vos dépendances et vos images par version, et idéalement par empreinte (pip install --require-hashes, image@sha256:…), plutôt que de suivre latest. Avec un délai de quelques jours avant d’adopter une nouvelle version, la plupart de ces attaques sont détectées et retirées avant de vous atteindre.
C’est la deuxième fois cette année : en mars 2026, des versions malveillantes de LiteLLM avaient déjà été publiées après la compromission de Trivy, un outil de sécurité utilisé dans sa CI.