LiteLLM compromis sur PyPI : une attaque supply chain expose les cles API de milliers de developpeurs

Ce qui s est passe le 24 mars 2026

Le 24 mars 2026 a 10:39 UTC, deux nouvelles versions du package Python litellm sont apparues sur PyPI : les versions 1.82.7 et 1.82.8. LiteLLM est un proxy open source extremement populaire qui unifie les appels vers plus de 100 fournisseurs de LLM (OpenAI, Anthropic, Azure, Bedrock, Vertex AI, etc.). Avec plus de 28 millions de telechargements mensuels et une adoption massive dans les pipelines d inference IA en production, c est l une des bibliotheques les plus critiques de l ecosysteme AI Python.

Ces deux versions contenaient un fichier malveillant nomme litellm_init.pth insere dans le repertoire site-packages lors de l installation. La particularite des fichiers .pth en Python est qu ils sont executes automatiquement au demarrage de tout processus Python sur le systeme, sans qu aucun import explicite ne soit necessaire. C est un vecteur d attaque particulierement insidieux car il ne necessite pas que le code malveillant soit appele directement.

Les packages compromis sont restes en ligne pendant environ 40 minutes, de 10:39 a 11:20 UTC, avant d etre mis en quarantaine par l equipe de securite PyPI. Pendant cette fenetre, les systemes CI/CD configurees en auto-update et les developpeurs ayant effectue un pip install --upgrade litellm ont ete exposes.

Le vecteur d attaque : Trivy comme cheval de Troie

L ironie de cette attaque est saisissante. Le groupe TeamPCP a obtenu les credentials PyPI du mainteneur principal de LiteLLM en compromettant d abord Trivy, un scanner de securite open source developpe par Aqua Security. Trivy est utilise par des dizaines de milliers d organisations pour detecter les vulnerabilites dans les containers, les fichiers systeme et les dependances. LiteLLM l utilisait dans son propre pipeline CI/CD pour verifier la securite de ses releases.

Selon l analyse publiee par Snyk le 28 mars, TeamPCP a d abord insere un composant malveillant dans une version specifique de Trivy distribuee via un canal non-officiel. Ce composant extrayait les variables d environnement des pipelines CI/CD ou Trivy s executait, incluant les tokens d authentification PyPI, npm, et Docker Hub.

Une fois les credentials PyPI de LiteLLM obtenues, l attaquant a publie les versions trojanisees en utilisant le compte du mainteneur legitime. Pour les systemes de verification, la publication semblait parfaitement normale : bon compte, bonne signature, increment de version logique.

Kaspersky a confirme dans un rapport ulterieur que Trivy, Checkmarx et LiteLLM avaient tous ete compromis dans le cadre de la meme campagne, suggerant une operation coordonnee visant specifiquement les outils de securite de la supply chain logicielle. C est une strategie de type "attaque du gardien" : compromettre les outils censes proteger la chaine pour ensuite remonter vers les cibles finales.

Anatomie technique du credential stealer

Le fichier litellm_init.pth contenait du code Python obfusque qui, une fois decode, revelait un credential stealer sophistique. Voici ce qu il ciblait :

• Cles SSL/SSH : parcours recursif de ~/.ssh/ et extraction de toutes les cles privees (id_rsa, id_ed25519, etc.)
• Credentials cloud : lecture de ~/.aws/credentials, ~/.config/gcloud/, ~/.azure/
• Configurations Kubernetes : extraction complete de ~/.kube/config incluant les tokens de service account
• Credentials Git : vol de ~/.git-credentials et des tokens stockes dans les helpers de credential
• Cles API : scan des variables d environnement pour OPENAI_API_KEY, ANTHROPIC_API_KEY, AZURE_API_KEY, et 47 autres patterns
• Historique shell : exfiltration de .bash_history et .zsh_history (souvent riches en credentials colles en clair)
• Wallets crypto : detection et extraction des keystores Ethereum, fichiers wallet Bitcoin, et configs MetaMask

L exfiltration se faisait via des requetes HTTPS POST vers un serveur C2 (command and control) heberge derriere Cloudflare Workers, rendant le blocage par IP inefficace. Les donnees etaient chiffrees avec une cle publique RSA-4096 embarquee dans le payload, empechant toute interception en clair meme avec un proxy SSL.

Timeline detaillee de l incident

Voici la chronologie precise des evenements telle que reconstituee par les equipes de securite de PyPI, Snyk et Kaspersky :

CVE-2026-42208 : injection SQL dans le proxy LiteLLM

En parallele de l attaque supply chain, les chercheurs de Snyk ont decouvert une vulnerabilite critique dans le code source legitime de LiteLLM. La CVE-2026-42208 (score CVSS 9.3) est une injection SQL dans la couche de base de donnees du proxy LiteLLM. Elle permet a un attaquant non-authentifie d extraire la totalite des cles API stockees dans la base du proxy, d escalader ses privileges, et potentiellement d executer du code arbitraire sur le serveur.

Cette vulnerabilite affecte toutes les versions du proxy LiteLLM anterieures a la 1.83.7. Elle est independante de l attaque supply chain mais a ete decouverte dans le cadre de la meme investigation. Combinee avec la CVE-2026-35030 (bypass d authentification affectant les deployments JWT), elle offrait un vecteur d attaque complet contre les infrastructures utilisant LiteLLM comme gateway IA.

La correction a ete publiee dans la version 1.83.7 le 2 avril 2026. Si vous utilisez le proxy LiteLLM en production, la mise a jour est critique et urgente. La documentation officielle sur docs.litellm.ai detaille les mesures de hardening recommandees.

Comparaison des versions : compromises vs sures

Pour vous aider a evaluer rapidement votre exposition, voici le tableau comparatif des versions affectees :

L ecosysteme compromis : pas seulement LiteLLM

L analyse de Kaspersky revele que l attaque de TeamPCP ne se limitait pas a LiteLLM. Trois outils majeurs de l ecosysteme securite et IA ont ete compromis dans la meme campagne :

Cette strategie en cascade est particulierement redoutable : en compromettant d abord les outils de detection (Trivy pour les vulnerabilites, Checkmarx pour l analyse statique), TeamPCP s assurait que leurs insertions malveillantes dans d autres projets comme LiteLLM ne seraient pas detectees par les scanners automatiques des victimes. C est une attaque sur la confiance meme de l ecosysteme de securite.

Impact sur les equipes de developpement IA en France

LiteLLM est massivement adopte par les equipes IA francaises. D apres nos echanges avec une vingtaine de CTOs et lead devs dans l ecosysteme French Tech, au moins 60 a 70 pourcent des startups IA francaises utilisant plusieurs providers LLM ont LiteLLM dans leur stack, soit directement soit via des frameworks comme LangChain qui le referecent en dependance optionnelle.

Les equipes les plus exposees sont celles qui :

• Utilisent pip install --upgrade sans pin de version dans leurs Dockerfiles
• Ont des pipelines CI/CD qui rebuilent automatiquement a chaque push sans lockfile
• Deploient LiteLLM proxy en production avec un acces direct a Internet
• N ont pas de monitoring des connexions sortantes depuis leurs containers

Pour les equipes basees en France qui pensent avoir ete exposees, la procedure de remediation est detaillee dans notre guide Comment proteger votre pipeline Python contre les attaques supply chain en 7 etapes. Si vous avez besoin d un accompagnement immediat, notre equipe peut intervenir sous 24h : contactez-nous.

Les lecons strategiques pour la supply chain open source

Cette attaque cristallise plusieurs problemes systemiques que la communaute open source discute depuis des annees sans les resoudre. Premierement, le modele de confiance transitive est fondamentalement fragile : quand vous installez LiteLLM, vous faites implicitement confiance a tous les outils utilises dans son CI/CD, et aux outils utilises dans le CI/CD de ces outils, et ainsi de suite. La surface d attaque croit exponentiellement.

Deuxiemement, la fenetre de 40 minutes suffit largement dans un ecosysteme ou les pipelines CI/CD s executent en continu. Les mecanismes de detection actuels de PyPI, bien qu efficaces (la detection a ete rapide), ne peuvent pas empecher l exposition initiale. La securite post-publication est necessaire mais insuffisante.

Troisiemement, les fichiers .pth representent un vecteur sous-estime. Contrairement a du code dans un __init__.py qui necessite un import explicite, un fichier .pth s execute sans condition. Peu d outils d audit de securite les surveillent specifiquement. C est un angle mort documente depuis 2019 mais jamais adresse systematiquement.

Quatriemement, l attaque du gardien (compromettre les outils de securite pour desactiver les alarmes) est une tendance en forte croissance. En 2025-2026, nous avons vu des compromissions cibler CodeQL, Dependabot, et maintenant Trivy et Checkmarx. Les attaquants comprennent que le meilleur camouflage est de blinder les outils qui devraient les detecter.

Plan de remediation immediat

Si vous utilisez LiteLLM dans votre organisation, voici les actions a mener dans les 24 prochaines heures :

1. Audit des versions installees : verifiez pip freeze | grep litellm sur tous vos environnements (dev, staging, prod, CI/CD runners)
2. Recherche du fichier .pth : find / -name "litellm_init.pth" 2>/dev/null sur toutes vos machines
3. Rotation de tous les secrets si vous avez detecte les versions 1.82.7 ou 1.82.8 : cles SSH, tokens API, credentials cloud, tokens Git
4. Audit des logs reseau : recherchez des connexions HTTPS sortantes inhabituelles entre le 24 mars 10:39 et 11:20 UTC
5. Mise a jour vers litellm >= 1.83.7 pour corriger les CVE independamment de l attaque supply chain
6. Activation de la verification de hash dans pip : pip install litellm==1.83.7 --require-hashes
7. Mise en place d un miroir PyPI prive avec verification des signatures (guide Snyk)

Recommandations a long terme pour les equipes DevOps

Au-dela de la remediation immediate, cette attaque doit servir de catalyseur pour des changements structurels dans vos pratiques :

1. Adopter les lockfiles avec verification de hash

Utilisez pip-compile avec l option --generate-hashes ou Poetry avec son lockfile natif. Chaque installation doit verifier l integrite cryptographique du package telecharge contre un hash connu. Cela aurait empeche l installation silencieuse des versions compromises.

2. Deployer un miroir PyPI prive avec politique d approbation

Des outils comme Artifactory, Nexus, ou devpi permettent de creer un proxy-cache PyPI avec une politique de retention. Les nouvelles versions ne sont rendues disponibles qu apres un delai (24-72h) ou une approbation manuelle, eliminant le risque d exposition aux packages malveillants publiees puis retirees rapidement.

3. Monitorer les fichiers .pth en production

Ajoutez une regle dans vos outils de detection (OSSEC, Wazuh, Falco) pour alerter sur la creation ou modification de fichiers .pth dans les repertoires site-packages. C est un indicateur de compromission specifique a Python extremement fiable car ces fichiers changent rarement en conditions normales.

4. Implementer le principe de moindre privilege sur les CI/CD

Les tokens PyPI, npm, et Docker Hub ne devraient jamais etre accessibles depuis les jobs de test ou de scan. Isolez les secrets de publication dans des pipelines dedies avec des conditions de declenchement strictes (tag signe, approbation humaine requise).

Pour un guide complet sur la mise en place de ces protections, consultez notre article detaille : Comment proteger votre pipeline Python contre les attaques supply chain en 7 etapes. Nous y detaillons chaque mesure avec des exemples de configuration concrets pour les equipes travaillant avec Poetry, pip-tools, et les principales plateformes CI/CD.

Ce que cela signifie pour l avenir des outils IA open source

LiteLLM n est pas un cas isole. La surface d attaque de l ecosysteme AI Python croit a une vitesse vertigineuse. En 2025-2026, les packages les plus telecharges sur PyPI dans la categorie "AI/ML" incluent transformers, langchain, llama-index, vllm, et litellm. Chacun de ces packages a des centaines de dependances transitives et des pipelines CI/CD complexes.

Le marche noir des credentials IA est en plein essor. Une cle API OpenAI entreprise (tier 5) se revend entre 5 000 et 15 000 dollars. Une cle Anthropic avec acces Claude Opus se monetise encore davantage en raison des quotas limites. Les attaquants ont desormais une motivation financiere directe pour cibler specifiquement l ecosysteme AI.

La communaute open source doit collectivement investir dans trois directions : la transparence des builds reproductibles (savoir exactement quel code source a produit quel package binaire), la verification d integrite end-to-end (Sigstore, in-toto, SLSA), et la detection comportementale post-installation (sandbox d execution, monitoring des appels systeme). Les initiatives comme Snyk Open Source et le framework SLSA de Google vont dans cette direction mais sont encore insuffisamment adoptes.

Pour une veille continue sur les incidents de securite affectant l ecosysteme open source et IA, consultez egalement notre analyse precedente sur la regulation DORA et la conformite open source en 2026. Les exigences reglementaires europeennes vont dans le sens d une meilleure tracabilite de la supply chain logicielle.

FAQ