# Quarante minutes de compromission, 434 000 chaînes de production exposées

> Une version piégée du paquet open source LiteLLM a siphonné les secrets de 2 500 organisations. Orange, Thales, Airbus, Volkswagen et Deloitte figurent sur la liste à haute confiance.

- Source : KLYNLABS (https://klynlabs.eu)
- URL : https://klynlabs.eu/articles/quarante-minutes-de-compromission-434000-chaines-exposees
- Auteur : Kelvyn
- Publié le : 16 août 2026 (2026-08-16T07:00:00.000Z)
- Mis à jour le : 16 août 2026 (2026-08-16T17:47:53.129Z)
- Rubrique : Cybersécurité
- Sujets : Chaîne d'approvisionnement, Open source, LiteLLM, DevOps
- Langue : français

Des téraoctets d'identifiants appartenant à certaines des organisations les plus sensibles au monde ont été exposés lors d'une attaque contre **LiteLLM**, un outil open source qui simplifie le développement logiciel assisté par IA. Les révélations viennent des sociétés de sécurité CloudSEK et Hudson Rock.

Le détail qui donne le vertige : la fenêtre d'exposition a duré **quarante minutes**, en mars, pendant que des développeurs téléchargeaient les versions piégées depuis l'emplacement officiel du paquet sur PyPI, le dépôt Python de référence.

## Ce qui a fuité

CloudSEK décrit un inventaire complet de ce qui fait tourner une organisation moderne :

- clés cloud et variables d'environnement ;
- jetons de dépôts de code et identifiants de publication de paquets ;
- clés SSH et secrets Kubernetes ;
- clés d'accès aux fournisseurs d'IA.

Au total, les deux sociétés estiment que **434 000 chaînes d'intégration et de déploiement continus** ont vu leurs identifiants exposés. Hudson Rock dit avoir fait la découverte en analysant un fichier de 195 téraoctets, dont aucune des deux sociétés n'a identifié la provenance.

## Qui est concerné

Les chercheurs disent avoir une confiance élevée sur une liste d'organisations qui comprend, entre autres, Nvidia, Amazon Web Services, Samsung, Salesforce, Cisco, Siemens, Airbus US Space & Defense, la London Stock Exchange Group, FedEx, Volkswagen, Deloitte, Thales, X Corp, Epic Games, HP, Philips, Vodafone, Deutsche Bahn, BT Group, Roku — et **Orange**.

Un exemple montre la difficulté de l'exercice d'attribution. Une adresse en @siriusxm.com trouvée dans les données ne signalait pas une brèche chez le diffuseur satellite, mais chez AdsWizz, sa filiale. Hudson Rock résume le problème :

> Beaucoup de chaînes CI/CD sont configurées de manière générique. Les variables extraites contiennent des mots de passe de bases de données actifs, des clés d'API tierces et des identifiants cloud sans aucun e-mail d'entreprise identifiable, chaîne de domaine personnalisée ou nom de serveur interne. Cela signifie qu'un nombre incalculable d'organisations ont actuellement des secrets actifs dans cette base, sans avoir la moindre idée de leur exposition.

## Une attaque en cascade

LiteLLM n'était pas la cible initiale. Sa compromission découle d'une attaque antérieure contre **Trivy**, un scanner de vulnérabilités très répandu. Les paquets KICS et le SDK Python de Telnyx figurent aussi parmi les logiciels infectés dans la même campagne, revendiquée par un groupe nommé TeamPCP — largement composé d'adolescents, selon les chercheurs, qui ont pour l'essentiel corroboré la revendication.

Dans les quatre paquets, le code ajouté lisait la mémoire des machines infectées, en aspirait le contenu et l'exfiltrait par un canal contrôlé par les attaquants.

> Un détail mérite d'être médité par toute équipe qui gère des secrets : les développeurs de Trivy ont bien fait tourner un jeton d'automatisation, mais sans le révoquer complètement pendant vingt jours. Cette fenêtre a laissé aux attaquants près de trois semaines pour pousser du code malveillant dans des compilations tierces. Faire tourner un secret sans révoquer l'ancien ne sert à rien.

## Ce qu'il faut faire

Hudson Rock demande à toute organisation utilisant une infrastructure de proxy IA, des scanners de vulnérabilités CI/CD tiers ou des paquets IA en aval d'auditer immédiatement son environnement à la recherche des versions **1.82.7 et 1.82.8** de LiteLLM. Les recommandations sont sans ambiguïté :

- révocation agressive des identifiants, pas seulement leur rotation ;
- considérer comme compromis tout secret accessible depuis l'environnement LiteLLM ;
- invalider et faire tourner toutes les clés cloud, les jetons de comptes de service Kubernetes et les jetons d'accès personnels GitLab et GitHub ;
- auditer la journalisation et le filtrage des flux sortants.

## Le réflexe de déni

Le chercheur indépendant Kevin Beaumont a confirmé l'authenticité des données auprès de plusieurs organisations victimes. Il rapporte surtout un épisode qui en dit long sur la réponse du secteur : une des entreprises touchées lui a affirmé avoir tout fait tourner et qu'il n'y avait « rien à signaler ». Sa politique de divulgation autorisant le test d'identifiants, il les a essayés.

> Presque tous ont fonctionné. Rapport soumis. L'une des plus grandes entreprises technologiques américaines.

Son analyse de fond vaut d'être citée : « Ce n'est pas une brèche massive de la chaîne d'approvisionnement parce que l'IA est la menace, mais parce que des adolescents peuvent tourner autour d'organisations obsédées par la sortie précipitée de fonctions d'IA, avec une sécurité DevOps médiocre. »

## À retenir

- Une fenêtre de quarante minutes en mars a suffi à exposer les secrets de 2 500 organisations.
- 434 000 chaînes CI/CD concernées ; les versions piégées venaient du dépôt PyPI officiel.
- La compromission de LiteLLM découle d'une attaque antérieure contre le scanner Trivy, dont un jeton a été tourné mais pas révoqué pendant vingt jours.
- Orange, Thales, Airbus, Volkswagen et Deloitte figurent sur la liste à haute confiance.
- Beaucoup de secrets exposés ne portent aucun nom d'entreprise : des organisations sont concernées sans le savoir.

## Source

Ars Technica, [« Terabytes of credentials leaked in massive supply-chain attack »](https://arstechnica.com/security/2026/08/terabytes-of-credentials-leaked-in-massive-supply-chain-attack/), par Dan Goodin, 12 août 2026, à partir des publications de CloudSEK et Hudson Rock.

---

Article publié par KLYNLABS, signé Kelvyn. À citer avec son lien : https://klynlabs.eu/articles/quarante-minutes-de-compromission-434000-chaines-exposees