Attaque supply chain LiteLLM : 2 500 entreprises et 434 000 pipelines CI/CD exposés

YuSMP Group Editorial Team Équipe éditoriale, YuSMP Group

L'essentiel

Comment Trivy est devenu la porte d'entrée

L'attaque a exploité un unique jeton jamais révoqué, situé trois niveaux plus bas dans une chaîne de dépendances open source. TeamPCP a d'abord compromis le scanner de vulnérabilités Trivy d'Aqua Security le 19 mars 2026, obtenant un jeton PyPI que la CI de LiteLLM utilisait pour ses publications automatisées. Lorsque le système de build de LiteLLM a exécuté Trivy dans son workflow de release habituel, le scanner compromis a injecté du code malveillant dans le paquet publié.

Résultat : les versions 1.82.7 et 1.82.8 de LiteLLM, publiées sur PyPI le 24 mars. Toutes deux contenaient un fichier nommé litellm_init.pth, que Python charge automatiquement via le mécanisme des fichiers .pth au démarrage de n'importe quel processus Python – le collecteur d'identifiants s'exécutait donc même si LiteLLM n'était jamais importé directement. Les paquets malveillants sont restés disponibles environ 40 minutes (approximativement de 10 h 39 à 16 h 00 UTC) avant leur retrait par PyPI.

Ce schéma d'attaque est instructif sur la nature du risque CI/CD actuel. La cible n'était pas LiteLLM lui-même, mais un outil de sécurité auquel LiteLLM faisait implicitement confiance et dont les identifiants n'avaient jamais été limités à la lecture seule ni à une durée de validité courte. Un seul jeton non renouvelé dans le pipeline de release d'un scanner s'est transformé, en moins d'une heure, en paquet empoisonné distribué à un nombre inconnu de systèmes de build en aval.

Ce que révèle le rapport CloudSEK

Dans son analyse du 11 août 2026, CloudSEK a reconstitué l'exposition à partir d'environ 434 000 fichiers récupérés sur l'infrastructure des attaquants. L'entreprise classe plus de 2 500 organisations comme correspondances à haut niveau de confiance : leurs environnements de build présentent des traces d'installation des releases piégées pendant la fenêtre active.

Parmi les organisations nommées dans ce jeu de données figurent NVIDIA, Amazon Web Services, Cisco Systems, Samsung Electronics, Salesforce, Deloitte, Siemens, S&P Global, ServiceNow, Vodafone, Volkswagen, FedEx, Thales, Zscaler et le London Stock Exchange Group. L'ampleur de la liste montre à quel point LiteLLM est utilisé comme bibliothèque de passerelle IA, du SaaS d'entreprise jusqu'aux infrastructures logistiques.

Une nuance importante du rapport CloudSEK : le chiffre de plus de 2 500 décrit une exposition reconstituée, pas une compromission confirmée. Les pipelines CI/CD installent et mettent en cache les paquets de manières différentes, et l'impact réel dépend du démarrage effectif d'un processus Python pendant la fenêtre, des secrets accessibles dans l'environnement et de la possibilité de joindre le domaine des attaquants. Les équipes doivent analyser leurs propres journaux de build plutôt qu'attendre une notification officielle.

Ce qui a été exfiltré et pourquoi cela compte encore

Le collecteur caché dans litellm_init.pth visait un large éventail d'identifiants et d'éléments d'environnement : clés d'API cloud, dont des jetons OpenAI et Anthropic, clés d'accès et clés secrètes AWS, identifiants Azure, jetons de comptes de service GCP, jetons ServiceAccount Kubernetes, clés SSH privées, mots de passe de bases de données et variables d'environnement capturées au démarrage du processus Python. Toutes les données partaient vers un domaine contrôlé par TeamPCP – models.litellm[.]cloud –, qui imitait un point de terminaison légitime de LiteLLM.

L'alerte du FBI de juillet 2026 est importante parce que le renouvellement des identifiants après un incident de supply chain est plus lent et moins complet qu'il ne le devrait. Les secrets intégrés dans des conteneurs déployés, stockés dans des gestionnaires de secrets CI/CD sans rotation automatique ou partagés entre plusieurs services échappent souvent aux opérations de réponse à incident. L'alerte souligne que les clés d'API de fournisseurs d'IA – OpenAI, Anthropic et autres – présentent un risque particulier : elles permettent de consommer discrètement de l'inférence aux frais de la victime ou d'injecter des sorties malveillantes dans des workflows dépendants de l'IA, sans déclencher les signaux classiques de détection d'intrusion.

Selon CloudSEK, TeamPCP a également utilisé une infrastructure secondaire – des dépôts GitHub et GitLab nommés tpcp-docs ou docs-tpcp – comme canal de commande et de contrôle. Certains environnements compromis pourraient donc conserver un mécanisme de persistance actif, au-delà du vol initial d'identifiants.

Ce que cela change pour le marché français

En France, l'incident ne concerne pas que les géants américains : Thales figure dans la liste de CloudSEK, et les passerelles de type LiteLLM sont largement utilisées pour faire cohabiter plusieurs fournisseurs de modèles – y compris des modèles européens comme ceux de Mistral AI ou des modèles auto-hébergés – pour des raisons de souveraineté et de maîtrise des coûts. Souvent déployée par une équipe data dans le cadre d'un pilote, la passerelle échappe fréquemment à la cartographie du SI et à la nomenclature logicielle (SBOM). C'est précisément cet angle mort qui rend la revue des environnements de build urgente.

Pour les équipes qui conçoivent des produits à base d'IA, l'incident LiteLLM illustre une catégorie de risque qui grandit à mesure que les bibliothèques d'IA deviennent une infrastructure de base : la chaîne de confiance d'un paquet Python inclut chaque outil du pipeline de publication de son éditeur, pas seulement le paquet lui-même. LiteLLM n'a pas écrit le code malveillant. Son système de build a récupéré automatiquement une dépendance compromise, exactement comme il était conçu pour le faire. L'attaque a réussi précisément parce que l'automatisation a fonctionné comme prévu.

Concrètement, l'audit des dépendances doit aller au-delà des dépendances directes et de leur graphe transitif. Les outils de build – scanners, formateurs, linters, lanceurs de tests – qui détiennent des droits de publication ou s'exécutent avec un accès aux secrets doivent être soumis aux mêmes règles de rotation et de moindre privilège que les secrets applicatifs. Un jeton Trivy capable de publier sur PyPI ne devrait pas exister ; s'il le faut, il doit être restreint, limité dans le temps et renouvelé plus souvent que la durée pendant laquelle un attaquant peut rester indétecté.

Côté réglementaire, deux cadres sont en jeu. Pour les entités relevant de NIS2, dont l'ANSSI est l'autorité nationale de référence en France, un incident de cette ampleur justifie une revue des obligations de notification : la directive impose une alerte précoce dans les 24 heures suivant la prise de connaissance d'un incident important. Les banques, assureurs et autres entités financières sont en outre soumis à DORA pour la gestion des incidents liés aux TIC et des risques liés aux prestataires tiers. Par ailleurs, si les variables d'environnement exfiltrées donnaient accès à des données personnelles, la notification à la CNIL sous 72 heures prévue par le RGPD doit être examinée. Les organisations qui ne découvrent leur exposition de mars qu'avec le rapport d'août doivent clarifier les délais avec leurs équipes juridique et conformité.

Pour les FinTech et HealthTech en particulier, une clé d'API d'IA volée dans un pipeline qui manipulait aussi des données de santé ou des variables d'environnement de paiement constitue un risque cumulé. La clé OpenAI ou Anthropic elle-même vaut peut-être peu, mais le vidage de variables d'environnement qui l'accompagnait peut contenir des mots de passe de bases de production ou des identifiants de services soumis au périmètre PCI DSS.

Plan de remédiation en trois étapes

Si votre organisation utilise LiteLLM et n'a pas encore mené de revue post-incident, priorisez ces trois actions :

1. Auditer les journaux de build sur la fenêtre d'exposition. Recherchez dans les journaux d'artefacts de votre plateforme CI/CD les installations de litellm==1.82.7 ou litellm==1.82.8 le 24 mars 2026, entre environ 10 h 39 et 16 h 00 UTC. Si votre pipeline utilise un cache, vérifiez aussi que des versions mises en cache pendant cette fenêtre n'ont pas été réutilisées dans des builds ultérieurs.

2. Renouveler tous les secrets accessibles aux pipelines concernés. Cela inclut les clés d'API des fournisseurs cloud (AWS, Azure, GCP), les clés d'API des fournisseurs d'IA (OpenAI, Anthropic et tout autre fournisseur dont les identifiants figuraient dans les variables d'environnement), les jetons ServiceAccount Kubernetes, les clés SSH du runner de build et les mots de passe de bases de données accessibles à l'environnement de build. Ne limitez pas la rotation aux secrets que vous pensez avoir été utilisés directement : renouvelez tout ce qui était à la portée du processus Python.

3. Rechercher des indicateurs de persistance. Cherchez dans vos organisations GitHub et GitLab toute référence aux dépôts tpcp-docs ou docs-tpcp. Analysez les journaux réseau des runners de build à la recherche de connexions sortantes vers models.litellm.cloud à partir du 24 mars. Si vous trouvez l'un de ces indicateurs, considérez l'environnement de build concerné comme potentiellement toujours compromis et mobilisez vos capacités de réponse à incident.

Questions fréquentes

Sources

SecurityWeek — Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack, août 2026
The Hacker News — Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations, août 2026
CloudSEK — 2,500+ Companies and 434,000 CI/CD Pipelines Exposed (source primaire), 11 août 2026