LiteLLM compromis : la plus grande supply chain IA de 2026

Comment une supply chain attack a compromis l'infrastructure IA de 2 500 organisations

En mars 2026, un groupe de cybercriminels connu sous le nom de Team PCP a réussi à s'introduire dans la chaîne de compilation de LiteLLM, l'un des frameworks open source les plus utilisés par les développeurs pour orchestrer des appels vers différents modèles de langage (LLM) tels que GPT, Claude, Gemini ou Mistral. L'incident, découvert et documenté par la société de cybersécurité CloudSEK, n'a été rendu public qu'en août 2026, révélant une compromission d'une amplitude sans précédent dans l'écosystème des outils d'infrastructure IA.

Le vecteur d'attaque est remarquable par sa sophistication et son exploitation d'une faiblesse structurelle commune dans les chaînes CI/CD open source. Team PCP a pris le contrôle du pipeline de compilation de LiteLLM non pas en attaquant directement les serveurs du projet, mais en ciblant l'un de ses outils de sécurité tiers : Trivy, le scanner de vulnérabilités open source de la société Aqua Security, utilisé par LiteLLM pour auditer son propre code. Les attaquants ont exploité un token d'automatisation précédemment révoqué mais jamais entièrement invalidé — une distinction technique cruciale — laissant une fenêtre d'environ 20 jours pendant laquelle ils pouvaient force-pusher du code malveillant par-dessus les tags de version publiés de Trivy.

En substituant une version de Trivy corrompue à la version légitime dans le pipeline CI de LiteLLM, Team PCP a fait en sorte que toute organisation intégrant LiteLLM dans son pipeline de développement télécharge et exécute automatiquement le scanner malveillant. Ce scanner modifié ne se contentait pas d'analyser le code : il exfiltrait discrètement l'ensemble des secrets accessibles dans l'environnement d'exécution CI/CD. Selon CloudSEK, les paquets compromis ont été disponibles pendant environ 40 minutes avant leur détection et retrait — mais cette fenêtre courte a suffi à exposer des centaines de milliers de pipelines en production.

L'inventaire des données exfiltrées dressé par CloudSEK est alarmant. Les credentials volés comprennent des clés d'accès cloud pour AWS, Google Cloud et Azure, des tokens de dépôts GitHub et GitLab, des clés SSH permettant l'accès aux serveurs de production, des secrets Kubernetes pour des clusters en production, des tokens de publication de paquets sur PyPI et npm, des variables d'environnement contenant des identifiants de bases de données, et — particulièrement préoccupant dans le contexte de l'écosystème LiteLLM — des clés API pour des fournisseurs de modèles IA comme OpenAI, Anthropic, Google, Mistral et d'autres passerelles LLM. Dans les cas où l'exfiltration directe n'a pas réussi, le malware a créé un dépôt public dans le compte GitHub de la victime et y a déposé les données volées en tant que release asset — une technique d'exfiltration détournée rarement documentée à cette échelle.

L'impact potentiel dépasse largement la seule compromission des 40 minutes d'exposition. CloudSEK a identifié 2 500 organisations et plus de 434 000 pipelines CI/CD potentiellement exposés. Cette estimation inclut des entreprises de toutes tailles : des startups IA jusqu'à de grandes entreprises ayant intégré LiteLLM comme brique centrale de leurs plateformes d'agents autonomes, de leurs applications RAG (Retrieval-Augmented Generation) ou de leurs proxys de modèles en production. Le FBI, dans son alerte FLASH émise en juillet 2026, a explicitement averti que les acteurs liés à cette campagne sont susceptibles de monétiser les credentials volés bien après l'intrusion initiale, en lançant de nouvelles attaques de supply chain depuis les accès compromis.

La timeline de la réponse à incident révèle les difficultés inhérentes à la détection de ce type d'attaque. L'intrusion dans Trivy a eu lieu en mars 2026, mais la publication du rapport détaillé de CloudSEK n'intervient qu'en août — soit cinq mois après les faits. Ce délai s'explique par la complexité de l'investigation : pour reconstituer la chaîne d'attaque, les chercheurs de CloudSEK ont dû analyser les logs de compilation, corréler des événements dans des pipelines CI appartenant à des centaines d'organisations différentes, et remonter jusqu'au token compromis dans l'infrastructure de Trivy. Les organisations victimes n'avaient souvent aucune visibilité directe sur la compromission, car elle s'était produite dans un outil de sécurité tiers exécuté automatiquement par leur pipeline.

Le choix de LiteLLM comme vecteur d'attaque n'est pas anodin. Ce framework, développé par la société BerriAI, est devenu en 2025-2026 l'un des composants les plus utilisés dans l'écosystème des agents IA et des plateformes LLM en entreprise. Sa popularité tient à sa capacité à abstraire les appels vers plus de 100 fournisseurs de modèles différents derrière une interface unifiée, facilitant les tests de modèles, les migrations et la gestion des coûts. En ciblant LiteLLM plutôt qu'un fournisseur de modèle directement, Team PCP a maximisé sa surface d'impact en atteignant simultanément des organisations utilisant GPT, Claude, Gemini et d'autres modèles à travers un seul point de compromission.

Les mesures de remédiation recommandées par CloudSEK et le FBI sont immédiates et non négociables pour toute organisation ayant utilisé LiteLLM entre fin février et mi-mars 2026 : rotation complète et immédiate de tous les secrets d'infrastructure (clés cloud, tokens d'API, clés SSH, secrets Kubernetes), audit des accès effectués depuis les comptes et projets GitHub associés, révocation et régénération des tokens de publication de paquets, et analyse forensique des logs CI/CD pour détecter d'éventuels accès non autorisés subséquents.

Une attaque qui redéfinit les risques de l'écosystème IA open source

L'attaque LiteLLM/Trivy illustre une évolution majeure de la menace supply chain : les attaquants ne ciblent plus seulement les bibliothèques logicielles directement utilisées par les applications, mais les outils de sécurité et de développement intégrés dans les pipelines CI/CD eux-mêmes. Cette stratégie est particulièrement insidieuse car elle retourne contre les organisations les outils censés les protéger. Trivy est utilisé par des dizaines de milliers de projets open source et d'entreprises pour scanner leurs propres vulnérabilités ; sa compromission transforme chaque scan en vecteur d'exfiltration.

L'explosion de l'adoption de frameworks d'orchestration IA comme LiteLLM, LangChain, LlamaIndex ou AutoGen a créé une nouvelle classe de risques de supply chain spécifiques à l'écosystème IA. Ces frameworks sont caractérisés par des cycles de développement très rapides, des dépendances nombreuses et souvent peu auditées, et une centralisation des accès aux API de fournisseurs de modèles — ce qui en fait des cibles particulièrement attractives pour des acteurs motivés par le vol de credentials LLM à haute valeur. Une clé API volée peut être revendue ou utilisée pour des campagnes de génération de spam, de phishing ou de désinformation à grande échelle avec un coût quasi nul pour l'attaquant.

Cet incident met également en lumière une lacune dans les pratiques de sécurité des pipelines CI/CD : la gestion des tokens d'automatisation. L'exploitation d'un token précédemment révoqué mais jamais entièrement invalidé pointe vers une confusion commune entre la révocation logique d'un token (marquer comme inactif dans une interface) et son invalidation technique complète dans tous les systèmes où il était enregistré. Cette distinction, bien connue des équipes de sécurité IAM, est régulièrement sous-estimée dans la gestion des tokens d'intégration CI/CD, qui se retrouvent souvent dans des registres de packages, des configurations de webhooks ou des scripts d'automatisation oubliés.

Pour les RSSI et les équipes DevSecOps, cet incident devrait accélérer l'adoption de plusieurs pratiques préventives : l'utilisation de solutions SLSA (Supply chain Levels for Software Artifacts) pour vérifier l'intégrité des artefacts de build, la mise en place de politiques de moindre privilège dans les environnements CI/CD limitant l'accès des outils tiers aux seuls secrets strictement nécessaires, et l'audit régulier des tokens d'automatisation avec des politiques de rotation et d'expiration automatique. Les environnements CI/CD sont devenus des concentrateurs de secrets extrêmement sensibles ; leur sécurité mérite un niveau d'attention équivalent à celui accordé aux environnements de production.

Ce qu'il faut retenir

• Si LiteLLM a été utilisé dans vos pipelines CI/CD entre fin février et mi-mars 2026, considérez que tous vos secrets d'infrastructure sont potentiellement compromis et procédez à leur rotation immédiate.
• Les outils de sécurité intégrés dans les pipelines CI/CD (scanners, linters, analyseurs SAST/DAST) sont devenus des cibles d'attaque de première importance : vérifiez leur intégrité via des mécanismes de signature de code ou des hash cryptographiques.
• Les clés API de fournisseurs IA (OpenAI, Anthropic, Google, Mistral…) sont une cible de valeur croissante pour les cybercriminels : traitez-les avec le même niveau de protection que vos credentials d'infrastructure cloud.