Attaque de la chaîne d'approvisionnement LiteLLM : une clé maître non révoquée et une exfiltration via webhook

LiteLLM a révélé une compromission critique de sa chaîne d'approvisionnement le 24 octobre 2026, découlant d'une fuite de clé maître survenue en mai. Un attaquant a utilisé cet accès pour injecter du code malveillant dans la version 1.107.0 du populaire package Python, visant les identifiants des développeurs et les environnements système.

Ce qui s'est passé

L'incident a débuté le 27 mai 2026, lorsqu'un fichier de configuration contenant une clé maître pour la plateforme LiteLLM Agent a été accidentellement committé dans un dépôt GitHub public. Bien que l'équipe ait rapidement forcé le push pour écraser ce commit et identifié la nécessité de révoquer la clé, celle-ci n'a jamais été effectivement révoquée. Le 10 octobre 2026, un attaquant opérant depuis l'adresse IP 69.48.229.143 a utilisé cette clé toujours valide pour accéder à la plateforme Agent. Depuis là, il a extrait un jeton OAuth CLI GitHub qui n'était pas restreint par périmètre (scope) et était associé au compte du propriétaire de l'organisation.

Doté d'un accès niveau propriétaire, l'attaquant a mené une série d'opérations furtives. Le 10 octobre, il a créé des branches éphémères dans des dépôts internes pour exécuter des workflows conçus pour collecter des identifiants supplémentaires. Ces branches ont été supprimées en quelques minutes, ne laissant que peu de traces dans l'historique standard. Au 21 octobre, l'attaquant avait outrepassé les protections de branches et modifié le pipeline de publication pour qu'il pointe vers un dépôt imitant l'original. Il a utilisé des jetons d'ingénieurs volés pour déclencher et approuver la publication de LiteLLM version 1.107.0 sur PyPI, Docker Hub et GHCR avant de supprimer les registres de production pour effacer ses traces.

Le package malveillant a été mis en quarantaine par PyPI et retiré des registres de conteneurs plus tard dans la journée après avoir été signalé par des chercheurs en sécurité. LiteLLM a confirmé que l'attaquant aurait pu assouplir davantage les restrictions de publication, mais a probablement évité de le faire pour échapper à la détection. L'entreprise travaille désormais à la révocation de tous les jetons associés à ses systèmes internes et plateformes de fournisseurs.

Comment cela fonctionne

La méthode principale utilisée par l'attaquant pour voler des identifiants consistait à injecter des workflows GitHub Actions malveillants dans des branches jetables. Ces workflows, nommés cache.yml, étaient configurés pour s'exécuter à chaque push. Ils collectaient des secrets tels que les clés API pour Anthropic, OpenAI, AWS Bedrock et GitGuardian, ainsi que des identifiants de base de données et des états de session de navigateur. Les données volées étaient exfiltrées vers des endpoints contrôlés par l'attaquant sur webhook.site, un service permettant aux utilisateurs d'inspecter les requêtes HTTP entrantes.

Une fois publié, la version compromise de LiteLLM 1.107.0 contenait un malware qui s'exécutait automatiquement au démarrage de Python, même si la bibliothèque n'était pas importée. Le malware incluait un module de collecte d'identifiants qui scannait les matériaux d'authentification à travers les outils de développement, les environnements cloud et les navigateurs. Il installait également une porte dérobée orientée Unix qui récupérait et exécutait du code arbitraire depuis le serveur de l'attaquant toutes les heures. Cela signifiait que le simple fait de démarrer Python dans un environnement affecté pouvait activer le code malveillant, étendant le risque au-delà des déploiements actifs de LiteLLM.

Détails clés

• Le vecteur initial de violation était une clé maître fuitée le 27 mai 2026, qui n'a jamais été révoquée malgré son exposition identifiée.
• Les attaquants ont utilisé des endpoints webhook.site pour exfiltrer des identifiants volés, y compris des clés API et des mots de passe de bases de données.
• Des workflows malveillants ont été poussés sur des branches éphémères et supprimés en quelques minutes pour éviter la détection dans l'historique du dépôt.
• La version compromise du package 1.107.0 a été publiée sur PyPI et les registres de conteneurs le 21 octobre 2026.
• Le malware s'exécute au démarrage de Python et inclut une porte dérobée qui communique avec litellm.dev toutes les heures.
• Les identifiants volés comprenaient l'accès à Linear, Together AI et des plateformes de scan de secrets comme GitGuardian.

Pourquoi c'est important

Cet incident met en évidence les risques graves liés à une gestion inadéquate des clés et à des pipelines CI/CD trop permissifs. L'échec de la révocation d'une clé connue comme compromise plusieurs mois après son exposition a permis à l'attaquant de maintenir un accès persistant. Pour les équipes d'ingénierie, cela souligne l'importance de traiter la rotation des clés comme un contrôle de sécurité critique plutôt que comme une tâche de maintenance optionnelle. Cela démontre également comment des contrôles de publication relâchés, même pour une commodité temporaire, peuvent créer des vulnérabilités exploitées par les attaquants pour contourner les processus d'approbation multi-personnes.

L'utilisation de l'exfiltration basée sur les webhooks montre comment les attaquants exploitent des outils de débogage légitimes pour voler des données sans déclencher d'alertes de sécurité traditionnelles. Étant donné que les données étaient envoyées à des endpoints webhook externes, elles contournaient la surveillance réseau interne. Les développeurs et ingénieurs en sécurité doivent reconnaître que tout service capable de recevoir des requêtes HTTP peut être utilisé comme canal d'exfiltration de données. Comprendre comment ces requêtes sont structurées et ce qu'elles contiennent est essentiel pour détecter et prévenir de telles attaques.

Ce que vous pouvez faire

• Auditez tous les pipelines CI/CD pour identifier les permissions trop larges et assurez-vous que les jetons sont limités au minimum d'accès requis.
• Implémentez une rotation automatique des clés et des protocoles de révocation immédiate pour toute credential exposée dans des dépôts publics.
• Surveillez les exécutions de workflows inhabituelles, en particulier celles impliquant des branches éphémères ou des suppressions rapides.
• Inspectez les requêtes HTTP sortantes depuis vos environnements de build pour détecter toute exfiltration de données non autorisée vers des services externes.
• Vérifiez l'intégrité des packages tiers en vérifiant les hashs et en utilisant des fichiers de verrouillage (lock files) pour empêcher les mises à jour inattendues.
• Revoyez et restreignez l'accès aux pipelines de publication, en veillant à ce que les relaxations temporaires des contrôles de sécurité soient strictement limitées dans le temps et surveillées.