La Brèche de la Chaîne d'Approvisionnement LiteLLM : 153 Go de Données d'Identification Fuitées chez Plus de 2 500 Organisations

Une fenêtre de 40 minutes. C'est tout ce qu'il a fallu.

Le 24 mars 2026, deux versions empoisonnées de LiteLLM — le populaire gateway open source pour l'IA — sont restées sur PyPI pendant moins d'une heure. Dans cette petite fenêtre, le malware a silencieusement balayé la mémoire, récolté chaque secret qu'il pouvait trouver et exfiltré le butin vers un serveur contrôlé par les attaquants. Des mois plus tard, une archive de 153 Go contenant les données volées a fait surface, et l'ampleur est stupéfiante : AWS, Samsung, Cisco, NVIDIA, Salesforce, Siemens, Deloitte, FedEx, Volkswagen, Epic Games et plus de 2 480 organisations ont vu leurs données d'identification exposées.

C'est la plus grande brèche de la chaîne d'approvisionnement d'infrastructure IA de 2026. Et les données d'identification fonctionnent toujours.

Qu'est-ce que LiteLLM ?

LiteLLM est une bibliothèque Python open source qui agit comme un gateway unifié entre les applications et les fournisseurs de modèles de langage de grande taille. Au lieu d'écrire des intégrations personnalisées pour OpenAI, Anthropic, Google et des dizaines d'autres fournisseurs, les développeurs intègrent LiteLLM dans leur stack et obtiennent une interface unique. Il est installé des milliers de fois par jour dans les pipelines CI/CD, les environnements de développement et les systèmes de production.

Cette ubiquité est exactement ce qui en a fait un vecteur d'attaque si dévastateur.

Comment l'attaque s'est produite

Le compromis de LiteLLM faisait partie d'une campagne plus large de la chaîne d'approvisionnement orchestrée par TeamPCP — un groupe de menaces informel mais extrêmement capable, composé en grande partie d'adolescents, selon les chercheurs en sécurité. Google les suit sous le nom UNC6780.

Leur playbook était élégant dans sa simplicité :

1. Compromettre le jeton de publication. Les attaquants ont obtenu une credential de publication PyPI pour LiteLLM, probablement via la précédente brèche de la chaîne d'approvisionnement Trivy (CVE-2026-33634), qui leur a donné un accès force-push à plusieurs dépôts.

2. Pousser des paquets empoisonnés. Le 24 mars, les versions 1.82.7 et 1.82.8 sont apparues sur PyPI. Elles contenaient un fichier appelé litellm_init.pth — un hook de démarrage Python qui s'exécute automatiquement lorsque l'interpréteur Python s'initialise, que vous importiez LiteLLM explicitement ou non.

3. Tout récolter. Le malware a balayé la mémoire et les configurations de l'environnement actif à la recherche de clés SSH, de credentials AWS/GCP/Azure, de jetons Kubernetes, de mots de passe de bases de données, de fichiers .env, de clés API LLM (y compris OPENAI_API_KEY et ANTHROPIC_API_KEY) et de configuration du gateway.

4. Exfiltrer et disparaître. Les données ont été chiffrées et envoyées à models.litellm[.]cloud — un domaine contrôlé par les attaquants sans rapport avec le projet légitime. PyPI a mis les paquets en quarantaine après environ 40 minutes.

L'astuce du fichier .pth est particulièrement vicieuse. Python traite ces fichiers au démarrage de l'interpréteur, ce qui signifie que le code malveillant s'exécutait dans tout processus Python de l'environnement affecté — pas seulement dans les sessions LiteLLM. Un seul pipeline CI compromis pourrait fuiter chaque secret accessible à ce runner.

Le rayon d'explosion

CloudSEK et Hudson Rock ont obtenu et analysé indépendamment une archive RAR de 153 Go contenant 433 909 fichiers. L'analyse a attribué 118 829 dumps de CI runner à 2 488 domaines d'entreprise affectés, impactant 434 000 pipelines CI/CD.

La liste d'exposition à haute confiance ressemble à un annuaire Fortune 500 :

• Technologie : AWS, NVIDIA, Cisco, Samsung, Salesforce, ServiceNow, Zscaler, NGINX
• Entreprise : Siemens, S&P Global, Deloitte, Thomson Reuters, Munich Re
• Industrie : Airbus, John Deere, FedEx, Volkswagen, Deutsche Bahn
• Finance : London Stock Exchange Group, Krungthai Bank
• Médias & Divertissement : Epic Games, X Corp, SiriusXM
• Télécommunications : Vodafone, BT Group, Orange
• Autre : Philips, HP, Thales, Carl Zeiss, Regeneron, Kroger

Le chercheur en sécurité indépendant Kevin Beaumont a confirmé que les données sont légitimes et a testé des credentials du dump des mois après l'attaque. Le résultat ? Presque toutes fonctionnaient encore. L'une des plus grandes entreprises technologiques américaines lui avait assuré avoir roté toutes les credentials affectées. Elles ne l'avaient pas fait.

Pourquoi c'est important pour l'infrastructure IA

Cette brèche expose un angle mort fondamental dans la façon dont les organisations adoptent les outils IA :

Les gateways IA se trouvent à l'intersection la plus privilégiée des stacks modernes. Ils touchent simultanément les données, l'identité, le calcul et l'action autonome. Ils détiennent des clés API pour chaque fournisseur de modèles, se connectent à l'infrastructure cloud et s'exécutent souvent avec de larges permissions IAM. Un seul gateway compromis ne fuit pas un secret — il fuit tous les secrets.

Les dépendances open source IA multiplient les surfaces d'attaque. LiteLLM peut être tiré comme dépendance transitive par des frameworks d'agents, des outils d'orchestration ou des scripts CI/CD qui ne l'ont jamais explicitement choisi. Si quelque chose sur votre hôte l'a installé, vous êtes dans le périmètre — que votre équipe le sache ou non.

La culture de rapidité-mise-en-production autour de l'IA dépasse la sécurité. Comme l'a dit Beaumont : "C'est une brèche massive de la chaîne d'approvisionnement due à une mauvaise sécurité de l'IA — pas parce que l'IA est la menace, mais parce que des adolescents peuvent faire des cercles autour d'organisations obsédées par le déploiement rapide de l'IA et une mauvaise sécurité DevOps."

Le FBI s'exprime

En juillet 2026, le FBI a émis l'avis FLASH-20260702-01 avertissant que les affiliés de TeamPCP sont susceptibles d'armer les credentials volées longtemps après le compromis initial. Le bureau a exhorté les organisations à faire tourner les secrets CI/CD, les jetons de publication et toutes les credentials cloud accessibles pendant la fenêtre d'exposition.

L'avis a spécifiquement souligné le passage des jetons de longue durée aux credentials temporaires — un mouvement qui aurait considérablement limité le rayon d'explosion de cette brèche.

Ce que vous devriez faire maintenant

Si votre organisation utilise LiteLLM — ou toute infrastructure IA qui en dépend — voici le playbook :

1. Recherchez les versions compromises. Recherchez dans votre environnement les versions LiteLLM 1.82.7 et 1.82.8. Toute installation le 24 mars 2026 (jusqu'à 16h00 UTC) doit être traitée comme compromise.

2. Effectuez une rotation agressive. Ne vous contentez pas de faire tourner la clé LiteLLM ou du fournisseur de modèles. Considérez que tout secret accessible au processus affecté est compromis : clés IAM AWS/GCP/Azure, jetons de compte de service Kubernetes, PATs GitLab/GitHub, mots de passe de bases de données, clés SSH.

3. Auditez la persistance. Recherchez les cron jobs inattendus, les services systemd, les connexions SSH inversées ou les événements push non autorisés dans vos dépôts.

4. Implémentez le filtrage egress réseau. Restreignez le trafic sortant des runners CI/CD pour empêcher l'exfiltration de données même si un paquet est compromis.

5. Passez à des jetons de courte durée. Remplacez les clés API de longue durée et les jetons de publication par des credentials temporaires (fédération basée sur OIDC, PATs de courte durée, runners éphémères).

6. Épinglez vos dépendances. Utilisez des lockfiles et vérifiez les hash d'intégrité des paquets. Ne laissez pas les dépendances transitives non épinglées introduire des paquets empoisonnés.

Points clés

• 40 minutes d'exposition en mars ont conduit à la fuite de credentials de plus de 2 500 organisations dans une archive de 153 Go
• Le malware utilisait un hook de démarrage .pth — il s'exécutait à chaque initialisation de Python, même sans importer LiteLLM
• 434 000 pipelines CI/CD ont vu leurs credentials récoltées ; beaucoup restent valides des mois plus tard
• Les attaquants (TeamPCP / UNC6780) ont obtenu l'accès grâce à une rotation incomplète des credentials dans la brèche Trivy associée
• L'infrastructure IA se situe à l'intersection des données, de l'identité et du calcul — en faisant la cible de plus grande valeur dans les chaînes d'approvisionnement modernes
• Le FBI avertit que les credentials volées continueront d'être armées ; les organisations doivent effectuer une rotation et passer à des jetons de courte durée immédiatement

La brèche LiteLLM n'est pas seulement l'histoire d'un paquet compromis. C'est un aperçu de la façon dont les attaques de la chaîne d'approvisionnement évolueront à mesure que les outils IA deviendront le tissu conjonctif des logiciels d'entreprise. La question n'est pas de savoir si votre organisation fera face à quelque chose comme ça — c'est de savoir si vous l'attraperez en 40 minutes, ou si vous le découvrirez des mois plus tard dans une archive publique.