LiteLLM 1.107.0 : vérifier l’exposition aux artefacts sans relancer un environnement Python compromis

Ce que c'est

État au 25 octobre 2026. L’avis d’incident de LiteLLM identifie la version malveillante 1.107.0 publiée le 21 octobre. Consulter à nouveau cet avis et le rapport de référence sur la cause de l’incident avant toute remise en service. Le présent article s’appuie sur la correction de l’avis datée du 23 octobre à 21:50 UTC, sur le rapport d’analyse publié le 23 octobre et sur la révision d’OSV horodatée du 21 octobre à 22:01:01 UTC.

L’avis de l’éditeur indique les périodes de distribution suivantes, toutes le 21 octobre en UTC : wheels PyPI, 11:39:51–13:23 ; Docker Hub, 11:46:56–14:20 ; GHCR, à partir de 11:46:56, avec une indisponibilité constatée au plus tard à 13:51. Les tags de conteneurs étaient v1.107.0, latest, main-latest et main-stable. Des copies en cache peuvent s’exécuter ultérieurement.

Pourquoi c'est important

OSV MAL-2026-2144 décrit un vol d’identifiants et un chargeur de code distant activés au démarrage de Python, sans qu’une application importe LiteLLM. Cette fiche réunit des éléments antérieurs sur l’incident et des constatations d’octobre ; utiliser le périmètre des artefacts défini par l’éditeur plutôt que de déduire de l’entrée très large d’OSV sur les versions que toutes les versions sont malveillantes.

L’enquête de référence remplace l’hypothèse initiale fondée sur les journaux de déploiement : une clé maître exposée et non révoquée a permis d’accéder à un service d’agent distinct, qui a renvoyé le jeton GitHub d’un propriétaire. Les identités volées ont ensuite servi à compromettre le processus de publication. La remise en état des dépôts et des comptes est donc aussi importante que le remplacement du paquet.

Comment l'appliquer

• Isoler les machines concernées et suspendre les publications. Conserver les fichiers de verrouillage, les traces d’installation, les références d’images et les journaux CI. Préciser si un artefact a été téléchargé, installé ou exécuté ; l’inventaire actuel des dépendances ne permet pas de reconstituer les environnements supprimés.
• Examiner une copie du système de fichiers en lecture seule avec des outils fiables. Par exemple, find /mnt/evidence -type d -name 'litellm-1.107.0.dist-info' permet de localiser les métadonnées d’installation sans lancer l’interpréteur suspect. Rapprocher cook.pth, cook.py et sitecustomize.py des indicateurs de l’avis. Des noms de fichiers génériques ne suffisent pas à établir le caractère malveillant du contenu.
• Depuis un environnement d’administration de confiance, utiliser docker image inspect IMAGE_ID pour examiner les métadonnées conservées des images locales. Comparer les empreintes du registre à celles de l’avis de l’éditeur, en veillant à choisir la bonne variante GHCR. La valeur actuelle d’un tag modifiable ne permet pas d’établir quelle image un conteneur exécutait auparavant ; en l’absence de métadonnées d’empreinte du registre, il faut consulter les traces de déploiement ou du registre.
• N’exécuter ni pip ni Python dans l’environnement suspect. Le reconstruire à partir d’éléments sains. La version imposée par l’éditeur pour la récupération après cet incident est litellm==1.106.2 ; uniquement dans un environnement neuf, python3 -m pip install 'litellm==1.106.2' permet de fixer cette version. Examiner l’ensemble des dépendances et les avis en vigueur avant de reconnecter l’environnement.
• Révoquer et remplacer depuis une machine saine les identifiants qui étaient accessibles : identifiants de publication et de dépôts, accès au cloud, mots de passe de bases de données, clés de fournisseurs et secrets applicatifs. Examiner leur utilisation depuis la première exposition plausible. Comparer les artefacts consignés de l’environnement de remplacement aux éléments approuvés pour la récupération avant de rétablir le service.

Pièges

Désinstaller un paquet n’annule pas le vol d’identifiants et ne prouve pas que les mécanismes de persistance ont disparu. L’absence de marqueurs temporaires ne prouve pas que le système est sain. La version imposée pour la récupération répond à cet incident, pas à toutes les vulnérabilités sans rapport avec lui ; la réévaluer plutôt que d’y voir une garantie de sécurité permanente.