Le pipeline de releases de LiteLLM détourné encore une fois : un infostealer livré via la v1.107.0 sur PyPI et Docker Hub
Dans la matinée du 21 octobre 2026, une version malveillante de LiteLLM est arrivée sur PyPI et dans les images Docker officielles du projet. La v1.107.0 embarquait un voleur d'identifiants et un chargeur de code distant à la place du code écrit par ses mainteneurs. Selon la mise à jour de sécurité de LiteLLM elle-même, c'est le pipeline de release qui a été compromis, grâce à des identifiants GitHub fuités appartenant aux comptes de développeurs du projet. Les wheels malveillants sont restés moins de deux heures sur PyPI, et les tags Docker contaminés ont survécu tout l'après-midi. Dans un écosystème de builds automatisés et de dépendances épinglées, c'était largement assez pour avoir des conséquences.
Un tag propre, un build empoisonné
La divulgation se lit comme une checklist de la fragilité de la confiance dans les paquets. LiteLLM indique que l'attaquant a obtenu des jetons OAuth de GitHub CLI depuis trois comptes de développeurs, apparemment capturés dans les journaux d'un déploiement interne de LiteLLM exposé sur Internet ; l'un des comptes appartenait au propriétaire d'une organisation GitHub. Avec ces identifiants, la protection de branche a été contournée, une modification du workflow forcée, et le pipeline pointé vers un dépôt sosie : Berri-AI/litellm, à un tiret du véritable BerriAI/litellm. Le tag git officiel de la v1.107.0 est resté propre ; les artefacts malveillants ont été compilés depuis le dépôt imposteur.« Cette version contenait un malware compilé qui vole des identifiants et charge des outils d'exécution de code à distance. » — mise à jour de sécurité de LiteLLM, 21 octobre 2026La détection, au moins, a été rapide. Comme le rapporte BleepingComputer, des sociétés de sécurité dont Socket et Endor Labs ont signalé la version en environ six minutes, et PyPI avait retiré les wheels à 13h23 UTC, Docker Hub étant nettoyé dans l'après-midi. LiteLLM indique que les clients de son registre entreprise privé n'ont pas été touchés. Six minutes comptent toujours quand le paquet enregistre environ 92 millions de téléchargements par mois et que des sociétés comme NVIDIA, Netflix et Okta figurent parmi ses utilisateurs, selon BleepingComputer.
Ce que le voleur d'identifiants recherche
La mécanique de la charge explique la fermeté des recommandations. Les wheels ont déposé trois fichiers — cook.pth, cook.py et sitecustomize.py — dans le répertoire site-packages de Python. Python exécute ces types de fichiers à chaque démarrage de l'interpréteur, donc tout processus Python de la machine a exécuté le malware, même sans jamais importer LiteLLM. L'analyse technique de Datadog Security Labs ajoute que désinstaller le paquet litellm ne supprime pas les fichiers ; il faut les effacer à la main. L'analyse d'incident de Kodem documente ce que le voleur était conçu pour collecter :- Identifiants cloud et d'infrastructure : clés AWS, Azure et GCP, y compris jetons de métadonnées d'instance, plus secrets Kubernetes, Docker et Terraform
- Matériel spécifique à l'IA : clés d'API de fournisseurs de LLM, identifiants stockés dans la base du proxy LiteLLM et fichiers de session d'outils de code assisté par IA
- Jetons de développeurs et de registries : identifiants Git, jetons GitHub, npm et PyPI, clés SSH, GPG et TLS
- Secrets locaux : fichiers .env, variables d'environnement, historiques shell et bases de données
- Données de navigateur : mots de passe enregistrés, cookies et entrées de remplissage automatique
Deuxième incident de pipeline de l'année
C'est la deuxième version compromise de LiteLLM en 2026. En mars, un acteur suivi sous le nom de TeamPCP a placé une porte dérobée dans les versions 1.82.7 et 1.82.8 après avoir compromis un scanner Trivy dans le pipeline CI/CD du projet et volé un jeton PyPI. Datadog ne relie les deux campagnes que par leur cible : aucun lien entre les acteurs n'est établi. Le schéma est ce qui incommode — une passerelle au centre de milliers de stacks d'IA, qui conserve des clés de fournisseurs et des identifiants cloud, a vu son canal de distribution corrompu deux fois en huit mois.La première heure, selon le runbook
Kodem a accompagné ses indicateurs d'un runbook de réponse pour la première heure, et l'avis de LiteLLM est tout aussi ferme. Le socle commun :- Bloquer litellm 1.107.0 au proxy de paquets, cesser de déployer les tags flottants comme latest et épingler la dernière version propre, 1.106.2, par hash — les images par digest
- Ne pas exécuter python ni pip sur les hôtes touchés avant nettoyage, car chaque démarrage de l'interpréteur réexécute la charge
- Isoler hôtes et conteneurs, puis supprimer manuellement cook.pth, cook.py, sitecustomize.py et leurs fichiers .pyc compilés
- Rotater depuis une machine saine : rôles cloud, clés de fournisseurs stockées dans la base du proxy, clés master et virtuelles LiteLLM, mot de passe de la base, jetons des registries et de GitHub
- Examiner les journaux d'audit cloud à la recherche d'appels GetCallerIdentity et d'usages d'identifiants depuis une infrastructure inattendue depuis 11h39 UTC le 21 octobre