Attaque LiteLLM : ce que les équipes dev doivent faire

Ce qui s'est passé

Le 24 mars 2026, quelqu'un a publié des versions malveillantes de LiteLLM (1.82.7 et 1.82.8) directement sur PyPI, en contournant le processus de publication normal du projet. Les paquets compromis contenaient un voleur de credentials qui récupérait des clés SSH, des credentials de fournisseurs cloud, des configurations Kubernetes, des clés API et bien plus encore, avant de les exfiltrer vers un domaine qui ressemblait à celui de LiteLLM sans l'être.

Les paquets malveillants ont été en ligne pendant environ 40 minutes avant que PyPI ne les mette en quarantaine. Ça ne semble pas grand-chose. Mais LiteLLM est installé environ 15 à 20 millions de fois par semaine, ce qui représente près de 1 700 installations par minute. Durant cette fenêtre, plus de 119 000 téléchargements ont eu lieu. On estime que 40 à 50 % d'entre eux provenaient d'installations non épinglées récupérant automatiquement la dernière version.

L'attaque trouve son origine dans une dépendance Trivy compromise dans le workflow de scan de sécurité CI/CD de LiteLLM. Un groupe appelé TeamPCP est présumé responsable, et des indices laissent penser qu'il s'est associé au groupe d'extorsion Lapsus$ pour monétiser les données volées. À la RSA Conference la semaine dernière, des chercheurs en réponse aux incidents ont confirmé avoir connaissance de plus de 1 000 environnements SaaS touchés, et les chasseurs de menaces estiment que des données ont été exfiltrées depuis 500 000 machines.

Cette semaine, la première victime en aval a rendu son cas public. Une startup de recrutement IA a confirmé être « l'une des milliers d'entreprises » touchées, et le groupe Lapsus$ met désormais aux enchères ce qu'il affirme être 4 To de données volées, incluant du code source, des credentials et des configurations VPN.

Pourquoi cette attaque est différente des CVE habituels

Les avis sur la chaîne d'approvisionnement se multiplient au point de se confondre. Celui-ci se distingue pour plusieurs raisons.

Premièrement, le vecteur d'attaque. La compromission n'a pas commencé par LiteLLM lui-même. Elle a commencé par Trivy, un scanner de vulnérabilités open source que de nombreuses équipes font tourner dans leurs pipelines CI/CD. Réfléchissez-y une seconde : l'outil que vous utilisez pour scanner les vulnérabilités était le point d'entrée. Vos outils de sécurité ont compromis votre sécurité. Ce n'est pas seulement ironique — c'est un rappel que les pipelines CI/CD sont des cibles de choix, et que chaque outil qui y tourne mérite le même niveau de vigilance que vos dépendances de production.

Deuxièmement, la position de LiteLLM dans la stack. C'est une interface unifiée pour appeler des LLM depuis plusieurs fournisseurs. Cela signifie qu'il a généralement accès aux clés API de chacun de vos fournisseurs IA, ainsi qu'aux variables d'environnement et credentials cloud présents dans le même contexte. Compromettre un paquet à cette position offre aux attaquants un raccourci vers tout.

Troisièmement, le rayon d'impact en aval. LiteLLM n'est pas seulement installé directement. C'est une dépendance transitive intégrée par des frameworks d'agents IA, des serveurs MCP et des outils d'orchestration de LLM. Des équipes qui n'ont jamais entendu parler de LiteLLM l'ont peut-être quand même fait tourner dans leurs jobs CI.

Ce que nous observons dans notre propre travail

Lors de missions de tests de pénétration pour des studios de jeux vidéo, l'une des premières choses que nous examinons est le pipeline CI/CD. C'est systématiquement la cible la plus vulnérable. Les équipes investissent massivement dans les firewalls, les WAF et la surveillance au runtime, mais le pipeline de build tourne souvent avec des permissions trop larges, récupère des dépendances sans les épingler, et journalise des secrets d'une façon qui ferait grimacer n'importe qui.

Nous avons observé des schémas similaires en développant des applications cloud-native pour des clients entreprise soumis à des exigences strictes de conformité. Les environnements réglementaires suisses, par exemple, vous obligent à démontrer que vous maîtrisez votre chaîne d'approvisionnement logicielle. Ce n'est pas qu'un exercice de case à cocher. Cela signifie connaître exactement la version de chaque dépendance que vous faites tourner, sa date de publication, et les checksums correspondants. Les équipes qui avaient déjà cette discipline en place étaient celles les moins exposées à cette attaque.

Dans nos projets iOS et Android natifs, nous avons historiquement été un peu plus à l'abri de ce type d'attaque, car les écosystèmes Apple et Google disposent d'outils de build plus centralisés. Mais la tendance évolue. De plus en plus d'équipes mobile intègrent des outils de génération de code IA et des fonctionnalités basées sur des LLM dans leurs applications, ce qui fait entrer des outils Python dans des pipelines de build qui n'en avaient jamais eu auparavant. Si vous exécutez du prétraitement IA/ML dans le cadre de votre build mobile, vérifiez votre arbre de dépendances.

Ce que vous devriez concrètement faire

Voici des étapes concrètes. Certaines sont réalisables dès aujourd'hui.

Épinglez vos dépendances. Pas seulement dans requirements.txt, mais partout : Dockerfiles, config CI, GitHub Actions. Utilisez le hash-pinning là où votre gestionnaire de paquets le supporte. Le fait que 40 à 50 % des installations de LiteLLM récupéraient la dernière version à chaque exécution est la cause principale pour laquelle une fenêtre de 40 minutes a touché autant d'environnements.

Vérifiez si vous avez été exposé. Si vous avez installé ou mis à jour LiteLLM via pip le 24 mars entre 10 h 39 et 16 h 00 UTC, vérifiez les versions 1.82.7 ou 1.82.8. Exécutez pip show litellm dans chaque environnement. Recherchez ~/.config/sysmon/sysmon.py et des pods suspects dans Kubernetes correspondant à node-setup-*. LiteLLM et plusieurs firmes de sécurité ont publié des scripts de scan. Utilisez-les.

Faites tourner vos credentials sans attendre. Si vous trouvez le moindre signe de compromission, considérez que chaque credential sur cette machine est brûlé : clés SSH, tokens cloud, mots de passe de bases de données, clés API dans les fichiers .env. Supprimer simplement le paquet ne suffit pas, car le malware était conçu pour s'établir durablement et peut avoir déjà déployé des charges utiles supplémentaires.

Utilisez des délais de refroidissement pour les dépendances. PyPI intègre des « relative dependency cooldowns » dans pip v26.1 (attendu ce mois-ci), ce qui vous permet de configurer pip pour n'installer que des paquets publiés depuis un délai minimum. Ça ne protège pas de tout, mais cela aurait empêché l'installation automatique d'un paquet en ligne depuis seulement 40 minutes. Vous pouvez déjà définir des délais absolus dans pip v26.0 avec le flag --uploaded-prior-to.

Auditez les permissions de vos outils CI/CD. Votre scanner de vulnérabilités, votre linter, votre test runner — ils tournent tous avec les permissions de votre pipeline. Si votre pipeline peut pousser en production, un scanner compromis le peut aussi. Appliquez le principe du moindre privilège à chaque étape.

La vérité inconfortable sur les outils IA et les chaînes d'approvisionnement

Voici ce qui me préoccupe dans cette affaire. La stack de développement IA est jeune, en évolution rapide, et repose sur un nombre relativement restreint de paquets open source dont tout le monde dépend. LiteLLM, LangChain, divers frameworks d'agents. Ces projets avancent vite, livrent souvent, et sont maintenus par de petites équipes. Ce n'est pas une critique — c'est simplement la réalité de là où nous en sommes.

Le rapport 2026 State of DevOps Modernization Report a révélé que près d'un quart des déploiements nécessitent une remédiation, avec des délais de remédiation dépassant en moyenne 7,5 heures. Ajoutez du code généré par IA et des dépendances gérées par IA à ce mélange, et vous obtenez une chaîne d'approvisionnement qui s'étend plus vite que la plupart des équipes ne peuvent l'auditer.

D'après notre expérience PHP et Docker avec des clients entreprise, nous savons que la discipline en matière de chaîne d'approvisionnement est ennuyeuse. Peu glorieuse. Personne ne veut passer un sprint à resserrer les pins de dépendances et à revoir les permissions CI. Mais les équipes qui le font sont celles qui dorment tranquillement lors d'incidents comme celui-ci, plutôt que de se précipiter à faire tourner chaque credential qu'elles possèdent.

Si tout cela vous semble inconfortablement familier, ou si vous n'êtes pas sûr que votre pipeline CI/CD survivrait à ce type d'attaque, parlons-en. Nous réalisons des audits de sécurité qui couvrent spécifiquement les pipelines de build et la gestion des dépendances — pas seulement le périmètre de production — et nous apportons l'expérience de développement nécessaire pour comprendre ce qui est réellement faisable pour votre équipe.