La Faille LiteLLM Résume le Cauchemar DevOps des Agents IA en Production

L'attaque supply chain LiteLLM pose une question structurelle aux agences tech

Le 24 mars 2026, le package Python LiteLLM a été compromis sur PyPI. Deux versions vérolées, 1.82.7 et 1.82.8, ont été distribuées pendant environ trois heures avant la mise en quarantaine. Pour une agence digitale qui déploie des agents IA pour ses clients, cet incident dépasse le simple fait divers sécurité. Il expose un problème structurel que la plupart des équipes techniques refusent d'affronter : la chaîne de dépendances des pipelines IA est devenue un vecteur d'attaque majeur, et presque personne n'est prêt.

LiteLLM, pour ceux qui ne le connaissent pas, est une passerelle unifiée vers plus de 100 fournisseurs de modèles de langage. OpenAI, Anthropic, Azure, Bedrock, Vertex AI : tout passe par LiteLLM via une interface compatible OpenAI. Le projet, issu de Y Combinator (batch W23), cumule 3,4 millions de téléchargements quotidiens sur PyPI. Quand vous compromettez LiteLLM, vous ne volez pas un mot de passe. Vous récupérez potentiellement toutes les clés API de tous les fournisseurs LLM d'une organisation en une seule opération.

Chez Bridgers, nous voyons cet incident comme un cas d'école qui mérite une analyse approfondie, non pas uniquement technique, mais sous l'angle DevOps et gouvernance que toute agence sérieuse doit maîtriser.

Anatomie d'une attaque en cascade : de Trivy à PyPI

Ce qui rend cette attaque remarquable du point de vue DevOps, c'est la sophistication de la chaîne de compromission. Les attaquants n'ont pas ciblé le code source de LiteLLM directement. Ils ont d'abord compromis Trivy, un scanner de sécurité open source largement utilisé dans les pipelines CI/CD. En exploitant une GitHub Action Trivy non épinglée dans le pipeline de LiteLLM, ils ont exfiltré le token PYPI_PUBLISH, ce qui leur a permis de publier directement sur PyPI sans passer par les workflows officiels de build.

C'est le scénario cauchemardesque pour tout responsable DevOps : l'outil qui est censé protéger votre pipeline devient le vecteur de l'attaque. Et c'est exactement le type de risque que la plupart des audits de sécurité classiques ne couvrent pas. Quand vous faites auditer votre code applicatif, personne ne vérifie si vos GitHub Actions sont épinglées à un SHA précis plutôt qu'à un tag mutable.

Les chercheurs de Trend Micro ont identifié cette campagne comme faisant partie d'un effort plus large mené par le groupe TeamPCP. Ce n'est donc pas un incident isolé. C'est un pattern d'attaque reproductible qui cible systématiquement les projets open source à forte adoption dans l'écosystème IA.

Le fichier .pth : pourquoi cette technique doit alarmer les DevOps

La version 1.82.7 contenait un payload classique dans un fichier Python du proxy server, qui ne s'activait qu'à l'import du module proxy. La version 1.82.8 a franchi un palier bien plus préoccupant avec l'introduction d'un fichier litellm_init.pth dans le répertoire site-packages.

Les fichiers .pth sont un mécanisme méconnu de Python. Traités par le module site au démarrage de l'interpréteur, toute ligne commençant par import y est exécutée automatiquement. Concrètement, le code malveillant se déclenchait à chaque lancement de Python, que vous importiez LiteLLM ou non. Ouvrir un notebook Jupyter, lancer pip, démarrer un serveur de language dans votre IDE : tout suffisait.

Pour une agence qui gère plusieurs environnements clients, les implications sont considérables. Un développeur qui installe une mise à jour sur sa machine locale compromet potentiellement son poste de travail entier. Et si ce poste a accès aux environnements de staging ou de production de plusieurs clients via SSH, kubectl ou des profils cloud, l'impact se multiplie exponentiellement.

Le malware ne se contentait pas de voler les variables d'environnement. Il scannait les clés SSH, les identifiants AWS/GCP/Azure, les tokens Kubernetes et les mots de passe de bases de données. Les données étaient chiffrées en AES/RSA puis exfiltrées vers models.litellm.cloud et checkmarx.zone, des domaines enregistrés par les attaquants. Un backdoor Python nommé sysmon était installé en persistance via systemd.

Par une ironie du sort, c'est un bug dans le code de l'attaquant qui a accéléré la détection. Le mécanisme .pth créait une boucle récursive : chaque processus Python lancé par le malware déclenchait à son tour le .pth, créant une fork bomb qui saturait la RAM et rendait le problème immédiatement visible.

Ce que cela révèle sur les pipelines IA en agence

Chez Bridgers, nous travaillons quotidiennement avec des architectures qui intègrent des passerelles LLM comme LiteLLM, des orchestrateurs d'agents et des chaînes de traitement complexes. Cet incident met en lumière trois problèmes structurels que nous observons dans la plupart des projets IA d'agence.

Le premier problème est la concentration des secrets. Un proxy LLM centralise par nature les clés API de multiples fournisseurs. C'est un single point of failure pour les credentials. La plupart des équipes stockent ces clés dans des variables d'environnement sans rotation automatique, sans vault externe, sans segmentation. Un compromis du proxy expose tout.

Le deuxième problème est l'absence de vérification d'intégrité des dépendances. Combien de Dockerfile en agence contiennent pip install litellm sans épingler la version ni vérifier le hash ? Combien de pipelines CI/CD utilisent des GitHub Actions référencées par tag mutable plutôt que par SHA ? La commodité a systématiquement pris le pas sur la sécurité dans l'écosystème Python/IA.

Le troisième problème est le manque de cloisonnement entre projets clients. En agence, un même développeur travaille souvent sur plusieurs projets. Un seul poste compromis peut exposer les environnements de tous les clients simultanément si les accès ne sont pas strictement segmentés.

Stratégie de protection pour les agences : au-delà de la réaction

La vérification immédiate reste nécessaire pour quiconque a utilisé LiteLLM pendant la fenêtre d'exposition. Lancez pip show litellm pour vérifier la version. Cherchez le fichier litellm_init.pth avec find / -name "litellm_init.pth" 2>/dev/null. Examinez les connexions vers models.litellm.cloud et checkmarx.zone dans vos logs réseau. Vérifiez la présence d'un processus sysmon dans ~/.config/ et les services systemd utilisateur suspects.

Mais la vraie question pour une agence est de savoir comment éviter de se retrouver dans cette situation à l'avenir. Et la réponse passe par des changements de pratiques profondes, pas par un simple scan post-incident.

La première mesure est l'épinglage strict des dépendances avec vérification de hash. Chaque package installé dans un Dockerfile ou un requirements.txt doit être épinglé à une version précise avec son hash SHA256. Cette pratique empêche l'installation d'un package modifié même si le numéro de version est identique.

La deuxième mesure est la centralisation des secrets dans un vault externe. HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager ou Azure Key Vault : les clés API ne doivent jamais résider en variables d'environnement statiques. Un vault permet la rotation automatique, l'audit des accès et la révocation instantanée.

La troisième mesure est l'épinglage des GitHub Actions par SHA. Remplacer uses: aquasecurity/trivy-action@main par uses: aquasecurity/trivy-action@abc123def456 est la seule façon de garantir que le code exécuté dans votre pipeline CI/CD est celui que vous avez validé.

La quatrième mesure est le cloisonnement des environnements par client. Chaque projet client devrait disposer de son propre jeu de credentials, de ses propres comptes cloud et de son propre accès réseau. Un compromis sur un projet ne doit pas cascader vers les autres.

L'image Docker officielle n'est pas concernée : une nuance importante

Un point souvent mal compris dans les analyses de cet incident : l'image Docker officielle de LiteLLM Proxy n'a pas été affectée. Cette image épingle ses dépendances et n'installe pas via pip depuis PyPI au moment du build. Les installations depuis le code source GitHub sont également épargnées.

Cette distinction est fondamentale pour les agences qui recommandent des architectures à leurs clients. Préconiser l'utilisation de conteneurs officiels plutôt que des installations pip directes dans des images custom n'est plus une simple bonne pratique. C'est devenu une exigence de sécurité.

Le vrai problème : la confiance implicite dans l'écosystème open source IA

Au fond, l'incident LiteLLM pose une question que l'industrie IA préfère ignorer. La vitesse d'innovation dans l'écosystème des agents IA repose sur une confiance implicite dans des milliers de packages open source maintenus par des équipes réduites. Quand un package atteint 3,4 millions de téléchargements quotidiens, il devient une cible de choix pour les attaquants, mais son infrastructure de sécurité ne scale pas proportionnellement.

Pour les agences digitales qui construisent des solutions IA pour leurs clients, cela signifie que la sécurité de la supply chain logicielle doit devenir une compétence métier, pas un sujet délégué à l'équipe infra. Chaque nouveau package IA ajouté à un projet augmente la surface d'attaque. Chaque mise à jour automatique est un vecteur potentiel. Et la question n'est plus de savoir si une autre attaque de ce type surviendra, mais quand.

L'incident LiteLLM n'est pas un accident. C'est la conséquence logique d'un écosystème qui a privilégié la vitesse d'adoption sur la robustesse de la chaîne d'approvisionnement. Les agences qui auront investi dans leurs pratiques DevSecOps avant le prochain incident seront celles qui pourront garantir à leurs clients que la promesse de l'IA ne se transforme pas en risque existentiel.