LiteLLM Infecté : Vos Clés API Ont-elles Fuité ? Guide Complet de Vérification

Le 24 mars 2026, la communauté Python a découvert que LiteLLM, l'un des proxy LLM open source les plus utilisés au monde, avait été compromis. Les versions 1.82.7 et 1.82.8 publiées sur PyPI contenaient un malware sophistiqué capable de voler des clés API, des identifiants cloud, des clés SSH, et même des portefeuilles de cryptomonnaies. Le package malveillant est resté en ligne pendant environ trois heures, avec plus de 425 000 téléchargements potentiels.

L'attaque a été découverte par hasard : Callum McMahon, développeur chez FutureSearch, a constaté que sa machine plantait à cause d'un fork bomb provoqué par un bug dans le malware lui-même. En enquêtant sur ce crash, il a identifié le code malveillant et alerté PyPI, qui a immédiatement mis le package en quarantaine.

Pour les entreprises qui utilisent des LLMs via des proxys comme LiteLLM, cet incident est un signal d'alarme majeur. Vos clés API OpenAI, Anthropic, Azure, AWS et Google Cloud ont pu être exfiltrées silencieusement, sans que vous ne receviez la moindre alerte.

Cet incident s'inscrit dans une tendance alarmante. Depuis 2024, les attaques supply chain ciblant l'écosystème Python IA se multiplient à un rythme préoccupant. Des packages malveillants imitant PyTorch, des extensions compromises pour VS Code, des plugins MCP infectés : les attaquants ont compris que les développeurs IA manipulent des secrets à haute valeur (clés API facturées à l'usage, accès cloud, données propriétaires) et que leur culture de sécurité est souvent en retard sur leur vitesse d'adoption des nouveaux outils.

LiteLLM est un proxy open source développé par BerriAI (Y Combinator W23) qui permet d'unifier l'accès à plus de 100 modèles de langage via une seule API compatible OpenAI. Il est utilisé par des milliers d'entreprises et de développeurs pour router leurs appels vers GPT-4, Claude, Gemini, Mistral et d'autres modèles, tout en gérant le load balancing, le caching, les budgets et les logs.

LiteLLM cumule plus de 20 000 étoiles sur GitHub et est intégré comme dépendance transitive dans de nombreux frameworks populaires de l'écosystème IA, notamment DSPy (Stanford), ce qui signifie que des développeurs peuvent avoir installé la version infectée sans même le savoir, simplement en mettant à jour un autre package.

La gravité de l'attaque tient au fait que LiteLLM, par nature, a accès à toutes les clés API des fournisseurs de LLMs configurés. Un malware dans ce package spécifique a donc un accès privilégié aux actifs les plus sensibles de votre infrastructure IA.

L'attaque est de type supply chain : les attaquants n'ont pas compromis le code source de LiteLLM sur GitHub, mais ont réussi à publier des versions modifiées directement sur PyPI, le dépositaire officiel des packages Python.

L'investigation menée par BerriAI avec le cabinet Mandiant a révélé que le vecteur initial était une compromission de Trivy, un outil de scan de vulnérabilités. À travers cette compromission, les attaquants ont obtenu les identifiants nécessaires pour publier sur le compte PyPI de LiteLLM.

Deux versions malveillantes ont été publiées :

• litellm 1.82.7 : première version contenant le payload dans proxy_server.py

• litellm 1.82.8 : seconde version avec un mécanisme additionnel via un fichier .pth (litellm_init.pth)

Le fichier .pth est particulièrement insidieux : il s'exécute automatiquement au démarrage de tout interpréteur Python sur le système, même si LiteLLM n'est jamais importé dans le code. C'est l'un des mécanismes les plus dangereux du système de packages Python.

Le mécanisme du fichier .pth mérite une explication détaillée car il illustre un risque méconnu de l'écosystème Python.

Lorsque Python démarre, il parcourt automatiquement tous les fichiers .pth présents dans les répertoires site-packages. Si un fichier .pth contient une ligne commençant par import, Python l'exécute immédiatement. Le fichier litellm_init.pth exploitait ce mécanisme pour déclencher le malware à chaque lancement de Python, que LiteLLM soit utilisé ou non dans le projet.

# Contenu simplifié du fichier malveillant litellm_init.pth
import litellm_init  # S'exécute automatiquement au démarrage Python

# Le module litellm_init.py contenait le code d'exfiltration
# qui collectait les variables d'environnement et les fichiers sensibles

Cela signifie que si vous avez installé LiteLLM 1.82.8 dans un environnement virtuel, le malware s'exécutait à chaque fois que vous lanciez n'importe quel script Python dans cet environnement, même un simple python --version. Pour les développeurs utilisant des outils comme Cursor avec des plugins MCP qui tiraient LiteLLM comme dépendance transitive, l'infection pouvait se produire de manière totalement invisible.

Le malware ciblait un éventail large de données sensibles, bien au-delà des simples clés API de LLMs :

Les données collectées étaient envoyées vers un serveur contrôlé par les attaquants via HTTPS, rendant l'exfiltration difficile à détecter par les pare-feux classiques. Le groupe derrière l'attaque, identifié sous le nom de TeamPCP, est spécialisé dans les attaques supply chain ciblant l'écosystème Python.

L'éventail des données ciblées révèle un niveau de sophistication élevé de la part des attaquants. En ciblant simultanément les clés API des fournisseurs de LLMs et les identifiants cloud, le malware permettait non seulement de consommer frauduleusement des tokens d'IA (ce qui peut représenter des milliers d'euros de facturation), mais aussi de pivoter vers l'infrastructure cloud de la victime pour des attaques plus profondes.

Les conséquences financières d'une telle compromission peuvent être considérables. Un attaquant disposant de clés API OpenAI ou Anthropic volées peut générer des dizaines de milliers d'euros de consommation en quelques heures en utilisant ces clés pour des tâches gourmandes en tokens. Les fournisseurs de LLMs n'offrent généralement aucune protection contre la consommation frauduleuse une fois que la clé est compromise, et la responsabilité financière incombe au propriétaire du compte.

Pour les entreprises qui utilisent LiteLLM en production derrière un proxy, la compromission est encore plus grave. Le proxy LiteLLM gère typiquement les clés API de tous les modèles utilisés par l'organisation. Une seule instance compromise donne donc accès à l'ensemble des clés de l'entreprise, pas seulement à celles d'un développeur individuel. Dans le cas d'une entreprise utilisant GPT-4, Claude et Gemini via LiteLLM, c'est potentiellement trois fournisseurs différents qui doivent être notifiés et dont les clés doivent être régénérées.

Le vol de l'historique bash et zsh est souvent sous-estimé mais représente un risque considérable. Les développeurs et les administrateurs système exécutent régulièrement des commandes contenant des secrets en clair : des curl avec des tokens d'authentification, des connexions à des bases de données avec des mots de passe, des exports de variables d'environnement. L'historique du terminal est une mine d'or pour un attaquant qui cherche à cartographier l'infrastructure d'une cible.

Voici les étapes de vérification à effectuer immédiatement dans tous vos environnements de développement et de production :

# 1. Vérifier la version installée de LiteLLM
pip show litellm | grep Version

# 2. Chercher le fichier .pth malveillant
find / -name "litellm_init.pth" 2>/dev/null

# 3. Chercher le module malveillant
find / -name "litellm_init.py" 2>/dev/null

# 4. Vérifier les logs d'installation pip
pip install --log /tmp/pip-log.txt litellm 2>/dev/null
grep "1.82.7\|1.82.8" /tmp/pip-log.txt

# 5. Vérifier les connexions réseau suspectes
# (le malware exfiltrait vers un domaine spécifique)
grep -r "litellm" /var/log/syslog 2>/dev/null

Au-delà de ces vérifications manuelles, il est recommandé d'utiliser des outils d'analyse de dépendances automatisés. Des solutions comme pip-audit, Safety ou Snyk peuvent scanner votre environnement entier et détecter les versions connues comme compromises. Pour les environnements de production, intégrer ces scans dans votre pipeline CI/CD garantit qu'aucune dépendance compromise ne sera déployée à l'avenir.

Si vous utilisez Docker, vérifiez également les images construites entre le 24 mars et le moment où PyPI a mis les packages en quarantaine. Une image Docker construite avec un pip install litellm sans version pinnée pendant cette fenêtre pourrait contenir la version compromise, même si votre environnement local est maintenant propre.

Si vous trouvez le fichier litellm_init.pth ou si vous avez installé les versions 1.82.7 ou 1.82.8, considérez votre environnement comme compromis et passez immédiatement au plan de remédiation ci-dessous.

Il est important de comprendre que même si vous avez installé la version compromise pendant seulement quelques minutes avant de la désinstaller, les dégâts ont pu être faits. Le malware s'exécutait immédiatement après l'installation, collectait toutes les données accessibles et les exfiltrait en quelques secondes. La fenêtre d'exposition ne se mesure pas en jours mais en secondes.

Étape 1 : Isoler et nettoyer

• Désinstallez immédiatement LiteLLM : pip uninstall litellm

• Supprimez manuellement litellm_init.pth et litellm_init.py de vos site-packages

• Réinstallez une version propre : pip install litellm==1.82.6 (dernière version saine)

• Vérifiez que le fichier .pth a bien disparu après réinstallation

Étape 2 : Rotation de TOUTES les clés

• Révoquez et régénérez toutes les clés API (OpenAI, Anthropic, Azure, Google, etc.)

• Régénérez vos clés AWS/GCP/Azure

• Remplacez vos clés SSH et tokens Git

• Vérifiez vos portefeuilles crypto si vous en aviez sur la machine

• Changez les tokens Kubernetes et les secrets de vos services

Étape 3 : Audit et monitoring

• Vérifiez les logs de consommation de vos APIs LLM pour détecter un usage anormal

• Auditez vos logs cloud (CloudTrail, GCP Audit Log) pour détecter des accès non autorisés

• Mettez en place des alertes sur les nouvelles connexions et les changements de configuration

La remédiation ne s'arrête pas à la rotation des clés. Il est essentiel de vérifier que les nouvelles clés n'ont pas été compromises à leur tour. Si le malware était encore actif au moment de la rotation (par exemple, si le fichier .pth n'a pas été supprimé avant de générer de nouvelles clés), les nouvelles clés ont pu être exfiltrées immédiatement. C'est pourquoi l'ordre des opérations est critique : d'abord nettoyer l'environnement, ensuite régénérer les secrets.

Pour les équipes qui gèrent des flottes de serveurs ou des clusters Kubernetes, la vérification doit être systématique et automatisée. Un script de scan qui recherche le fichier litellm_init.pth dans tous les conteneurs et environnements virtuels de votre infrastructure peut être exécuté en quelques minutes et vous donnera une vision claire de l'étendue de la compromission. N'oubliez pas de vérifier les images Docker qui pourraient avoir été construites pendant la fenêtre d'exposition.

Cet incident met en lumière plusieurs vulnérabilités systémiques de l'écosystème Python qui sont particulièrement critiques pour les entreprises qui dépendent de l'IA :

Le pinning strict des versions est la mesure la plus simple et la plus efficace. Au lieu d'écrire litellm>=1.80 dans votre requirements.txt, utilisez litellm==1.82.6 avec le hash SHA256 correspondant. Cette pratique, souvent considérée comme contraignante car elle empêche les mises à jour automatiques, est en réalité votre première ligne de défense contre les attaques supply chain. Si LiteLLM 1.82.7 avait été installé automatiquement via un pip install --upgrade, c'est précisément ce que le pinning aurait empêché.

L'isolation des environnements via Docker ou des environnements virtuels dédiés est une autre protection essentielle. Un conteneur Docker qui n'a accès qu'aux secrets dont il a besoin (et pas à vos clés SSH, votre historique bash, ou vos wallets crypto) limite considérablement le rayon de blast d'une compromission. Le principe du moindre privilège, appliqué aux environnements de développement, signifie que votre notebook Jupyter n'a pas besoin d'avoir accès à vos clés AWS de production.

Pour les équipes de prospection B2B qui utilisent des outils d'automatisation connectés à des APIs (comme Emelia), ces recommandations sont particulièrement pertinentes. Vos clés API sont le pont entre votre outil et vos données, et une fuite peut avoir des conséquences financières directes : consommation frauduleuse de tokens, accès non autorisé aux données de prospects, ou pire, compromission de vos comptes cloud.

L'attaque contre LiteLLM n'est pas un cas isolé. L'écosystème Python IA est devenu une cible privilégiée pour les attaquants en raison de la combinaison de plusieurs facteurs : des packages avec un accès privilégié à des secrets sensibles (clés API, tokens cloud), une culture du pip install sans vérification, et des chaînes de dépendances profondes où un seul package compromis peut infecter des dizaines de projets en aval.

En 2025-2026, plusieurs attaques similaires ont ciblé l'écosystème IA : des packages de typosquatting imitant des bibliothèques populaires comme transformers ou langchain, des injections dans des extensions VS Code et des plugins MCP, et des compromissions de comptes de mainteneurs. La sophistication croissante de ces attaques, avec l'utilisation de techniques comme les fichiers .pth et les dépendances transitives, montre que les attaquants comprennent parfaitement l'architecture de l'écosystème Python.

La compromission de Trivy comme vecteur initial est particulièrement inquiétante. Trivy est un outil de scan de sécurité utilisé précisément pour détecter les vulnérabilités dans les dépendances. Le fait que les attaquants aient ciblé un outil de sécurité pour compromettre un outil d'IA crée une chaîne d'attaque particulièrement sophistiquée : l'outil censé vous protéger devient le vecteur de l'attaque elle-même.

Pour les entreprises de prospection B2B comme celles qui utilisent Emelia, ces enjeux de sécurité sont d'autant plus importants que les données manipulées sont sensibles par nature. Les listes de prospects, les séquences d'emails personnalisées, les données de campagne : une compromission des clés API peut donner accès non seulement aux outils d'IA utilisés pour la rédaction, mais potentiellement aux données CRM et aux historiques de communication qui transitent par ces systèmes.

L'incident LiteLLM a été documenté en détail dans le billet officiel de BerriAI et dans l'issue GitHub #24512. Simon Willison a confirmé que PyPI a rapidement mis les packages en quarantaine après signalement.

L'attaque LiteLLM va probablement accélérer plusieurs initiatives en cours dans la communauté Python :

• PyPI explore la signature cryptographique obligatoire des packages (PEP 740)

• Des outils comme Socket Security et Snyk développent des détections spécifiques pour les payloads d'exfiltration

• La communauté pousse pour une authentification multi-facteur obligatoire pour les mainteneurs de packages populaires

• Des propositions émergent pour limiter ou auditer l'exécution automatique des fichiers .pth

Pour les équipes qui dépendent de LLMs dans leur stack, la leçon principale est claire : traitez votre gestionnaire de packages comme un vecteur d'attaque potentiel, pas comme un catalogue de confiance. Pinnez vos versions, vérifiez les hashes, isolez vos environnements, et surtout, faites tourner vos secrets régulièrement. Le coût d'une rotation de clés est négligeable comparé au coût d'une compromission.

La version saine actuelle de LiteLLM est disponible sur le dépôt GitHub officiel. Si vous utilisez LiteLLM, assurez-vous d'être sur la version 1.82.6 ou ultérieure (1.82.9+) et d'avoir effectué toutes les vérifications décrites dans cet article.