LiteLLM 1.107.0 compromis sur PyPI : stealer et RAT injectés

Une bibliothèque IA centrale compromise à la source

LiteLLM est l'une des bibliothèques Python les plus adoptées dans l'écosystème des entreprises déployant des agents IA : elle offre une interface unifiée pour appeler plus de 100 LLMs différents — OpenAI, Anthropic Claude, Gemini, Mistral, Llama, Cohere — via une API standardisée. Sa fonction de proxy centralisé, utilisée pour consolider les accès aux API IA d'une organisation, la rend particulièrement critique du point de vue de la sécurité. C'est précisément cette popularité qui en fait une cible de choix pour les attaquants cherchant à compromettre la chaîne d'approvisionnement logicielle des équipes d'ingénierie IA.

Le 21 octobre 2026 à 11h39 UTC, une version malveillante de LiteLLM — la 1.107.0 — a été publiée sur PyPI, le dépôt officiel de packages Python. Les sept fichiers wheel (.whl) distribués pour cette version contenaient deux charges malveillantes distinctes : un infostealer ciblant les identifiants cloud et les clés API, ainsi qu'un loader de code à distance capable d'exécuter du code arbitraire toutes les heures. La version saine 1.107.1 n'a été publiée qu'après que PyPI eut mis 1.107.0 en quarantaine à 13h20 UTC — soit une fenêtre d'exposition de 1h41.

La technique d'infection est particulièrement sophistiquée et difficile à détecter après coup. Le malware exploite le mécanisme Python des fichiers .pth (path configuration files) : un fichier nommé cook.pth est installé dans le répertoire site-packages du système lors de l'installation du package. Ce fichier importe automatiquement cook.py à chaque démarrage de l'interpréteur Python. cook.py décode et exécute alors son code obfusqué, déclenchant la routine de vol d'identifiants. Cette persistance est insidieuse : l'exécution d'une commande Python quelconque — même sans rapport avec LiteLLM, même dans un autre projet — peut déclencher le payload malveillant une fois la bibliothèque installée.

L'infostealer cible un spectre remarquablement large d'informations sensibles. Selon les analyses publiées par StepSecurity, Wiz, OX Security et Endor Labs, il collecte les mots de passe enregistrés dans les navigateurs web (Chrome, Firefox, Edge, Brave), les clés SSH et les clés d'accès cloud (AWS Access Keys, GCP service account credentials, Azure client secrets), les tokens des outils de développement IA (GitHub Copilot, Cursor, Continue, Codeium), et surtout les clés de providers stockées dans la base de données du proxy LiteLLM. Pour une entreprise utilisant LiteLLM comme proxy centralisé, une compromission peut exposer l'intégralité des secrets d'infrastructure IA en une seule exfiltration.

Le loader distant contacte un serveur de commande et contrôle (C2) toutes les heures pour télécharger et exécuter du code arbitraire. Cette persistance horaire permet aux attaquants de mettre à jour la charge utile post-infection, de pivoter vers d'autres systèmes du réseau interne, ou d'installer des outils supplémentaires selon leurs objectifs. Cette architecture modulaire est caractéristique des opérations de compromission à grande échelle où les attaquants veulent maximiser la monétisation de chaque machine infectée.

La détection a été remarquablement rapide. La plateforme de sécurité AISLE a identifié le code malveillant dans les wheels seulement 3 minutes après la publication sur PyPI. StepSecurity a confirmé la compromission peu après, suivies par des analyses détaillées de Wiz, OX Security, Endor Labs et OpenSourceMalware. La fenêtre d'exposition d'1h41 a toutefois suffi pour que des installations automatisées (pipelines CI/CD, environnements avec mises à jour automatiques) récupèrent la version compromise en nombre indéterminé.

Ce n'est pas la première fois que LiteLLM est victime d'une attaque supply chain en 2026. En mars, les versions 1.82.7 et 1.82.8 avaient déjà été compromises sur PyPI avec des charges malveillantes similaires. Cette récidive en moins de huit mois soulève des questions importantes sur la sécurité des credentials PyPI du mainteneur principal et sur les mécanismes de vérification mis en place après le premier incident. La double compromission suggère soit une protection insuffisante du compte de publication, soit un accès persistant non révoqué lors du premier incident.

Les équipes DevSecOps doivent agir immédiatement sur plusieurs fronts. La première priorité est d'identifier les environnements exposés : rechercher litellm==1.107.0 dans tous les fichiers requirements.txt, pyproject.toml, Pipfile.lock et dans les images Docker. La mise à jour vers 1.107.1 ou supérieure est impérative. Les systèmes concernés doivent faire l'objet d'une rotation complète de tous les secrets : clés API OpenAI, Anthropic, Azure AI, AWS, GCP, tokens GitHub, ainsi que les mots de passe des bases de données configurées dans le proxy LiteLLM. La vérification des fichiers .pth dans les répertoires Python est recommandée pour détecter une persistance résiduelle, même après désinstallation.

Un vecteur d'attaque émergent ciblant l'infrastructure IA des entreprises

L'attaque contre LiteLLM illustre un vecteur d'attaque en rapide expansion : la compromission des bibliothèques servant de couche d'abstraction aux API des grands modèles de langage. LiteLLM est utilisé par des centaines de milliers d'équipes de développement, des startups construisant des agents IA jusqu'aux grandes entreprises déployant des proxies LLM centralisés. Une compromission réussie peut donner accès à des clés API représentant des dizaines de milliers d'euros de crédit cloud IA, ou permettre l'exfiltration de données sensibles traitées par les modèles dans des workflows métier critiques.

La technique du .pth file est un vecteur de persistance bien documenté dans la littérature sécurité Python mais rarement mis en avant dans les formations et les outils de détection. Contrairement à un script malveillant qui doit être explicitement exécuté, un .pth malveillant s'active automatiquement à chaque démarrage de l'interpréteur Python, y compris dans les environnements virtuels (venv, conda). Pour les entreprises utilisant Python dans leurs pipelines CI/CD, leurs scripts d'automatisation ou leurs serveurs de production, cette persistance peut survivre à une simple désinstallation du package malveillant si le nettoyage n'est pas exhaustif.

Le double incident de 2026 sur LiteLLM pointe vers un problème systémique dans l'écosystème PyPI. Malgré l'authentification à deux facteurs obligatoire pour les projets critiques, un attaquant disposant d'un accès aux credentials du mainteneur peut publier une version malveillante en quelques secondes. Des solutions comme les attestations Sigstore pour PyPI, les dépôts miroirs privés avec analyse automatique des packages (JFrog Artifactory, Nexus), et les firewalls de dépendances sont désormais indispensables dans toute posture DevSecOps moderne. AISLE a démontré qu'une détection en 3 minutes est possible — l'adoption de tels outils doit s'accélérer.

La réglementation européenne NIS2, en vigueur depuis octobre 2024, impose aux entités essentielles et importantes de maîtriser leurs risques liés à la chaîne d'approvisionnement logicielle. Une compromission via une dépendance PyPI non vérifiée peut constituer un incident de sécurité déclarable, avec des délais de notification stricts envers les autorités compétentes — 72h en France pour certaines catégories d'incidents notifiables à l'ANSSI. Les organisations utilisant LiteLLM dans des contextes critiques doivent documenter cet incident dans leur registre des incidents de sécurité et évaluer si les seuils de notification sont atteints.

Ce qu'il faut retenir

• Toute installation de LiteLLM 1.107.0 est compromise : mettre à jour vers 1.107.1+ immédiatement et effectuer une rotation complète de tous les secrets accessibles sur les machines concernées.
• La persistance via .pth file survit à la désinstallation du package : vérifier et nettoyer manuellement les répertoires site-packages Python.
• Les proxies LiteLLM centralisés exposent l'ensemble des clés API d'une organisation : la compromission d'un seul serveur proxy peut affecter tous les projets utilisant l'infrastructure IA partagée.