Logiciel malveillant · 23 octobre 2026 · 3 min de lecture

Une version malveillante de LiteLLM a volé des identifiants pendant environ deux heures

La version 1.107.0 sur PyPI et les étiquettes Docker officielles lançaient un voleur à chaque démarrage de Python. Épinglez 1.106.2, et ne nettoyez pas avec pip.

BBrody · Frame

Le contour d’un paquet sur fond noir, trois petits fichiers à l’intérieur, et un trait d’acier qui sort de la boîte.

Le 21 octobre 2026, des attaquants ont publié LiteLLM 1.107.0, une copie empoisonnée d’une bibliothèque très utilisée pour parler aux modèles de langage. LiteLLM dit que les mauvais paquets PyPI ont été en ligne de 11 h 39 à 13 h 23 UTC, et que les étiquettes Docker correspondantes sur Docker Hub sont restées en place jusqu’à 14 h 20 UTC. Si vous n’avez pas installé ni exécuté 1.107.0 dans cette fenêtre, cela n’est pas arrivé sur votre machine.

Ce qui a été publié

La note d’incident de LiteLLM (en anglais) dit que des identifiants GitHub volés ont servi à lancer le processus de publication habituel du projet contre un dépôt contrôlé par l’attaquant. L’étiquette git officielle de 1.107.0 ne contient pas les fichiers malveillants. Les paquets et les images publiés, eux, les contenaient.

Datadog Security Labs dit que le paquet compte environ 23 millions de téléchargements par semaine, et que c’est le deuxième compromis de la chaîne d’approvisionnement de LiteLLM en 2026. Datadog dit ne pas avoir établi de lien entre les deux. Il dit aussi que la version a été construite à partir d’une bifurcation nommée Berri-AI/litellm, à un trait d’union du vrai projet BerriAI/litellm, et que le journal de construction montrait cette bifurcation comme source.

Les paquets installent trois fichiers supplémentaires à la racine de site-packages : cook.pth, cook.py et sitecustomize.py. Python exécute ce genre de fichier au démarrage de l’interpréteur, même si le programme n’importe jamais LiteLLM. Datadog dit que le voleur recueille des identifiants infonuagiques, des secrets Kubernetes et Terraform, des clés SSH, des jetons de registres de paquets, des clés d’API de modèles de langage et des mots de passe enregistrés dans le navigateur, puis les envoie chiffrés vers un domaine qui imite le vrai. Un second fichier vérifie chaque heure s’il y a un téléchargement de suivi. LiteLLM dit que ce pointeur n’a jamais tenu que des valeurs d’essai, donc aucun programme de seconde étape n’a été vu dans la nature.

LiteLLM dit que son registre privé pour les clients entreprise ne faisait pas partie de cette publication. PyPI, Docker Hub et GHCR ont retiré les artefacts malveillants. Les étiquettes à surveiller sont v1.107.0, latest, main-latest et main-stable sur ghcr.io/berriai/litellm et les images liées de base de données et non-root, plus les mêmes étiquettes sur Docker Hub, si elles ont été tirées dans cette fenêtre.

Si vous avez peut-être installé cette version

Ne commencez pas par pip ou python. Les deux relancent les fichiers déposés. Depuis un shell, supprimez cook.pth, cook.py, sitecustomize.py et les fichiers correspondants sous __pycache__, dans chaque site-packages touché. LiteLLM dit aussi d’arrêter le processus en arrière-plan qui tient /tmp/remote_code_loader.lock. Reconstruire l’environnement virtuel ou l’image à partir de zéro est le chemin le plus propre.
Épinglez une version d’avant l’incident. L’instruction actuelle de LiteLLM est litellm==1.106.2, ou toute version explicite publiée avant celle-ci. Une étiquette flottante latest est la façon dont la mauvaise image a été livrée.
Faites tourner les secrets que l’hôte pouvait voir. Si 1.107.0 a tourné sur une machine avec Internet sortant, LiteLLM dit de présumer que le vol a fonctionné. Cela comprend les identifiants de rôle infonuagique, les clés stockées dans une base de données de proxy LiteLLM, le mot de passe de la base de données, et tout ce qui était dans l’environnement d’un processus sur cet hôte. L’absence d’un fichier marqueur ne prouve pas que le vol a échoué. Les conteneurs et le nettoyage des fichiers temporaires l’enlèvent.
Une copie installée avant 11 h 39 UTC, ou seulement à partir du code source à la vraie étiquette git, est hors de cet incident. Les fichiers malveillants étaient dans les artefacts publiés, pas dans cette étiquette.

Sources

LiteLLM, Contained : Oct 21, 2026 LiteLLM release v1.107.0 compromised, 21 octobre 2026
Datadog Security Labs, LiteLLM supply chain compromise : What you need to know, 21 octobre 2026

Les nouveaux articles, par courriel.

Environ une fois par mois. Des notes sur la vie privée en termes simples, rien d’autre. Je ne partage jamais votre adresse.

Ce qui a été publié

Si vous avez peut-être installé cette version

Ne commencez pas par pip ou python. Les deux relancent les fichiers déposés. Depuis un shell, supprimez cook.pth, cook.py, sitecustomize.py et les fichiers correspondants sous __pycache__, dans chaque site-packages touché. LiteLLM dit aussi d’arrêter le processus en arrière-plan qui tient /tmp/remote_code_loader.lock. Reconstruire l’environnement virtuel ou l’image à partir de zéro est le chemin le plus propre.

Épinglez une version d’avant l’incident. L’instruction actuelle de LiteLLM est litellm==1.106.2, ou toute version explicite publiée avant celle-ci. Une étiquette flottante latest est la façon dont la mauvaise image a été livrée.

Faites tourner les secrets que l’hôte pouvait voir. Si 1.107.0 a tourné sur une machine avec Internet sortant, LiteLLM dit de présumer que le vol a fonctionné. Cela comprend les identifiants de rôle infonuagique, les clés stockées dans une base de données de proxy LiteLLM, le mot de passe de la base de données, et tout ce qui était dans l’environnement d’un processus sur cet hôte. L’absence d’un fichier marqueur ne prouve pas que le vol a échoué. Les conteneurs et le nettoyage des fichiers temporaires l’enlèvent.

Une copie installée avant 11 h 39 UTC, ou seulement à partir du code source à la vraie étiquette git, est hors de cet incident. Les fichiers malveillants étaient dans les artefacts publiés, pas dans cette étiquette.