LiteLLM : une attaque de la supply chain expose les identifiants de milliers d’organisations

Des versions malveillantes publiées sur PyPI

Une attaque de la supply chain visant LiteLLM, une passerelle open source destinée aux applications basées sur l’intelligence artificielle, aurait entraîné la distribution de la backdoor SANDCLOCK et l’exposition de nombreux identifiants opérationnels.

L’opération est attribuée au groupe TeamPCP, qui aurait, selon les éléments disponibles, dérobé les identifiants des administrateurs du projet. Les attaquants auraient ensuite publié sur PyPI les versions compromises 1.82.7 et 1.82.8, aux alentours de mars 2026.

La fenêtre d’exposition pourrait donc avoir duré au moins plusieurs mois. Certaines organisations pourraient ne pas avoir encore détecté l’installation du composant altéré ni l’utilisation ultérieure des identifiants volés.

LiteLLM est utilisé comme bibliothèque et couche d’intégration pour acheminer les requêtes vers plus d’une centaine de fournisseurs de modèles de langage. Les environnements compatibles incluent notamment OpenAI, Anthropic, Google Gemini ainsi que les modèles locaux gérés via Ollama.

La compromission d’un composant installé dans des pipelines automatisés peut considérablement élargir le périmètre de l’attaque. Il n’est pas nécessaire de viser directement chaque entreprise : il suffit d’insérer du code malveillant dans un élément partagé par de nombreuses applications et processus de développement.

SANDCLOCK et le parcours potentiel des identifiants

Le brief disponible identifie SANDCLOCK comme une backdoor, mais ne décrit pas son fonctionnement interne et ne précise pas quelles données elle collecte directement ni vers quelles infrastructures elle les exfiltre.

L’élément le plus important réside dans le contexte d’exécution de LiteLLM. Le logiciel peut être présent dans des environnements de développement, des systèmes d’intégration et de déploiement continus, des outils d’automatisation et des services qui doivent s’authentifier auprès de fournisseurs cloud ou d’API d’intelligence artificielle.

Dans ces conditions, un package altéré peut accéder aux variables d’environnement, aux fichiers de configuration et aux secrets utilisés par les pipelines. Les identifiants potentiellement exposés comprennent :

• des clés pour les infrastructures AWS, GCP et Firebase ;
• des tokens pour des registres tels qu’Amazon ECR et JFrog ;
• des tokens d’accès personnels GitHub, ou PAT ;
• des clés privées de GitHub App ;
• des identifiants SSH ;
• des secrets de clusters Kubernetes ;
• des mots de passe de signature ;
• des clés API pour des services d’IA, notamment celles d’OpenAI et d’Anthropic.

Un tel accès peut permettre de consulter ou de modifier des dépôts, de manipuler des pipelines de build et de déploiement, d’atteindre des registres d’images ou de packages et d’intervenir sur des infrastructures cloud. En présence de privilèges élevés, le risque peut s’étendre aux clusters Kubernetes et aux services qu’ils hébergent.

On ignore si tous les identifiants collectés ont été utilisés dans le cadre d’activités ultérieures. Leur simple exposition impose toutefois de les révoquer et de les remplacer : il ne suffit pas de supposer qu’une clé n’a pas été exploitée.

L’ampleur de l’exposition

Resecurity a analysé une archive de 150 Go attribuée aux activités de TeamPCP. Les fichiers owners.txt et repos.txt qu’elle contient feraient apparaître 898 propriétaires GitHub distincts, organisations et comptes confondus, répartis sur 2 038 dépôts.

La compromission est fragmentée : 631 propriétaires ne posséderaient qu’un seul dépôt dans la liste. L’entité comptant le plus grand nombre de dépôts concernés serait Cencosud-Cencommerce, avec 64 dépôts.

Parmi les noms recensés figurent Microsoft, Azure, IBM, NVIDIA, PayPal (Zettle), Deloitte, Bosch, S&P Global, Elevance Health, 84.51° (Kroger), Adeo (Leroy Merlin), Kärcher, Dräger, ID.me et 1inch.

Resecurity a recensé 2 146 enregistrements à partir des noms des clés. Les valeurs n’auraient pas été examinées au-delà du masquage structurel ; ce chiffre correspond donc aux éléments identifiés dans l’archive, et non nécessairement à des identifiants encore valides ou utilisés avec succès.

Selon cette analyse, l’incident aurait touché plus de 2 500 organisations et des centaines de milliers d’environnements CI/CD. L’écart entre le nombre total d’organisations et celui des propriétaires GitHub répertoriés peut s’expliquer par la structure des données analysées et les critères de recensement utilisés.

Les secteurs technologique, financier et de la santé parmi les plus exposés

Le secteur le plus représenté est celui de la technologie et des logiciels, où l’utilisation d’outils open source et de pipelines automatisés est particulièrement répandue.

Viennent ensuite les banques, la finance et l’assurance, puis la santé, l’industrie pharmaceutique et les medtech. La présence d’organisations réglementées accroît l’importance de l’incident : une compromission peut affecter la continuité d’activité, la protection des données et les obligations liées à la gestion des accès.

Les autres secteurs identifiés sont :

1. la distribution et le commerce en ligne ;
2. les médias, le gaming et l’adtech ;
3. l’industrie et la manufacture ;
4. les services professionnels ;
5. la cybersécurité ;
6. les cryptomonnaies ;
7. le secteur public.

Le risque réel dépend des privilèges accordés à LiteLLM et des pipelines dans lesquels le package a été installé. Un environnement de test isolé n’a pas le même impact qu’un runner CI/CD autorisé à publier des images, à mettre à jour des infrastructures ou à déployer des applications en production.

L’attaque peut également allonger le délai de détection de l’incident. Le malware a pu être exécuté dans de nombreux environnements aux configurations différentes, compliquant la corrélation des événements et augmentant à la fois le MTTD, le délai moyen de détection, et le MTTR, le délai moyen de réponse et de rétablissement.

Les vérifications à lancer immédiatement

Les organisations ayant installé LiteLLM doivent rechercher les versions 1.82.7 et 1.82.8 dans les projets, les images de conteneurs, les caches des gestionnaires de packages et les runners CI/CD. Il faut également contrôler les installations indirectes via des dépendances ou des images préconfigurées.

En cas de présence avérée ou de doute, la réponse doit notamment inclure :

• la révocation et la régénération des clés privées des GitHub App ;
• le remplacement des PAT et des tokens GitHub ;
• la rotation des identifiants AWS, GCP et Firebase ;
• la révocation des tokens ECR et JFrog ;
• le remplacement des clés SSH ;
• le changement des mots de passe de signature ;
• la régénération des clés API des fournisseurs d’IA ;
• l’invalidation des sessions actives.

La rotation doit commencer par les comptes disposant de privilèges d’administration et par les secrets utilisés dans les processus de build et de déploiement. Les nouvelles valeurs ne doivent pas être réinjectées dans des pipelines qui n’ont pas encore été vérifiés.

La phase suivante consiste à analyser les journaux GitHub, les runners CI/CD, les registres, les fournisseurs cloud et les clusters Kubernetes. Il faut rechercher les accès inhabituels, la création de tokens, les modifications de workflows, les nouvelles clés SSH, la publication inattendue de packages ou d’images et les déploiements ne correspondant pas aux opérations habituelles.

Aucune indication ne fait état d’une inscription de l’incident dans le catalogue KEV de la CISA ni d’une échéance associée pour sa correction. Les informations disponibles ne mentionnent pas non plus d’identifiant CVE.

Les organisations ayant installé LiteLLM pendant la période concernée doivent considérer les identifiants présents dans leur environnement comme potentiellement exposés, même en l’absence d’indicateurs immédiats d’abus. La compromission d’une dépendance logicielle peut laisser des traces dans les systèmes en aval longtemps après la publication du package malveillant.