Une version piégée de LiteLLM, outil très prisé pour accéder aux IA, volait les accès au cloud

Il a suffi de sept minutes. Le 21 octobre à 11 h 39 UTC (13 h 39 à Paris), sept paquets de LiteLLM 1.107.0 apparaissent sur PyPI, le dépôt public des bibliothèques Python. À 11 h 46, le scanner automatique de la société Socket lève l'alerte. Mais la version piégée est déjà téléchargeable par n'importe quelle chaîne de déploiement.

LiteLLM est une bibliothèque et une passerelle open source : elle permet aux développeurs d'interroger des dizaines de modèles d'IA (OpenAI, Anthropic, Google…) par une interface unique. Selon Socket, elle est téléchargée environ 23 millions de fois par semaine. Dans son rapport d'incident, le projet confirme que son processus de publication a été compromis et que cette version « contenait un logiciel malveillant compilé qui vole des identifiants et charge des outils d'exécution de code à distance ». La version entreprise, distribuée par un registre privé, n'est pas touchée.

Ce que la version piégée allait chercher

Les pirates n'ont pas modifié le code de LiteLLM. Ils ont ajouté trois fichiers au paquet d'installation : cook.pth, cook.py et sitecustomize.py. Ces fichiers s'exécutent à chaque démarrage de Python dans l'environnement touché, même si LiteLLM n'est jamais appelé.

Socket et Endor Labs ont analysé le programme. Il récolte notamment :

• les identifiants AWS, Azure, Google Cloud et Kubernetes ;
• les clés SSH et les fichiers .env ;
• les jetons GitHub, npm et PyPI ;
• les fichiers de connexion d'outils d'IA comme Codex, Claude, Gemini ou Cursor ;
• les données des navigateurs ;
• les clés des fournisseurs d'IA enregistrées dans la base de LiteLLM.

Le butin est chiffré puis envoyé vers un domaine qui imite celui du projet. Un programme de téléchargement reste ensuite actif pour récupérer et lancer du code Python à distance.

Les paquets ont été retirés de PyPI à 13 h 23 UTC. Sur Docker Hub, les images marquées v1.107.0, latest, main-latest et main-stable sont restées piégées jusqu'à 14 h 20 UTC. Point important : une installation réglée sur « latest », qui prend toujours la dernière version, a pu récupérer l'image piégée sans jamais demander la 1.107.0.

Comment les pirates ont-ils pris la main ?

Le rapport d'incident retrace la matinée. À 10 h 08 UTC, une protection de GitHub rejette une modification du processus de publication. Cinq secondes plus tard, l'identifiant d'un développeur aux droits élevés sert à passer outre. Les pirates font ensuite pointer la chaîne de publication vers un dépôt sosie, « Berri-AI/litellm », qui ne se distingue du vrai que par un tiret. Un deuxième identifiant valide la mise en production. Un troisième efface les traces des exécutions. Le lundi 19 octobre, les droits de publication avaient été élargis pour que deux ingénieurs puissent publier des correctifs.

D'où venaient ces identifiants ? LiteLLM avance une hypothèse qu'il ne présente pas comme confirmée. Un compte inconnu a été découvert sur un serveur LiteLLM interne exposé sur Internet, dont les journaux pouvaient enregistrer le contenu des réponses. Or, selon le projet, l'agent de programmation Claude Code, d'Anthropic, peut inclure dans ses réponses le jeton GitHub de l'utilisateur. On ignore encore comment l'attaquant a pénétré ce serveur : l'équipe soupçonne une faille récemment corrigée. Nous n'avons trouvé aucune réaction publique d'Anthropic. Selon BleepingComputer, LiteLLM avait déjà été piégé en mars 2026 par le groupe TeamPCP, via l'outil Trivy utilisé dans sa chaîne de publication.

Que faire si vous utilisez LiteLLM ?

Le réflexe habituel, désinstaller puis réinstaller avec pip, est ici le mauvais : tout lancement de Python, pip compris, relance le code malveillant. Voici ce que recommandent LiteLLM et Socket :

• contrôlez vos fichiers de dépendances, caches, journaux de compilation et conteneurs en cours : toute trace de la 1.107.0 ou d'une image récupérée le 21 octobre entre 11 h 46 et 14 h 20 UTC signale une compromission ;
• sans lancer Python, supprimez depuis le terminal cook.pth, cook.py, sitecustomize.py et les fichiers .pyc correspondants ;
• arrêtez le processus qui détient le fichier /tmp/remote_code_loader.lock ;
• reconstruisez environnements et images de zéro, en fixant la version 1.106.2 ;
• si la machine avait accès à Internet, considérez que les secrets ont été volés : changez les clés des fournisseurs d'IA stockées dans LiteLLM, la clé maîtresse et les clés virtuelles, le mot de passe de la base de données, les rôles cloud et tout secret présent dans l'environnement ;
• sur AWS, cherchez dans le journal CloudTrail des appels GetCallerIdentity au moment de l'installation, et toute utilisation de ces identifiants depuis l'extérieur.

L'affaire rappelle l'outil en ligne de commande d'OVHcloud piégé sur GitHub et les clés d'IA exposées chez OpenCode. LiteLLM promet de nouvelles mises à jour de son enquête. Il annonce aussi la publication, le 27 octobre, d'une autre faille encore sous embargo.