Fuite de clé maître LiteLLM : anatomie d'une attaque par chaîne d'approvisionnement

En octobre 2026, une simple erreur de configuration survenue cinq mois plus tôt a permis à un attaquant de compromettre la chaîne d’approvisionnement de LiteLLM, une passerelle open source pour modèles de langage. Cette attaque par chaîne d’approvisionnement illustre avec une acuité particulière les dangers d’une gestion laxiste des secrets et des tokens d’authentification dans les environnements CI/CD. Alors que les incidents de ce type se multiplient - +700 % en trois ans selon le rapport 2025 de Sonatype -, le cas LiteLLM devient un cas d’école pour toute équipe de développement soucieuse de sa sécurité.

Selon les informations publiées par l’équipe de LiteLLM, l’attaquant a exploité une clé maître non révoquée pour s’introduire dans la plateforme d’orchestration d’agents, y dérober un token OAuth GitHub aux droits d’organisation, puis détourner le pipeline de publication. La version malveillante 1.107.0, publiée sur PyPI le 21 octobre 2026, contenait un module de vol de credentials et une backdoor Unix. Cet article détaille chaque étape de la compromission et en tire des leçons actionnables pour sécuriser vos propres chaînes d’approvisionnement.

L’origine de la brèche : un commit accidentel et une révocation oubliée

Le 27 mai 2026, un fichier de configuration est commité dans le dépôt public LiteLLM-Labs/lite-harness. Ce fichier contient, par inadvertance, la master key d’un déploiement de la plateforme Agent Platform de LiteLLM, un outil interne d’orchestration d’agents. L’erreur est rapidement identifiée par l’équipe, le commit est force-pushé (réécrit) et les clés exposées sont marquées comme à révoquer. Mais la révocation effective n’a jamais eu lieu.

Le détail de la fuite

La configuration commitée donnait accès à une clé maître permettant de contrôler l’intégralité de la plateforme Agent Platform. Celle-ci était utilisée par LiteLLM pour orchestrer des agents cloud capables de soumettre des pull requests sur les dépôts GitHub de l’organisation. Or, le token OAuth GitHub intégré à cette plateforme n’était pas restreint (non scoped down) : il était associé au propriétaire de l’organisation GitHub, ce qui conférait un accès de niveau owner à tous les dépôts.

« L’erreur a été rapidement identifiée, le commit a été force-pushé, et les clés exposées ont été marquées comme nécessitant une révocation. Cependant, la révocation n’a pas eu lieu pour la clé maître. » - Oliver Jensen & Mateo Wang, LiteLLM

L’absence de révocation, une faille critique

Ce défaut de révocation est le point de départ de toute la chaîne d’attaque. La non-révocation d’un secret exposé est un problème récurrent en sécurité des systèmes : une clé ou un token qui a fuité, même brièvement, doit être considéré comme compromis et immédiatement remplacé. Dans le cas présent, l’attaquant a eu une fenêtre de cinq mois pour découvrir et exploiter cette clé maître. Ce délai montre que la détection seule ne suffit pas : la procédure de révocation doit être automatisée et immédiate.

La chaîne d’attaque déroulée

Le 10 octobre 2026, l’attaquant (opérant depuis l’adresse 69.48.229[.]143) utilise la clé maître non révoquée pour accéder à la plateforme Agent Platform. Il y extrait le token OAuth GitHub associé - un jeton d’accès de niveau owner. Dès lors, il possède un contrôle total sur tous les dépôts de l’organisation BerriAI.

L’exfiltration des tokens GitHub

Entre le 10 et le 12 octobre 2026, l’attaquant crée deux branches temporaires nommées ci-tmp-<hex> dans les dépôts BerriAI/litellm et BerriAI/litellm-auto. Chaque branche contient un unique commit ajoutant un fichier .github/workflows/cache.yml. Ces workflows sont conçus pour récolter et exfiltrer des secrets vers des endpoints webhook.site :

• Workflow du 10 octobre : token GitHub OAuth de deux ingénieurs, clés API de Linear, tokens Together AI, identifiant et clé de signature d’une GitHub App.
• Workflow du 12 octobre : en plus des précédents, clés API pour Anthropic, OpenAI, AWS Bedrock, Tavily, et clé API GitGuardian - le service de détection de secrets utilisé par LiteLLM. L’attaquant a ainsi pu désactiver les alertes qui auraient pu révéler l’intrusion.

« Un token GitHub et une clé privée de GitHub App sont des identifiants critiques pour la plateforme elle-même. GITGUARDIAN_API_KEY donne un accès au tableau de bord de détection de fuites, permettant de masquer l’activité malveillante. » - Karlo Zanki, Socket

Le détournement du pipeline de release

Le 21 octobre 2026, entre 10h08 et 11h08 UTC, l’attaquant utilise un des tokens OAuth volés pour modifier le pipeline de publication : il remplace la source du référentiel légitime BerriAI/litellm par un lookalike Berri-AI/litellm (tiret au lieu du camel case). Ce dépôt frauduleux contient le code malveillant. Ensuite, il déclenche une nouvelle release en utilisant un second token pour l’approuver. Normalement, le pipeline exigeait qu’un ingénieur autorisé déclenche la release et qu’un compte spécial, verrouillé sur un appareil physique, l’approuve. Mais cette restriction avait été assouplie la semaine précédente pour accélérer les correctifs. L’attaquant a pu ainsi publier la version 1.107.0 de LiteLLM sur PyPI, Docker Hub et GHCR.

La publication de la version malveillante

• 21 octobre 2026, 11h39-11h40 UTC : publication de la version sur PyPI
• 11h46 UTC : publication des images Docker
• 11h53-11h54 UTC : suppression des enregistrements d’exécution (pour effacer les traces)
• 12h06 UTC : le chercheur de Upwind, Lidor Machluf, signale l’attaque
• 13h23 UTC : PyPI met en quarantaine la version 1.107.0
• 14h20 UTC : retrait ou re-pointage des tags Docker vers des images saines

En moins de deux heures, un package malveillant a été distribué via les canaux officiels. La réaction a été rapide, mais le mal était déjà fait : les développeurs ayant installé cette version entre-temps étaient compromis.

Le malware à double détente

L’analyse de la version malveillante a révélé deux composants distincts : un module de vol de credentials et une backdoor Unix persistante.

Le voleur de credentials

Les fichiers livrés avec la version 1.107.0 sont conçus pour s’exécuter automatiquement au démarrage de Python, même si LiteLLM n’est pas importé. Le malware cible :

• les fichiers SSH et les tokens Git/GitLab
• les variables d’environnement
• les tokens de gestionnaires de paquets (npm, pip, yarn, Maven, Gradle, Composer, RubyGems, Cargo)
• les données de sessions navigateur
• les clés API de services cloud (AWS, OpenAI, etc.)

Toutes ces données sont compressées et envoyées vers litellm[.]dev/healthcheck via une requête HTTP POST. Le domaine litellm.dev avait été enregistré le 13 octobre 2026, soit huit jours avant la publication malveillante.

« Ensemble, ces mécanismes étendent l’exposition au-delà des déploiements actifs de LiteLLM : simplement démarrer Python dans un environnement affecté pouvait activer le code malveillant, même sans importer LiteLLM. De plus, comme les fichiers de démarrage se trouvaient en dehors du répertoire de l’application, supprimer seulement les fichiers de LiteLLM laissait les composants malveillants en place. » - Équipe de recherche Microsoft Security

La backdoor Unix

Un second exécutable est lancé en tâche de fond et contacte toutes les heures le serveur de l’attaquant pour récupérer et exécuter du code arbitraire. Cela permet à l’attaquant de maintenir un accès persistant, de déployer des charges utiles supplémentaires ou d’explorer le réseau interne.

Chronologie des événements

Enseignements pour la sécurité des dépôts open source

Cette attaque n’est pas un cas isolé. Elle illustre des faiblesses que l’on retrouve dans de nombreuses organisations. Voici les leçons essentielles à retenir, en lien avec les recommandations de l’ANSSI (guide de sécurisation des pipelines CI/CD) et du standard OWASP pour la gestion des secrets.

La gestion du cycle de vie des secrets

La non-révocation de la clé maître est l’erreur fondamentale. Pour éviter cela :

• Automatisez la révocation : dès qu’un secret est détecté comme fuyant, une procédure automatisée doit le révoquer et en générer un nouveau.
• Utilisez des outils de détection de fuites (GitGuardian, truffleHog) mais ne les laissez pas être les seuls garants : si l’attaquant peut neutraliser l’outil (comme c’est arrivé ici), l’alerte ne sera pas levée.
• Appliquez une durée de vie limitée à tous les tokens : les tokens d’accès doivent expirer au bout de quelques heures ou jours, pas être permanents.

L’application du moindre privilège

Le token OAuth volé était de niveau owner, ce qui est une violation flagrante du principe du moindre privilège. Un token utilisé par un service automatisé (agent cloud) ne devrait jamais avoir de droits d’administration sur l’organisation GitHub. Les permissions devraient être strictement limitées aux actions nécessaires (créer des pull requests sur des dépôts spécifiques).

• Scopez chaque token au minimum requis : utilisez des tokens d’accès par dépôt avec des permissions write limitées, et non des tokens de compte personnel.
• Séparez les environnements : les tokens utilisés en production ne doivent pas être accessibles depuis un environnement de développement ou un agent externe.

La surveillance des workflows

Les workflows malveillants ont été exécutés sur des branches temporaires qui ont été supprimées immédiatement après. Pour détecter ce type d’activité :

• Mettez en place des alertes sur la création de workflows inconnus ou sur les modifications des fichiers .github/workflows/.
• Auditez régulièrement les permissions des tokens OAuth et les webhooks configurés.
• Utilisez des outils de détection d’anomalies sur les exécutions de pipelines (durée, artéfacts, appels réseau).

Pour aller plus loin : sécuriser vos dépôts en 2026

Voici une liste d’actions concrètes que vous pouvez mettre en œuvre dès aujourd’hui :

1. Révoquer et remplacer tous les tokens permanents par des tokens à courte durée de vie, renouvelés automatiquement via des workflows.
2. Mettre en place une secret-scanning en pré-commit pour empêcher l’ajout de secrets dans l’historique.
3. Limiter les droits des GitHub Actions : utilisez permissions: pour réduire les accès par défaut.
4. Activer la protection des branches avec des règles strictes (pas de force push, revue obligatoire).
5. Segmenter les accès : les tokens des agents automatisés ne doivent pas avoir les mêmes droits que les comptes humains.
6. Automatiser la révocation : dès qu’un secret est détecté dans un commit, un workflow doit le révoquer et notifier l’équipe.
7. Réaliser des exercices de réponse à incident : que feriez-vous si un token owner fuyait ?

Conclusion : une attaque évitable qui appelle à une vigilance accrue

L’attaque par chaîne d’approvisionnement dont LiteLLM a été victime aurait pu être évitée par une simple révocation de clé en mai 2026. Au lieu de cela, un enchaînement de négligences - absence de révocation, token aux droits excessifs, assouplissement des contrôles de release, et absence de surveillance des workflows - a permis à un attaquant de compromettre la chaîne de distribution d’un package utilisé par des milliers de développeurs.

En France, l’ANSSI insiste dans son guide de sécurisation des pipelines CI/CD sur la nécessité de gérer les secrets comme des actifs critiques, avec un cycle de vie complet (création, rotation, révocation). Cette affaire montre que les bonnes pratiques ne doivent pas rester lettre morte : chaque équipe doit auditer régulièrement ses tokens, automatiser leur rotation et restreindre leurs permissions au strict nécessaire. La chaîne d’approvisionnement open source est une cible privilégiée ; la protéger est l’affaire de tous.