Une attaque de chaîne d’approvisionnement liée à l’écosystème autour de LiteLLM a provoqué une large exposition de systèmes de développement. D’après CloudSEK, plus de 2 500 organisations et 430 000 pipelines CI/CD auraient été touchés, suite à la compromission d’un maillon du processus d’intégration et de publication.
L’affaire met en lumière un point clé : lorsqu’un élément malveillant s’insère dans un mécanisme automatisé de build, l’impact peut se propager rapidement, bien au-delà du seul paquet concerné. Voici ce qui est ressorti des informations disponibles et les actions recommandées pour limiter les conséquences.
Ce que révèle l’attaque LiteLLM
CloudSEK rapporte que l’incident a affecté plus de 2 500 organisations et plus de 430 000 pipelines CI/CD. L’extraction des données côté impact s’appuie sur une reconstitution de l’exposition : cela signifie que le nombre correspond à des environnements pouvant avoir été exposés, et non forcément à des compromissions confirmées pour chaque entité.
Le phénomène a été observé plus tôt dans l’année, dans un contexte où d’autres incidents de chaîne d’approvisionnement avaient déjà mobilisé l’attention du secteur. La publication de la compromission de LiteLLM a été faite peu après une attaque visant l’outil open source Trivy.
Le lien avec Trivy et la publication sur PyPI
Selon CloudSEK, l’attaque n’a pas été dirigée spécifiquement contre LiteLLM. L’origine se trouve dans la compromission de la bibliothèque Python open source et du serveur proxy associés à la solution.
Le point critique : après l’installation automatique d’une version de Trivy compromise dans une chaîne CI, des versions de LiteLLM ont été publiées avec des éléments altérés. Deux versions de LiteLLM, 1.82.7 et 1.82.8, auraient notamment été poussées sur PyPI, permettant aux attaquants d’accéder aux informations manipulées par LiteLLM.
CloudSEK décrit la logique en chaîne comme un enchaînement d’étapes où une fuite de crédentiel se transforme en exposition à l’échelle de l’écosystème. Dans ce scénario, Trivy puis le système de build, puis la publication de LiteLLM forment une succession qui amplifie le risque.
Pourquoi l’automatisation rend la propagation plus rapide
Un autre élément revient dans les explications : la rapidité des systèmes de build automatisés. Une fois qu’un artefact malveillant est publié dans un registre, il peut être récupéré par des jobs planifiés, des résolveurs de dépendances, des environnements éphémères, mais aussi des postes de travail des développeurs et des couches mises en cache.
En pratique, cela élargit la “fenêtre” pendant laquelle des données peuvent être exposées. Même si le paquet modifié n’est resté disponible que 40 minutes, ce laps de temps peut suffire à déclencher des séries d’exécutions et de récupérations dans des environnements CI/CD.
Ce que faisait le code malveillant dans LiteLLM
Les versions concernées auraient intégré du code malveillant qui s’exécute à chaque invocation de Python, sans qu’un import explicite soit nécessaire. L’objectif : faire en sorte que, dès que le paquet est installé et appelé, la charge utile puisse se lancer sur les systèmes concernés.
CloudSEK indique que le payload aurait tourné sur tous les environnements où le paquet altéré était installé. Cela signifie que le risque n’est pas limité à une seule opération, mais s’étend aux exécutions répétées liées à l’usage normal de la bibliothèque.
Quelles données sensibles ont pu être exposées
L’impact rapporté par CloudSEK ne se limite pas à un paquet compromis : il concerne aussi une vaste catégorie de secrets potentiellement accessibles via l’exécution du logiciel altéré. Parmi les éléments cités figurent :
- les identifiants de publication de paquets ;
- des clés cloud ;
- des clés SSH ;
- des tokens ;
- des variables d’environnement ;
- des données de runtime ;
- des clés liées à des fournisseurs d’IA.
CloudSEK souligne également que des secrets peuvent se retrouver à différents endroits, par exemple en mémoire du processus, injectés dans le job, stockés sur disque, ou encore récupérables via un service de métadonnées d’instance. Autrement dit : même si un paquet est “retiré”, l’exposition peut continuer pendant les exécutions en cours ou les environnements ayant déjà récupéré l’artefact.
Les conséquences possibles pour les organisations
Une fois des secrets disponibles, les attaquants peuvent tenter plusieurs scénarios : prise de contrôle de comptes, extraction de données, injection de commits malveillants, mise en place de persistance, mouvements latéraux ou encore perturbation de services. Le recours à ces secrets peut aussi faciliter le déploiement de logiciels malveillants et d’autres formes d’attaques.
Il est important de noter la nuance apportée par CloudSEK : les chiffres “2 500+ organisations” et “434 000 pipelines” correspondent à des expositions reconstruite. Ils ne prouvent pas, à eux seuls, qu’une compromission a systématiquement abouti, ni que chaque identifiant a effectivement été volé. Chaque cas doit être confirmé par des vérifications indépendantes.
Des noms d’organisations cités, mais une vérification reste indispensable
La liste publiée par CloudSEK inclut des organisations connues du secteur, parmi lesquelles : Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Accenture Federal Services, Siemens, Regeneron Pharmaceuticals, London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX et Zscaler, entre autres.
Malgré ces mentions, les équipes de sécurité doivent traiter l’incident comme une opportunité de validation et de durcissement : l’objectif est de déterminer si des pipelines ont réellement exécuté les versions concernées et si des secrets ont pu être accessibles.
Que faire après une attaque de chaîne d’approvisionnement comme celle-ci
CloudSEK recommande de considérer tout secret accessible via la bibliothèque comme potentiellement compromis. Ensuite, la démarche doit inclure une validation des identifiants et une rotation des secrets et des sessions, accompagnée d’un contrôle des journaux pour clarifier l’étendue et la chronologie de l’exposition.
Concrètement, les priorités peuvent s’aligner ainsi :
- Identifier si des versions de LiteLLM (notamment celles mentionnées) ont été utilisées dans des pipelines CI/CD ;
- Vérifier les secrets qui auraient pu être accessibles pendant l’exécution ;
- Rotater les clés, tokens et comptes concernés, ainsi que les sessions associées ;
- Analyser les logs pour estimer l’ampleur de l’exposition et la durée réelle de propagation.
Cette approche permet de dépasser la simple suppression d’un paquet et de couvrir les effets induits par la récupération, la mise en cache et les exécutions planifiées.
Vers une cible : l’infrastructure d’IA
Au-delà de l’incident lui-même, CloudSEK estime que la prochaine grande attaque de chaîne d’approvisionnement pourrait viser davantage l’infrastructure liée à l’intelligence artificielle. L’argument : ces systèmes constituent des points de jonction à forte valeur entre les données, l’identité, le calcul et des actions automatisées.
Autrement dit, compromettre un élément de contrôle “dans la chaîne” peut exposer les systèmes qui l’entourent. Dans ce contexte, le risque évolue : il ne s’agit plus seulement d’une fuite logicielle, mais d’une atteinte potentielle aux mécanismes qui orchestrent l’exécution et l’accès aux ressources.
Conclusion
L’attaque LiteLLM décrite par CloudSEK illustre comment une compromission insérée dans une chaîne de build peut se propager très vite, toucher des centaines de milliers de pipelines et exposer divers types de secrets. Même si les versions concernées n’ont été disponibles que brièvement, l’automatisation a pu amplifier l’impact.
La leçon principale est opérationnelle : au lieu de se limiter à la suppression des artefacts, les organisations doivent vérifier les environnements, valider l’accès aux secrets, puis procéder à une rotation et à une analyse approfondie des journaux. C’est à ce prix que l’on peut déterminer l’ampleur réelle et réduire le risque pour l’avenir.
Source: https://www.securityweek.com/over-2500-organizations-impacted-by-litellm-supply-chain-attack/
