LiteLLM : quand une attaque supply chain expose toute la filière IA

Le 24 mars 2026, deux versions malveillantes du package Python LiteLLM ont été publiées sur PyPI. En seulement 40 minutes, un malware voleur de credentials a été téléchargé par des milliers de pipelines CI/CD à travers le monde. Retour sur une attaque qui illustre la fragilité de la chaîne logicielle de l'IA.

LiteLLM : un maillon critique de l'infrastructure IA

LiteLLM est une bibliothèque Python open source qui unifie les appels vers plus de 100 fournisseurs de modèles de langage (OpenAI, Anthropic, Azure, AWS Bedrock, etc.) via une interface unique. Avec 97 millions de téléchargements mensuels et une présence estimée dans 36 % des environnements cloud, LiteLLM est devenu un composant central de nombreuses architectures IA en production.

Cette popularité en fait une cible de choix pour les attaquants.

Chronologie de l'attaque

L'attaque contre LiteLLM s'inscrit dans une campagne plus large orchestrée par le groupe TeamPCP :

Fin février 2026 : compromission initiale du dépôt Trivy (scanner de sécurité d'Aqua Security)
19 mars : vague de compromission de Trivy via des credentials CI volés
21 mars : empoisonnement des tags GitHub Action de KICS
24 mars, 10h39 UTC : publication des versions malveillantes litellm==1.82.7 et litellm==1.82.8 sur PyPI
24 mars, ~11h19 UTC : les packages sont mis en quarantaine après environ 40 minutes
27 mars : compromission du SDK Python Telnyx par le même groupe
30 mars : publication de la version propre 1.83.0 via un nouveau pipeline CI/CD

Anatomie technique du malware

Les versions compromises embarquaient deux charges utiles :

Le fichier `.pth` (version 1.82.8)

Un fichier litellm_init.pth était déposé dans site-packages. Les fichiers .pth ont une particularité redoutable : ils sont exécutés automatiquement à chaque démarrage de l'interpréteur Python. Le malware utilisait subprocess.Popen pour lancer ses processus de collecte.

Ironie du sort : cette implémentation contenait un bug fatal. Chaque processus fils déclenchait à son tour le fichier .pth, créant une bombe fork exponentielle qui saturait le CPU. C'est précisément ce comportement qui a permis la détection rapide de l'attaque.

Le proxy serveur modifié (versions 1.82.7 et 1.82.8)

Un fichier proxy_server.py modifié contenait du code conçu pour :

Collecter les variables d'environnement (clés API, tokens cloud)
Extraire les clés SSH et les credentials Git
Voler les tokens Kubernetes et les mots de passe de bases de données
Récupérer les credentials AWS, GCP et Azure
Exfiltrer les données via des requêtes POST chiffrées vers models.litellm[.]cloud, un domaine contrôlé par les attaquants

L'effet domino : de Trivy à Mercor

L'attaque illustre parfaitement le risque de propagation en cascade dans les chaînes logicielles modernes :

Trivy (outil de scan de sécurité) est compromis
Les credentials CI/CD volés via Trivy permettent d'accéder au pipeline de publication de LiteLLM
Les versions malveillantes de LiteLLM infectent des milliers d'environnements en aval
Mercor, startup IA de recrutement, confirme être touchée le 2 avril 2026

Le groupe Lapsus$ revendique la possession de 4 To de données Mercor, incluant des profils de candidats, des données personnelles, du code source, des clés d'API et des enregistrements d'entretiens vidéo. Ces données sont mises aux enchères sur des forums clandestins.

Qui était réellement exposé ?

Selon l'analyse post-incident de LiteLLM, les utilisateurs impactés sont ceux qui ont :

Installé ou mis à jour LiteLLM via pip le 24 mars entre 10h39 et 16h00 UTC
Utilisé des dépendances non épinglées (sans version fixe dans requirements.txt)
Exécuté des pipelines CI/CD avec installation automatique des dernières versions

Les utilisateurs de l'image Docker officielle du proxy LiteLLM n'étaient pas affectés, car les dépendances y sont épinglées dans le requirements.txt.

Leçons pour sécuriser vos dépendances IA

Cette attaque met en lumière des pratiques essentielles, souvent négligées dans l'écosystème IA :

1. Épinglez vos dépendances

# Mauvaise pratique
litellm
 
# Bonne pratique
litellm==1.82.6

Ne laissez jamais pip install récupérer la dernière version sans contrôle. Utilisez un fichier requirements.txt avec des versions exactes et vérifiez les checksums SHA-256.

2. Adoptez un registre privé ou un proxy de packages

Des outils comme Artifactory, Nexus ou AWS CodeArtifact permettent de filtrer et scanner les packages avant qu'ils n'atteignent vos environnements. Configurez des politiques de rétention et de validation automatique.

3. Auditez votre chaîne CI/CD

Isolez les runners CI avec un accès réseau restreint
Utilisez des credentials éphémères plutôt que des tokens longue durée
Activez l'authentification multi-facteur sur tous les comptes de publication (PyPI, npm, etc.)
Surveillez les accès sortants inhabituels depuis vos pipelines

4. Intégrez un SBOM (Software Bill of Materials)

Générez et maintenez un inventaire complet de vos dépendances avec des outils comme Syft ou CycloneDX. En cas d'incident, vous pourrez identifier rapidement les composants affectés.

5. Surveillez le comportement réseau en production

Le malware LiteLLM exfiltrait des données vers un domaine non officiel. Un monitoring des connexions sortantes aurait pu déclencher une alerte immédiate. Des solutions comme Falco ou Tracee détectent ce type de comportement anormal au runtime.

La surface d'attaque croissante de l'IA

L'écosystème IA repose sur un empilement de dépendances open source rarement audité avec la rigueur nécessaire. LiteLLM n'est qu'un exemple : les SDK de fournisseurs, les frameworks d'orchestration d'agents, les bibliothèques de vectorisation — chacun représente un vecteur d'attaque potentiel.

Avec l'adoption massive des agents IA autonomes en entreprise, les conséquences d'une compromission de la supply chain ne se limitent plus au vol de code. Un agent compromis peut :

Accéder à des systèmes internes via des credentials volés
Modifier du code en production sans supervision humaine
Exfiltrer des données métier sensibles

Actions immédiates recommandées

Si vous utilisez LiteLLM dans vos projets, voici les actions à entreprendre :

Vérifiez si litellm==1.82.7 ou 1.82.8 a été installé dans vos environnements
Recherchez la présence du fichier litellm_init.pth dans vos répertoires site-packages
Bloquez le trafic sortant vers models.litellm[.]cloud et checkmarx[.]zone
Effectuez une rotation de tous vos secrets : clés API, tokens cloud, clés SSH, credentials de base de données
Mettez à jour vers litellm>=1.83.0 qui a été publié via un pipeline CI/CD entièrement reconstruit

Conclusion

L'attaque LiteLLM est un signal d'alarme pour toute organisation qui construit avec l'IA. La sécurité de la supply chain logicielle n'est plus un sujet réservé aux équipes DevSecOps — c'est un enjeu stratégique qui concerne chaque développeur, chaque architecte et chaque décideur technique.

Dans un écosystème où un package PyPI compromis pendant 40 minutes peut affecter des milliers d'entreprises, la confiance aveugle dans les dépendances open source n'est plus une option.