Des chercheurs alertent sur un LiteLLM malveillant qui a pu voler des identifiants sur les systèmes l’ayant installé. Deux versions compromises du projet open source ont été publiées sur PyPI pendant une période courte mais critique en mars. Une enquête de CloudSEK, basée sur un grand volume de fichiers capturés, établit des correspondances potentielles avec plus de 2 100 organisations.
Ce qui rend l’affaire particulièrement sensible, c’est la nature des données recherchées : clés cloud, clés SSH, jetons Kubernetes, mots de passe de bases de données et autres secrets présents dans l’environnement. Les experts recommandent aux équipes de ne pas attendre une confirmation “au cas par cas”, mais de faire tourner et révoquer les identifiants susceptibles d’avoir été exposés pendant la fenêtre d’installation.
Deux versions LiteLLM compromises sur PyPI
Selon les informations disponibles, deux versions de LiteLLM—les 1.82.7 et 1.82.8—ont été détectées comme compromises. Le projet indique qu’elles étaient en ligne le 24 mars, entre 10:39 UTC et environ 40 minutes, avant que PyPI ne les mette en quarantaine.
LiteLLM précise toutefois que les utilisateurs doivent considérer comme suspecte toute installation réalisée le jour même jusqu’à 16:00 UTC. Une vérification via PyPI a ensuite confirmé que ces versions ne figuraient plus dans l’historique de publication consultable, tandis que d’autres versions proches restaient disponibles.
Quels secrets ont été visés par le LiteLLM malveillant ?
Les versions piégées étaient conçues pour collecter des informations stockées dans l’environnement d’exécution. Le mécanisme rapporté inclut notamment :
- variables d’environnement contenant des clés d’API,
- clés SSH,
- identifiants cloud,
- jetons Kubernetes,
- mots de passe de bases de données.
Une fois les éléments collectés, les données volées étaient chiffrées puis envoyées vers un domaine contrôlé par l’attaquant. Ce domaine n’a aucun lien avec l’infrastructure du projet lui-même, ce qui a permis d’établir un schéma d’exfiltration distinct.
Pourquoi l’analyse parle de “2 100+ organisations”
CloudSEK affirme avoir obtenu un jeu de données construit à partir d’environ 434 000 fichiers capturés durant l’opération. À partir de ces traces, l’entreprise propose un référencement public permettant de rechercher par nom ou domaine, et de filtrer selon un niveau de confiance.
Chaque entrée du dataset fournit le nom de l’organisation, son domaine, un décompte des secrets potentiellement exposés, un nombre d’exécutions et un libellé de confiance (par exemple High ou Medium).
Il est toutefois important de comprendre la portée exacte : ce n’est pas un chiffre de victimes confirmées. CloudSEK indique que les fichiers proviennent de sources d’intelligence confidentielles et constituent des “butins” et des journaux attribués à la campagne. En clair, les correspondances reflètent une présomption d’exposition basée sur des signaux d’identité, pas la preuve que chaque organisation ait été compromise de manière certaine ni que les identifiants aient forcément été réutilisés.
Confiance “High” vs “Medium” : ce que mesurent les signaux
Pour les correspondances à haute confiance, l’attribution s’appuie sur des identifiants présents dans l’environnement d’un exécuteur CI (runner), notamment l’identité de la machine et des domaines liés au committer légitime. En plus, le domaine propre de l’organisation doit apparaître avant qu’un verdict obtienne le niveau maximal.
À l’inverse, le niveau “Medium” ne bénéficie que d’un mécanisme d’évaluation moins robuste. Des namespaces listés peuvent inclure des entreprises telles que NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens ou X Corp. Mais les auteurs soulignent que ces mentions ne prouvent pas une réutilisation avérée des identifiants volés.
Pour cette raison, les recommandations convergent : rotation des secrets plutôt que l’attente d’une preuve supplémentaire.
Une logique d’attaque supply-chain : lien avec Trivy
Le LiteLLM malveillant s’inscrit dans une campagne plus large de chaîne d’approvisionnement. Les informations disponibles relient l’incident à une opération associée à Trivy, un scanner référencé dans des analyses antérieures.
Dans ce cadre, plusieurs éléments clés sont mentionnés :
- des modifications malveillantes ont été poussées sur des tags de trivy-action,
- une version Trivy 0.69.4 comportant une charge utile dangereuse a été publiée,
- l’écosystème touché est suivi sous une identification de type CVE-2026-33634 et listé comme “exploité connu”.
La chronologie met notamment en évidence que l’accès a pu persister après une rotation incomplète des identifiants. Autrement dit, même si des équipes avaient tenté de corriger l’incident initial, certains secrets pouvaient rester actifs.
Pourquoi certains équipes doivent agir même sans “choisir” LiteLLM
Un point revient dans les recommandations : l’équipe ne doit pas se demander uniquement si elle utilise LiteLLM de manière intentionnelle. Dans ce scénario, la question devient plutôt : un composant a-t-il pu l’installer pendant un processus automatique (agent, framework, orchestration, dépendance transitive non “épinglée”)?
Un exemple précis est rapporté pour la version 1.82.8 : la présence d’un fichier litellm_init.pth, chargé lors du démarrage de l’interpréteur Python. Ainsi, le code malveillant pouvait s’exécuter dès que des processus Python étaient lancés dans l’environnement concerné, même si aucune importation explicite de LiteLLM n’avait été prévue.
Le risque de secrets “longue durée”
Les autorités indiquent que les identifiants volés peuvent rester exploitables tant qu’ils ne sont pas rotatés ou révoqués. Cela inclut des clés statiques, des jetons de publication, ou des éléments copiés pendant la fenêtre où l’accès était possible.
C’est aussi la raison pour laquelle les recommandations sont centrées sur les credentials plutôt que sur l’existence d’une preuve technique que le package a été utilisé. Plusieurs conseils d’acteurs de sécurité insistent également sur le passage à des jetons temporaires au lieu de jetons à longue durée de vie.
Comment identifier une exposition et réduire l’impact
Les équipes qui veulent évaluer leur exposition peuvent s’appuyer sur un plan d’action en trois étapes.
- Contrôler les installations : vérifier si LiteLLM 1.82.7 ou 1.82.8 a été installé durant la fenêtre d’audit autour du 24 mars (10:39 à 16:00 UTC).
- Faire tourner les secrets : remplacer tout identifiant, jeton ou clé pouvant être accessible depuis les systèmes touchés.
- Rechercher des indicateurs dans GitHub : vérifier des organisations GitHub pour des dépôts nommés tpcp-docs ou docs-tpcp. Les analyses indiquent que la recherche par nom exact peut manquer certains cas, car les artefacts peuvent être publiés sous un libellé de type data-
et préfixés de manière spécifique.
Cette approche vise à limiter la surface d’attaque, même lorsque la certitude sur la réutilisation des identifiants n’est pas complète.
Discussions sur la provenance de la publication malveillante
Les comptes publiés divergent sur le “comment” exact de l’arrivée des versions compromises sur PyPI. CloudSEK décrit une chaîne où une construction empoisonnée a été générée et publiée. De son côté, le rapport incident du projet LiteLLM évoque un dépôt direct sur PyPI qui aurait contourné ses workflows officiels. Unit 42, pour sa part, décrit une opération ciblant des tokens de publication après une brèche liée à Trivy.
CloudSEK conteste l’idée de scénarios alternatifs : l’entreprise affirme qu’il s’agit de phases différentes d’une même chaîne d’attaque. Selon ses éléments, un rapport couvre la collecte du credential, tandis que d’autres analyses couvrent l’utilisation pour publier les versions piégées.
Ce que confirment d’autres signalements
Même si les volumes exacts d’exposition ne peuvent pas être assimilés à des victimes formellement confirmées, plusieurs retours renforcent la réalité d’un impact. Checkmarx signale que des credentials obtenus via l’attaque autour de Trivy auraient permis un accès non autorisé à des dépôts GitHub et la publication d’artefacts malveillants. Mercor rapporte également un effet lié aux versions LiteLLM compromis, incluant des activités non autorisées.
Parallèlement, CERT-EU a évalué avec un niveau élevé de confiance qu’un compte AWS associé à la Commission européenne a été compromis via l’attaque supply-chain, avec environ 91,7 Go de données comprimées exfiltrées.
Conclusion : agir vite pour neutraliser le LiteLLM malveillant
Le LiteLLM malveillant documenté ici montre à quel point une courte fenêtre de publication sur une plateforme peut créer des conséquences longues. Les analyses liant l’incident à l’écosystème Trivy renforcent l’idée qu’il faut considérer les dépendances et les pipelines CI/CD comme des composants à surveiller en continu.
En pratique, la meilleure protection consiste à identifier les installations potentiellement effectuées pendant la fenêtre du 24 mars, puis à faire tourner et révoquer tout secret exposé. Cette action réduit rapidement le risque, même si les correspondances d’attribution restent “probables” plutôt que parfaitement prouvées pour chaque organisation.
Source: https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
