LiteLLM 1.107.0 piégée sur PyPI et Docker : quels secrets changer

Une chaîne de publication compromise le 21 octobre

LiteLLM est un SDK Python open source et une passerelle qui permet aux applications d’interroger les modèles de plusieurs fournisseurs d’IA par une API commune. Selon le post-mortem publié par son mainteneur et relayé le 22 octobre 2026 par Bleeping Computer, la chaîne de publication du projet aurait été compromise le 21 octobre. Un attaquant y aurait poussé une version 1.107.0 contenant un logiciel malveillant compilé, à la fois sur PyPI et sur les registres Docker. Cet article repose sur cette source unique, et les éléments qui suivent sont ceux qu’elle rapporte.

Le projet est très répandu : Bleeping Computer cite 92 millions de téléchargements mensuels sur PyPI et 61 800 étoiles sur GitHub. D’après le mainteneur, les clients de la version entreprise privée n’auraient pas été touchés. Plusieurs sociétés de sécurité applicative auraient détecté l’attaque dans les six minutes qui ont suivi la publication.

Les versions et les images concernées

Sur PyPI, les sept wheels de litellm==1.107.0, pour Windows, Linux et macOS, ont été en ligne de 11 h 39 min 51 s à 13 h 23 UTC.

Sur Docker Hub, les étiquettes v1.107.0, latest, main-latest et main-stable pointaient de 11 h 46 min 56 s à 14 h 20 UTC vers l’index d’image compromis sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e.

Sur GHCR, ces mêmes étiquettes pointaient vers des index compromis à partir de 11 h 46 min 56 s, jusqu’à leur retrait effectif à 13 h 51 UTC. Trois images sont concernées : ghcr.io/berriai/litellm (sha256:1bbcb1443bc9…), ghcr.io/berriai/litellm-database (sha256:c00f9d92c427…) et ghcr.io/berriai/litellm-non_root (sha256:7b00e91cd2fe…). La source ne donne ces empreintes que tronquées.

Une image tirée pendant ces créneaux par l’étiquette latest ou main-stable est donc concernée, même si vous n’avez jamais demandé la version 1.107.0. La version de reprise recommandée est la 1.106.2, dernière publication saine avant l’attaque.

Ce que le code malveillant collectait

Selon les chercheurs cités, le code applicatif de LiteLLM n’aurait pas été modifié. Seul le paquet d’installation l’a été, pour déposer trois fichiers dans le répertoire des bibliothèques Python de l’environnement : cook.pth, cook.py et sitecustomize.py. Au démarrage, Python exécute les lignes exécutables des fichiers .pth, puis tente d’importer sitecustomize. D’après Endor Labs, la charge s’exécute ainsi avant l’application à chaque lancement de Python dans l’environnement, y compris quand on lance Python ou pip pour examiner une installation suspecte.

Les données visées :

• identifiants cloud et de déploiement : AWS, Azure, Google Cloud, Kubernetes, Docker, outils de gestion d’infrastructure ;
• fichiers d’authentification des outils de développement IA, ainsi que les identifiants de fournisseurs et les réglages de modèles stockés par LiteLLM ;
• secrets de développeur : Git, GitHub, npm, PyPI, CI/CD, fichiers .env, clés SSH, GPG et TLS ;
• données de navigateur : identifiants enregistrés, cookies, saisie automatique et paiement, historique ;
• variables d’environnement, historiques du shell et des applications, informations système et réseau.

Les données étaient chiffrées en AES-256-CBC, avec une clé elle-même chiffrée en RSA-4096, puis envoyées vers litellm[.]dev/healthcheck, une adresse à rechercher dans vos journaux réseau. Le fichier sitecustomize.py lance en outre un chargeur détaché qui consulte toutes les heures un pointeur hébergé sur GitHub, puis télécharge du code Python depuis un serveur externe pour l’exécuter sur la machine.

Ce qu’il faut faire maintenant

Les paquets malveillants ont été retirés, mais les installations existantes restent infectées. Les recommandations rapportées :

• arrêter les déploiements concernés et les inspecter sans lancer l’interpréteur Python ;
• isoler les machines infectées et les reconstruire à partir de sauvegardes saines : supprimer le seul répertoire du paquet peut laisser en place les fichiers de démarrage ou un chargeur actif ;
• changer immédiatement tous les secrets exposés : clés cloud, accès Kubernetes et Docker, clés des fournisseurs d’IA configurées dans LiteLLM, jetons GitHub, npm, PyPI et CI/CD, contenu des fichiers .env, clés SSH, GPG et TLS, mots de passe enregistrés dans les navigateurs de la machine ;
• réinstaller LiteLLM en 1.106.2.

Le projet avait déjà été compromis en mars : le groupe TeamPCP avait alors publié des versions malveillantes sur PyPI, après avoir compromis le scanner de vulnérabilités Trivy d’Aqua Security utilisé dans la chaîne CI/CD de LiteLLM.

Une passerelle d’IA sert justement à centraliser les clés d’accès aux modèles. Sur une machine touchée, il faut donc partir du principe que l’attaquant connaît tous les secrets qu’elle contenait, et pas seulement ceux de LiteLLM.