Attaque LiteLLM : une clé maître oubliée ouvre la porte à un piratage de la chaîne d'approvisionnement

Et si une simple clé logicielle, oubliée dans un dépôt public, suffisait à dévaster l’ensemble de votre chaîne de développement ? C’est exactement ce qui est arrivé à LiteLLM, une passerelle open source populaire pour les grands modèles de langage (LLM). En octobre 2026, un attaquant a exploité une clé maître non révoquée - pourtant exposée depuis mai 2026 - pour compromettre le pipeline de livraison et publier une version malveillante du package Python. Cet incident illustre de manière brutale les risques d’une attaque de la chaîne d’approvisionnement logicielle et souligne l’urgence d’une gestion rigoureuse des secrets.

Selon les analyses des équipes de sécurité de LiteLLM, de Socket et de Microsoft Security Research, l’attaque s’est déroulée en plusieurs phases, combinant fuite accidentelle, absence de révocation, escalade de privilèges et exfiltration massive de tokens. En tant que professionnel de la cybersécurité, vous devez comprendre chaque étape de cette compromission pour renforcer vos propres défenses.

Une compromission en quatre mois : de la fuite à l’exploitation

Le 27 mai 2026, un fichier de configuration est commité accidentellement sur le dépôt public LiteLLM-Labs/lite-harness. Ce fichier contient la master key de l’Agent Platform, l’outil d’orchestration des agents LLM de LiteLLM. L’équipe identifie rapidement l’erreur et force un push sur le commit, mais la clé n’est jamais révoquée. « L’erreur a été rapidement identifiée, le commit a été forcé, et nous avons identifié les clés exposées comme devant être révoquées. Cependant, la révocation n’a pas eu lieu pour la clé maître », expliquent Oliver Jensen et Mateo Wang, développeurs chez LiteLLM.

Ce n’est que quatre mois plus tard, le 10 octobre 2026, que l’attaquant (depuis l’adresse IP 69.48.229[.]143) utilise cette clé maître toujours active pour accéder à l’Agent Platform. Une fois à l’intérieur, il extrait un jeton OAuth GitHub CLI que la plateforme utilisait pour permettre aux agents cloud de soumettre des pull requests vers les dépôts GitHub. Ce jeton, associé au compte propriétaire de l’organisation GitHub, n’était pas limité en droits - il offrait un accès propriétaire à tous les dépôts de l’organisation.

« Le token n’était pas limité en privilèges » - LiteLLM

Grâce à ce jeton, l’attaquant pouvait non seulement lire tous les codes sources, mais aussi modifier les workflows, désactiver les protections de branches et, in fine, manipuler le pipeline de release.

La chronologie détaillée de l’intrusion

Le tableau suivant résume les événements clés, dont certains ne se sont déroulés que quelques minutes.

Ce qui frappe dans cette chronologie, c’est la rapidité avec laquelle l’attaquant a agi après avoir obtenu les jetons des ingénieurs. Les branches temporaires n’ont existé que quelques minutes, et les workflows ont été déclenchés immédiatement grâce à l’événement on: [push].

Les premières tentatives d’exfiltration de tokens

L’attaquant a créé deux branches éphémères (ci-tmp-a351cc et ci-tmp-4d8517) en se basant sur un commit légitime récent pour ne pas éveiller les soupçons. Le commit ajoutait un fichier .github/workflows/cache.yml avec le sujet « ci: bump cache config ». Ce workflow, configuré pour s’exécuter à chaque push, permettait d’exfiltrer des tokens GitHub, des clés API pour Linear, Together AI, et la clé d’identification d’une GitHub App. Une seconde exécution, le 12 octobre, a étendu la collecte à de nombreux autres secrets : API keys d’Anthropic, OpenAI, AWS Bedrock, Tavily, et même la clé API de GitGuardian - le service même de détection de secrets. « Une clé API GitGuardian donne à un attaquant une visibilité sur les alertes et potentiellement un contrôle sur celles-ci », souligne Karlo Zanki de Socket.

« Les données exfiltrées étaient envoyées vers webhook[.]site/65a42464-… et webhook[.]site/4da03473-… » - Socket

Des workflows malveillants taillés pour la moisson de secrets

Les deux workflows découverts par les analystes de Socket révèlent une sophistication certaine. Voici les types de secrets ciblés :

• Environnement de développement : jetons GitHub (plusieurs niveaux), clé privée de GitHub App, identifiants de bases de données PostgreSQL (chaîne de connexion, mot de passe), points de terminaison Redis.
• Services d’IA : API keys pour OpenAI, Anthropic, AWS Bedrock, Together AI.
• Outils internes : clé API Linear, état de session Playwright (permettant un accès authentifié sans MFA).
• Infrastructure : jetons npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems, Cargo.
• Données de navigation : fichiers de stockage de navigateur (cookies, sessions).

Cette liste montre que l’attaquant cherchait à obtenir un maximum de leviers pour compromettre non seulement la plateforme LiteLLM, mais aussi tous les services connectés. L’exfiltration utilisait deux endpoints webhook[.]site distincts, probablement pour éviter une détection par volumétrie.

« La collecte incluait même GTIGUARDIAN_API_KEY, la clé du détecteur de secrets lui-même » - Socket

Dans les entrailles de la version malveillante (1.107.0)

Le package malveillant publié sur PyPI le 21 octobre 2026 ne se contentait pas d’infecter les seuls utilisateurs de LiteLLM. Les chercheurs de Microsoft Security Research ont découvert que les fichiers malveillants s’exécutaient automatiquement au démarrage de Python, même si LitaLLM n’était pas importé. Deux composants principaux étaient dissimulés :

• Un module de moissonnage : il collecte les informations système, fichiers SSH, jetons Git/GitLab, variables d’environnement, tokens de gestionnaires de paquets (npm, pip, etc.), données de navigateur (cookies, sessions). Le tout est compressé et envoyé par POST HTTP vers litellm[.]dev/healthcheck, un domaine enregistré le 13 octobre 2026.
• Une backdoor Unix : un processus en arrière-plan récupère et exécute du code arbitraire toutes les heures.

« Le simple fait de lancer Python dans un environnement affecté pouvait activer le code malveillant, même si LiteLLM n’était jamais importé » - Microsoft Security Research

Cette architecture rend le nettoyage particulièrement difficile : les fichiers de démarrage se trouvent en dehors du répertoire de l’application, donc une simple suppression du dossier LiteLLM ne suffit pas.

Un exemple d’impact concret

Imaginez une PME française spécialisée dans l’analyse de textes via LLM. Elle utilise LiteLLM pour agréger plusieurs modèles (OpenAI, Claude, Mistral). Le 21 octobre 2026, un développeur exécute pip install --upgrade litellm. La version 1.107.0 s’installe, le code malveillant est activé immédiatement. En quelques minutes, les jetons d’API OpenAI, les identifiants de la base PostgreSQL contenant les résultats d’analyse clients, et les tokens GitHub de l’organisation sont exfiltrés. L’attaquant peut dès lors accéder aux repositories privés, modifier le code, insérer des portes dérobées dans d’autres projets. Pour cette entreprise, l’incident a des conséquences juridiques (violation RGPD, fuite de données clients) et industrielles (vol de propriété intellectuelle).

Enseignements pour sécuriser vos pipelines de développement

Cet incident n’est pas un cas isolé. Il s’inscrit dans une tendance lourde d’attaques ciblant les chaînes d’approvisionnement logicielles, où un seul maillon faible peut compromettre des milliers de consommateurs. Les leçons à en tirer sont nombreuses, et vous pouvez dès maintenant les appliquer dans votre organisation.

L’importance de la révocation et de la rotation des clés

Le point de départ de l’attaque est une clé maître exposée puis non révoquée. Une gestion rigoureuse des secrets est primordiale :

• Automatisez la détection des secrets exposés (via des scanners comme GitGuardian, prenez l’exemple de la clé GitGuardian volée).
• Implantez une politique de rotation obligatoire : toute clé potentiellement compromise doit être révoquée immédiatement, même si l’exposition semble limitée.
• Limitez la durée de vie des tokens : des jetons avec expiration courte réduisent la fenêtre d’exploitation.

Le principe du moindre privilège pour les jetons GitHub

Le token OAuth utilisé par l’Agent Platform disposait de droits propriétaires sur l’ensemble de l’organisation. L’ANSSI recommande dans son guide de « Sécurisation des pipelines CI/CD » de toujours restreindre les permissions : un token utilisé pour soumettre des pull requests n’a pas besoin d’accès admin. Utilisez des tokens avec des permissions granulaires (ex : contenu en lecture-écriture) et associez-les à des comptes de service dédiés, non à des comptes personnels.

La surveillance des événements GitHub

Les attaquants créent des branches temporaires qui n’existent que quelques minutes. Pour les détecter, activez les notifications sur les événements de création de branche et les pushs vers des branches non standard. Des alertes sur des noms comme ci-tmp-* peuvent être mises en place. De même, surveillez les modifications des pipelines de release et les ajouts de workflows.

La sécurisation des runners GitHub Actions

Les workflows malveillants ont pu exécuter du code sur des runners auto-hébergés ou GitHub. Assurez-vous que vos runners ne disposent pas d’un accès réseau trop large et isolez les environnements de build. Utilisez des runners éphémères et nettoyez toujours les artefacts après exécution.

La défense en profondeur pour les versions publiées

Même si PyPI a mis en quarantaine la version malveillante en 1h17, durant ce laps de temps, de nombreux téléchargements ont eu lieu (le package comptait plus d’un million de téléchargements mensuels). Implantez un miroir privé de packages PyPI avec validation de hash et signature, ou utilisez des outils comme Sigstore ou SLSA pour attester l’intégrité des artefacts.

Plan d’action immédiat pour les équipes de sécurité

Voici une check-list que vous pouvez suivre pour réduire les risques similaires :

1. Auditez vos secrets exposés : lancez une recherche de tokens, clés API et mots de passe dans tous vos dépôts publics et privés (scannez l’historique git).
2. Révoquez et faites tourner immédiatement tout secret qui apparaît dans un commit, même s’il a été pushé puis supprimé.
3. Réduisez les privilèges des jetons GitHub : créez des comptes de service avec les droits minimaux nécessaires (ex : contents: write uniquement pour les dépôts ciblés).
4. Activez la protection des branches : imposez des revues de code et des approbations pour les branches de publication (main, stable).
5. Surveillez les branches temporaires : configurez des alertes pour les noms de branches suspects (ci-tmp-*, tmp-*).
6. Isolez vos runners CI/CD : utilisez des conteneurs éphémères, limitez les accès réseau.
7. Implémentez une signature des artefacts : utilisez des outils comme sigstore ou cosign pour que les consommateurs vérifient l’origine des packages.
8. Formez vos développeurs : sensibilisez aux risques de fuite de secrets dans les commits et à la nécessité de la révocation rapide.

Conclusion : une vigilance de tous les instants

L’attaque LiteLLM de 2026 est un cas d’école. Une simple clé maître non révoquée, couplée à un jeton GitHub trop permissif, a permis à un attaquant de prendre le contrôle d’une plateforme open source majeure, de compromettre son pipeline de release et de diffuser un code malveillant potentiellement infectieux pour des milliers d’utilisateurs. Cette attaque de la chaîne d’approvisionnement rappelle que la sécurité ne s’arrête pas à la porte du SI : elle doit s’étendre à chaque étape du cycle de développement, de la conception à la distribution.

En tant que responsable de la sécurité, vous devez considérer cet incident comme un signal d’alarme. Agissez dès aujourd’hui pour renforcer vos pratiques : révoquez sans hésiter, limiter les droits, surveyez en continu. Ce n’est qu’à ce prix que vous éviter de devenir la prochaine victime d’une attaque de la chaîne d’approvisionnement.