LiteLLM 1.107.0 piégée : un voleur de secrets publié sur PyPI et Docker

Mardi 21 octobre 2026, la version 1.107.0 de LiteLLM, la bibliothèque Python qui sert de passerelle unique vers les API d'IA (OpenAI, Anthropic, Google…), a été publiée par des pirates sur PyPI et sur Docker avec un voleur de secrets intégré. Elle n'est restée en ligne que deux à trois heures, mais si tu as installé LiteLLM sans fixer de version ce jour-là, considère ta machine comme compromise.

Es-tu concerné ?

Oui, si l'un de ces cas te correspond (heures UTC, le 21 octobre) :

Toutes les versions antérieures sont saines. Les clients de la version entreprise privée ne sont pas touchés. Le code source de la version 1.107.0 sur GitHub est propre : les paquets piégés ont été construits depuis un dépôt pirate.

Pour vérifier : pip show litellm, ou cherche sur le disque litellm-1.107.0.dist-info, cook.pth et sitecustomize.py. En trouver un confirme l'exposition ; ne rien trouver ne prouve pas que tu es sain, car un conteneur ou un nettoyage de /tmp efface les traces.

Ce que fait le logiciel malveillant

Les pirates n'ont pas touché au code de LiteLLM. Ils ont ajouté trois fichiers (cook.pth, cook.py, sitecustomize.py) dans le dossier des bibliothèques Python. Python les exécute à chaque démarrage, avant même ton application, y compris quand tu lances pip pour enquêter.

Selon les analyses citées par BleepingComputer, il aspire :

• les identifiants cloud et de déploiement (AWS, Azure, Google Cloud, Kubernetes, Docker) ;
• les clés d'API d'IA stockées par LiteLLM et les fichiers de connexion des outils de développement IA ;
• les secrets de développeur : Git, GitHub, npm, PyPI, CI/CD, fichiers .env, clés SSH, GPG et TLS ;
• les données des navigateurs (mots de passe, cookies, cartes, historique) ;
• les variables d'environnement et l'historique du terminal.

Les données sont chiffrées puis envoyées à un faux domaine litellm[.]dev. Un chargeur reste ensuite actif et télécharge du code à exécuter toutes les heures.

Ce que tu dois faire

LiteLLM donne ces consignes, dans cet ordre :

1. Ne lance pas pip install en premier : tout démarrage de Python relance le malware.
2. Depuis le shell, supprime cook.pth, cook.py, sitecustomize.py et les cook*.pyc / sitecustomize*.pyc de chaque site-packages touché.
3. Tue le processus Python détaché (il garde le verrou /tmp/remote_code_loader.lock).
4. Réinstalle en fixant litellm==1.106.2. Mieux : reconstruis les images et environnements virtuels de zéro.
5. Si la machine avait accès à internet, considère que les secrets sont partis et change tout ce qu'elle pouvait atteindre : rôle IAM, clés des fournisseurs stockées dans le proxy LiteLLM, clé maîtresse et clés virtuelles, mot de passe de DATABASE_URL, toute variable d'environnement.
6. Sur AWS, cherche dans CloudTrail des appels GetCallerIdentity autour de l'installation, puis l'usage des identifiants depuis l'extérieur.

Comment les pirates sont entrés

Après un premier piratage en mars, LiteLLM avait durci sa chaîne de publication : dépôt privé, publication via les Trusted Publishers de GitHub, étiquettes Docker immuables, images signées, compte de publication lié à un ordinateur gardé au bureau. Selon le post-mortem :

• lundi, l'équipe avait élargi temporairement les droits de publication à deux ingénieurs pour des correctifs quotidiens ;
• les pirates détenaient trois jetons GitHub CLI de développeurs, dont celui d'un des deux propriétaires de l'organisation. Ils s'en sont servis pour désactiver la protection de branche et forcer leur modification ;
• ils ont lancé la publication depuis un dépôt sosie, Berri-AI/litellm au lieu de BerriAI/litellm, qui a signé et publié les paquets piégés.

D'où venaient ces jetons ? LiteLLM affirme avoir observé que Claude Code peut, dans certains cas, recopier le jeton OAuth de GitHub CLI dans le corps d'une réponse, et que ces réponses étaient enregistrées dans les journaux de son déploiement interne de LiteLLM. Ce déploiement était exposé sur internet, avec un compte utilisateur inconnu au nom anodin. LiteLLM soupçonne une faille récemment corrigée, sans l'avoir encore confirmé. Anthropic n'a pas commenté ce point dans les sources que nous avons lues.

LiteLLM signale aussi qu'il diffuse aux clients entreprise un correctif sous embargo pour une autre faille, dont la publication est prévue le 27 octobre. Mets à jour dès sa sortie.

La leçon pour tes projets

Fixe tes versions (litellm==1.106.2, pas litellm tout court ni l'étiquette latest), et évite que tes journaux d'API gardent le corps complet des réponses d'agents : ils peuvent contenir des jetons. Cette semaine a déjà vu Railway demander de changer toutes les clés et la console OpenCode piratée : les secrets des développeurs IA sont devenus une cible prioritaire.