La brèche LiteLLM a exposé 434 000 pipelines CI/CD, et le maillon faible était un scanner de vulnérabilités

Mars 2026. Le groupe TeamPCP orchestre une compromission de LiteLLM, passerelle open source qui fédère des centaines de fournisseurs de modèles LLM, en passant par le scanner de vulnérabilités Trivy qu’installe son propre pipeline. 11 août 2026. CloudSEK publie le décompte reconstruit de l’exposition : plus de 2 500 organisations et 434 000 pipelines CI/CD dans le monde. Juillet 2026. Le FBI diffuse un avis FLASH avertissant que les credentials dérobés seront probablement réutilisés bien après l’intrusion initiale.

Pour une équipe plateforme, la conclusion tient en une phrase : une fenêtre de publication de 40 minutes sur PyPI s’est transformée en incident de plusieurs mois, parce que le code malveillant s’exécutait sans import explicite et que les pipelines tournaient avec des privilèges qui n’auraient jamais dû les accompagner.

Une chaîne de trois outils, un seul token non révoqué

LiteLLM n’a jamais été attaqué directement. Le récit de CloudSEK décrit une cascade précise : le processus de release de LiteLLM installait le scanner Trivy depuis le gestionnaire de paquets système, sans épingler la version. Un token d’automatisation fuité, tourné mais pas complètement révoqué, a laissé une fenêtre d’environ 20 jours pendant laquelle l’attaquant a force-pushé du code malveillant par-dessus les tags de version publiés du scanner.

Les builds qui tiraient ces tags ont donc reçu un scanner empoisonné qui paraissait légitime. Ce scanner compromis a coulé dans le build de LiteLLM, et ce build a produit et publié les versions 1.82.7 et 1.82.8 sur PyPI. Trivy, puis le système de build, puis la release LiteLLM : un seul token non révoqué, trois outils plus loin. C’est cette chaîne qui transforme une fuite de credential unique en exposition à l’échelle de l’écosystème.

Le vecteur d’exécution est la pièce la plus instructive. Le payload reposait sur un fichier .pth, qui s’exécute au démarrage de l’interpréteur Python, pas à l’import. Résultat : le code malveillant tournait sur toute machine où le paquet était simplement installé, même sans import de LiteLLM dans le code. Il contournait au passage la protection --ignore-scripts sur laquelle beaucoup d’équipes comptent pour sécuriser leurs installations.

Ce que le voleur a ramassé

Sur chaque runner CI compromis, le voleur — suivi par Google sous le nom SANDCLOCK — passait root et balayait méthodiquement : clés SSH, credentials AWS, GCP et Azure, tokens Kubernetes, fichiers .env et secrets CI/CD, y compris les valeurs que GitHub Actions tente de masquer, lues directement dans /proc/<pid>/mem. Pour les builds d’IA en particulier : les clés d’API LLM et la configuration des passerelles — autrement dit les credentials de toute la pile d’IA d’une organisation.

Les clés cloud étaient lues depuis le service de métadonnées d’instance (IMDS) et les tokens Kubernetes depuis les chemins de service accounts montés — sans exploit, juste avec l’accès que chaque runner portait déjà. Le butin était chiffré en AES-256 sous une clé RSA-4096 codée en dur, puis expédié vers un domaine typosquatté. Là où l’exfiltration échouait, le malware créait un dépôt public dans le compte GitHub de la victime et y déposait les données volées en tant qu’asset de release : certaines organisations fuyaient ainsi leurs propres secrets en public, sans le savoir.

La liste des organisations à forte confiance publiée par CloudSEK force le respect : AWS, Samsung, Salesforce, Cisco, ServiceNow, Siemens, Airbus, X Corp, Zscaler, Epic Games, Orange, Vodafone, NGINX, Deutsche Bahn, FedEx, Volkswagen. CloudSEK insiste sur un point de méthode : ces chiffres décrivent une exposition reconstruite, pas la preuve que chaque organisation a été effectivement compromise.

Une fenêtre de 40 minutes, un incident de plusieurs mois

Le paquet malveillant n’est resté en ligne que 40 minutes. C’est la durée qui a suffi pour que les systèmes automatisés — jobs planifiés, résolveurs de dépendances, runners éphémères, postes développeurs, couches de cache — copient l’artefact à la vitesse de la machine. CloudSEK en tire la conséquence que le retrait d’un paquet ne clôt pas l’incident : un artefact disparaît en minutes, mais des credentials copiés restent utilisables des semaines ou des mois s’ils ne sont pas révoqués.

C’est le point que les équipes SRE et plateforme doivent intégrer. La rotation d’un seul token — la clé LiteLLM ou du fournisseur de modèles — ne suffit pas. Tout credential lisible par le processus affecté, présent en mémoire, injecté dans le job, stocké sur disque ou récupérable via un service de métadonnées doit être traité comme potentiellement exposé jusqu’à validation. Le périmètre de rotation est donc le runner entier, pas le paquet.

Une note d’honnêteté s’impose sur l’attribution. SOCRadar a depuis contesté une partie du décompte : la majorité des 2 500 organisations auraient en réalité été touchées plus tôt, via l’incident Trivy lui-même. La nuance ne change pas la leçon d’ingénierie — elle la renforce : les deux incidents sont deux étages de la même cascade, et la frontière entre « victime de Trivy » et « victime de LiteLLM » est moins nette que les comptages le suggèrent.

Ce qu’il faut corriger dans le CI

La compromission de LiteLLM est un manuel d’anti-patterns CI/CD, et chaque étape pointe une décision d’ingénierie réversible.

Épingler les dépendances de build. Le scanner a coulé dans le build parce qu’il était installé non épinglé depuis apt. Un outil de sécurité est une dépendance comme une autre : il se versionne, il s’épingle, il se vérifie par hash. Le verrouillage au niveau du workflow — l’équivalent d’un go.sum pour vos actions — est la réponse structurelle que GitHub prépare pour Actions, mais elle vaut pour tout pipeline : conteneurs de build, scanners, runners.

Révoquer, pas seulement tourner. Le token « tourné mais pas complètement révoqué » est le pivot de toute l’attaque. La rotation sans révocation laisse les anciens credentials actifs — c’est exactement la fenêtre de 20 jours exploitée ici. Une compromission de credential impose la révocation, puis la rotation, dans cet ordre.

Scoper les secrets. Le voleur n’a eu besoin d’aucun exploit : il a lu les credentials que le runner portait déjà. Le moindre privilège sur le GITHUB_TOKEN, l’absence de clés cloud permanentes sur les runners, et des service accounts Kubernetes restreints auraient mécaniquement réduit la récolte.

Traiter le CI comme une surface d’attaque. Un runner exécute du code non vérifié, manipule des secrets et parle à l’extérieur. Il mérite la même surveillance que la production : télémétrie d’exécution, pare-feu de sortie, et la capacité de corréler une requête réseau à un job précis.

Verdict

Si vos pipelines installent des paquets Python, commencez par deux vérifications immédiates : vos scanners et outils de build sont-ils épinglés par hash, et vos runners ont-ils des clés cloud permanentes ? La brèche LiteLLM montre que la réponse « non » à l’une ou l’autre est une exposition en attente, pas un risque théorique.

Si vous tournez un parc de runners ou de pipelines, appliquez la règle du runner entier : en cas de compromission d’une dépendance, considérez comme exposé tout credential accessible au processus — mémoire, disque, IMDS, service accounts — et révoquez large, pas étroit.

La règle à retenir : dans une supply chain logicielle, votre scanner de sécurité est lui-même une dépendance. Trivy a été le maillon faible qui a fait tomber LiteLLM, qui a exposé 434 000 pipelines. Le premier composant à vérifier dans un pipeline, c’est celui qui est censé vérifier les autres.

Références

• LiteLLM Supply Chain Attack: 2,500+ Companies Exposed in the Largest AI Supply Chain Breach of 2026 — CloudSEK, 11 août 2026
• Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack — SecurityWeek
• TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure — Palo Alto Networks Unit 42, 31 mars 2026
• Cyber Criminal Group TeamPCP, FLASH-20260702-01 — FBI, 2 juillet 2026