La version 1.107.0 de LiteLLM détournée dans une attaque de la chaîne d'approvisionnement volant des identifiants et installant une porte dérobée

Le 21 octobre 2026, LiteLLM — un proxy Python open source très utilisé qui offre aux applications une interface unique, compatible avec OpenAI, vers plus d'une centaine de fournisseurs de grands modèles de langage — a révélé que des attaquants avaient détourné sa chaîne de publication pour diffuser une version malveillante 1.107.0 sur le Python Package Index et sur des registres Docker publics. La version altérée embarquait un voleur d'identifiants et une porte dérobée d'exécution de code à distance au sein du paquet officiel, ce qui en fait la deuxième compromission de la chaîne d'approvisionnement du projet en 2026, après un incident distinct survenu en mars.

Les paquets malveillants sont restés disponibles sur PyPI pendant environ deux heures, de 11h39 à 13h23 UTC, et le projet a indiqué que les sept paquets publiés pour cette version étaient concernés, couvrant des builds macOS, Linux et Windows. Les tags de conteneurs compromis — dont v1.107.0, latest, main-latest et main-stable sur Docker Hub et GitHub Container Registry — ont été actifs à partir de 11h46 jusqu'à leur suppression ou leur redirection vers des artefacts sains avant 14h20 UTC. Le tag source officiel v1.107.0 sur GitHub était sain ; LiteLLM a précisé que les artefacts empoisonnés avaient été compilés depuis un dépôt contrôlé par l'attaquant, de sorte qu'un examen du code source n'aurait rien révélé. Les mainteneurs ont exhorté les utilisateurs à revenir à la version 1.106.2 ou à toute version publiée avant l'incident.

Comment les attaquants sont entrés

Le directeur de la sécurité de LiteLLM, Oliver Jensen, a indiqué que les actions malveillantes avaient été menées via les comptes GitHub de trois ingénieurs, apparemment à l'aide de jetons OAuth de GitHub CLI dérobés. Selon le rapport d'incident du projet, un jeton de propriétaire de l'organisation a servi à désactiver les protections de branche et à forcer la modification du workflow de publication privé, un deuxième identifiant a franchi la porte d'approbation de production, et un troisième a ensuite supprimé des enregistrements de workflow dans une tentative apparente d'effacer les traces. L'entreprise pense que les jetons ont été récupérés dans les journaux d'un déploiement interne qui avait été exposé à l'internet public, tout en précisant qu'elle n'avait pas encore confirmé le vecteur d'attaque initial et qu'elle « ne peut pas encore affirmer qu'aucun autre accès » aux comptes n'avait eu lieu. LiteLLM a révoqué tous les jetons impliqués, coupé les liens de publication de confiance de ses registres et retiré de son organisation GitHub tous les utilisateurs sauf un, non concerné.

La charge malveillante

Des chercheurs de SafeDep, Socket, StepSecurity et Upwind ont analysé la version. La charge de première étape — que StepSecurity a baptisée « privcollect » — était configurée pour s'exécuter au démarrage de l'interpréteur Python via un fichier de chemin cook.pth contenant import cook, ce qui signifie qu'elle s'exécutait même lorsqu'une application n'importait jamais LiteLLM. Elle collectait des jetons cloud, des identifiants de comptes de développeurs, des clés privées, des fichiers d'identifiants d'outils d'IA, des données des navigateurs Chromium et Firefox, des variables d'environnement et des secrets du proxy LiteLLM, puis les regroupait dans une archive compressée et les exfiltrait via HTTP. Une porte dérobée de seconde étape lançait un démon en arrière-plan qui interrogeait une « boîte aux lettres morte » GitHub environ toutes les heures et exécutait le code Python servi par l'attaquant. JFrog a souligné n'avoir trouvé aucune preuve reliant cette campagne à la compromission TeamPCP de mars, les deux incidents devant donc être traités séparément.

LiteLLM a indiqué que les versions privées pour entreprises n'étaient pas concernées et que l'incident était contenu, l'enquête restant en cours. Comme le fichier .pth malveillant se recharge à chaque démarrage de Python, le projet a averti qu'une simple réinstallation n'était pas sûre : les exploitants doivent supprimer les fichiers indicateurs, arrêter le démon, reconstruire de zéro les environnements et les images de conteneurs concernés, et renouveler, depuis une machine saine, tous les identifiants accessibles depuis les hôtes compromis.