LiteLLM compromis : comment sécuriser ses dépendances Python et Docker

Ce qui s'est passé

Le 21 octobre 2026, le processus de publication de LiteLLM a été compromis. Le paquet PyPI litellm==1.107.0 et plusieurs images de conteneur publiées sous des identifiants officiels contenaient du code malveillant destiné à collecter des secrets et à permettre l'exécution de code distant.

Selon le compte rendu de l'éditeur, les roues PyPI ont été exposées de 11 h 39 à 13 h 23 UTC, et des images Docker compromises entre 11 h 46 et 14 h 20 UTC. Les artefacts concernés ont été retirés ou remplacés. La publication malveillante ne signifie pas que toutes les versions de LiteLLM sont compromises.

Quels environnements vérifier ?

• Les environnements Python ayant installé litellm==1.107.0 ou une version non figée durant la fenêtre concernée.
• Les conteneurs ayant exécuté les tags v1.107.0, latest, main-latest ou main-stable pendant la fenêtre signalée.
• Les environnements CI/CD qui ont téléchargé puis exécuté ces artefacts, notamment ceux disposant de secrets d'accès.

Un tag Docker tel que latest peut ensuite pointer vers une image assainie : son état actuel ne prouve pas l'absence d'exposition passée. Il faut examiner les digests utilisés, l'historique de déploiement et les journaux.

Pourquoi le risque est particulier

Microsoft a observé des mécanismes de démarrage automatique de Python via les fichiers .pth et sitecustomize.py. L'import explicite de LiteLLM n'était pas indispensable : démarrer Python dans un environnement compromis pouvait suffire à déclencher le code malveillant.

L'enquête finale de LiteLLM décrit une compromission de jetons GitHub privilégiés et une modification du flux de publication vers un dépôt usurpant le nom du projet. Cette chaîne montre qu'une signature ou une provenance présentée comme officielle ne protège pas si les contrôles de publication sont eux-mêmes détournés.

Comment réagir en cas d'exposition ?

1. Isoler l'environnement suspect et conserver les éléments de preuve. Ne pas commencer par exécuter pip install ni d'autres commandes Python dans l'environnement affecté.
2. Inventorier les versions et les images réellement exécutées. Rechercher les artefacts mentionnés par l'éditeur, notamment litellm-1.107.0.dist-info, cook.pth et sitecustomize.py, sans considérer leur absence comme une preuve de sécurité.
3. Reconstruire les environnements virtuels et les conteneurs depuis des sources vérifiées plutôt que de se limiter à supprimer quelques fichiers. L'éditeur conseillait initialement de figer une version antérieure explicitement vérifiée, par exemple 1.106.2.
4. Révoquer et renouveler les secrets accessibles à l'environnement : clés d'API des fournisseurs IA, jetons GitHub, variables d'environnement, rôles cloud et identifiants de base de données.
5. Enquêter sur l'utilisation des secrets et les connexions inhabituelles, puis surveiller les annonces officielles de remédiation.

Prévenir la prochaine compromission de dépendance

Figer les versions et, quand c'est adapté, les empreintes des artefacts ; éviter les tags flottants en production ; restreindre les permissions CI/CD et la durée de vie des jetons ; séparer les étapes de construction et de publication ; contrôler les digests effectivement déployés ; maintenir un inventaire des composants et des secrets qui leur sont accessibles.

Conseil TechAtelier : une mise à jour n'est pas une garantie de confiance en soi. La traçabilité des artefacts, le principe du moindre privilège et une procédure de rotation des secrets doivent faire partie de l'exploitation quotidienne.

Sources

LiteLLM — avis d'incident du 21 octobre · LiteLLM — chronologie et chaîne d'attaque, 23 octobre · Microsoft Security — analyse des mécanismes Python.