LiteLLM 1.107.0 piégé sur PyPI : vol de clés SSH et API

Ce qui s'est passé

Le 21 octobre 2026, à 14h37 UTC, un acteur malveillant a publié la version 1.107.0 de LiteLLM sur le dépôt officiel Python Package Index (PyPI). La bibliothèque, développée par BerriAI, est un proxy unifié permettant aux développeurs d'appeler une centaine de fournisseurs de modèles de langage — OpenAI, Anthropic, Azure OpenAI, Google Vertex, Cohere, Mistral et bien d'autres — via une interface commune. Avec environ 23 millions de téléchargements hebdomadaires, LiteLLM est devenue une infrastructure critique invisible de l'écosystème IA : elle équipe des startups, des équipes DevOps, des plateformes MLOps et des applications d'agents IA dans des milliers d'entreprises à travers le monde.

La compromission a touché les sept wheels (fichiers .whl) publiés pour cette version, couvrant Python 3.8 à 3.12 sur Linux, macOS et Windows. Les images Docker officielles LiteLLM 1.107.0 hébergées sur Docker Hub ont également été contaminées avec le même payload. Selon les analyses publiées par Microsoft Security Blog, Chainguard, StepSecurity et Datadog Security Labs, l'attaquant a probablement obtenu l'accès aux comptes PyPI et Docker Hub de BerriAI via une compromission préalable de secrets de pipeline CI/CD ou de tokens d'authentification.

Le mécanisme d'infection est particulièrement sophistiqué. L'attaquant a inséré un fichier nommé cook.pth dans le répertoire site-packages de l'installation Python. Les fichiers .pth sont lus par l'interpréteur Python à chaque démarrage, avant même l'exécution du script principal ou l'importation de la moindre bibliothèque. Concrètement, toute commande python, pip, pytest ou autre invocation de l'interpréteur déclenchait automatiquement le payload malveillant, y compris dans des environnements où LiteLLM n'était jamais explicitement importé. Cette technique d'injection via .pth contourne la plupart des contrôles d'intégrité statiques et reste peu détectée par les solutions antivirus traditionnelles.

Le credential stealer embarqué ciblait méthodiquement toutes les sources de secrets accessibles sur le système. Il exfiltrait en premier lieu les clés SSH stockées dans ~/.ssh/, y compris les clés privées RSA, Ed25519 et ECDSA. Il collectait ensuite les fichiers de configuration des clouds publics : ~/.aws/credentials et ~/.aws/config pour Amazon Web Services, ~/.config/gcloud/ pour Google Cloud Platform, et les tokens d'authentification Azure CLI. Les variables d'environnement du processus étaient également aspirées intégralement, exposant les secrets injectés par les pipelines CI/CD — tokens GitHub Actions, variables GitLab CI, paramètres CircleCI, secrets Kubernetes montés dans les pods.

Les tokens et clés API des fournisseurs de modèles de langage constituaient une cible de choix. Le malware analysait les fichiers de configuration courants et les variables d'environnement nommées selon les conventions des principaux fournisseurs — OPENAI_API_KEY, ANTHROPIC_API_KEY, COHERE_API_KEY, MISTRAL_API_KEY — ainsi que la base de données SQLite embarquée du proxy LiteLLM, qui stocke les clés des providers configurés. Les mots de passe enregistrés dans les navigateurs Chromium, Firefox et Safari étaient également visés via leurs bases de données locales. L'ensemble des données volées était exfiltré vers un serveur externe contrôlé par l'attaquant via une requête HTTPS chiffrée, rendant l'exfiltration invisible dans les logs réseau courants.

En complément du credential stealer, la version compromise embarquait un loader de second niveau qui se connectait toutes les heures à une URL externe pour télécharger et exécuter du code Python arbitraire. Ce mécanisme de Remote Access Trojan (RAT) permettait à l'attaquant de déployer des charges utiles supplémentaires, d'établir des tunnels de persistance, ou de pivoter vers d'autres systèmes du réseau interne à partir de tout environnement de développement ou serveur de production où LiteLLM était exécuté.

La détection a été rapide mais insuffisante pour empêcher l'exposition. Les premières alertes ont été publiées sur GitHub environ 90 minutes après la mise en ligne de la version malveillante, vers 16h07 UTC. PyPI a retiré la version 1.107.0 à 16h34 UTC, soit environ deux heures après sa publication. BerriAI a supprimé les images Docker contaminées dans la foulée et a publié la version 1.107.1 le 24 octobre, après vérification complète du code et rotation de ses propres secrets de pipeline. La fenêtre d'exposition de deux heures, combinée aux mécanismes automatiques de mise à jour des dépendances et aux caches de registres internes, signifie que de nombreuses organisations ont pu installer la version compromise sans le savoir.

Il est important de noter que cette attaque constitue le second compromis de LiteLLM en sept mois. Un premier incident similaire, bien que de moindre ampleur, avait frappé la bibliothèque en mars 2026, impliquant une dépendance transitoire compromise. BerriAI avait alors renforcé ses procédures de publication, mais cela n'a pas suffi à prévenir cette nouvelle attaque directement ciblée sur les comptes de publication officiels.

Pourquoi c'est important

LiteLLM est devenue, souvent à l'insu des équipes sécurité, une infrastructure critique de l'IA d'entreprise. Des plateformes MLOps, des outils d'orchestration d'agents, des serveurs de proxies unifiés en production s'appuient sur elle. Compromettre LiteLLM, c'est potentiellement ouvrir un accès simultané aux clés API de dizaines de fournisseurs IA, aux pipelines de déploiement, et aux environnements cloud de l'organisation. Le risque n'est pas théorique : un attaquant disposant de clés OpenAI volées peut générer des coûts API massifs, exfiltrer des données envoyées aux modèles, ou réutiliser les clés pour des attaques à grande échelle.

La technique de persistence via fichier .pth illustre l'évolution des attaques supply chain. Contrairement aux méthodes classiques qui modifient le code du package lui-même, l'injection via .pth exploite un mécanisme légitime de l'interpréteur Python. Elle échappe aux vérifications SBOM qui inspectent uniquement les fichiers source, aux contrôles de signature des wheels qui vérifient l'authenticité du publisher mais pas le contenu malveillant, et à la plupart des analyses statiques qui ne simulent pas le démarrage de l'interpréteur. Cette technique est susceptible d'être réutilisée dans de futures attaques supply chain ciblant l'écosystème Python.

Le contexte de cette attaque s'inscrit dans une tendance de fond : les attaques supply chain sur PyPI ont augmenté de manière significative en 2025 et 2026, ciblant de plus en plus l'écosystème IA. Des bibliothèques comme Hugging Face Transformers, LangChain, et diverses dépendances de frameworks d'agents ont été visées par des tentatives d'injection. Les attaquants ont compris que les développeurs IA sont souvent moins vigilants sur la sécurité des dépendances que les équipes DevOps traditionnelles, et que les secrets qu'ils détiennent — clés de modèles commerciaux avec des limites de facturation élevées — ont une valeur marchande immédiate sur les marchés underground.

Pour les équipes de sécurité, cet incident illustre l'urgence d'intégrer les dépendances IA dans les programmes de gestion des risques supply chain. Les contrôles habituels — vérification des hachages, SBOM, audit des nouvelles versions — sont nécessaires mais insuffisants. Il faut aussi surveiller les accès inhabituels aux ressources cloud après mise à jour de dépendances, mettre en place des alertes sur les nouvelles connexions SSH sortantes depuis les environnements de build, et appliquer le principe du moindre privilège aux secrets accessibles dans les pipelines CI/CD. La segmentation des secrets par environnement et par projet limite considérablement le rayon d'explosion d'une telle compromission.

Ce qu'il faut retenir

• Toute installation de LiteLLM 1.107.0 entre le 21 et le 24 octobre 2026 doit être considérée comme compromise : isoler les environnements, reconstruire les images, mettre à jour vers 1.107.1 minimum.
• Rotater immédiatement les clés SSH, tokens API (OpenAI, Anthropic, Azure, GCP, AWS), secrets CI/CD et variables d'environnement présents sur les machines concernées.
• Auditer les logs d'accès SSH, les appels API et les connexions réseau sortantes depuis le 21 octobre pour détecter tout usage malveillant des credentials exfiltrés.