Attaque de la chaîne d'approvisionnement LiteLLM : vol de credentials via des tokens GitHub divulgués

Le 21 octobre 2026, des acteurs de menace ont compromis le pipeline de publication de LiteLLM, une bibliothèque open-source de passerelle IA, pour distribuer une version malveillante de son logiciel. Les attaquants ont exploité des tokens OAuth GitHub CLI divulgués, probablement collectés à partir de journaux d'application, pour contourner les contrôles de sécurité et pousser des artefacts empoisonnés vers les principaux registres de paquets.

Ce qui s'est passé

L'incident a débuté aux alentours de 4h00 (heure du Pacifique) lorsque les attaquants ont publié la version 1.107.0 de LiteLLM sur le Python Package Index (PyPI), Docker Hub et GitHub Container Registry (GHCR). Cette version compromise contenait un voleur de credentials et une porte dérobée conçus pour récolter des secrets sur les systèmes affectés. Les utilisateurs ayant téléchargé des versions non épinglées via pip entre 11h39 et 13h23 UTC, ou ayant extrait des tags Docker spécifiques entre 11h46 et 14h20 UTC, ont été exposés au malware.

Le code malveillant employait une approche à double technique pour assurer la persistance et l'exécution. Il utilisait un fichier de chemin Python nommé "cook.pth" pour importer un script appelé "cook.py", qui se déobfusquait lui-même pour exécuter une routine nommée "privcollect". Cette routine collectait les secrets système, navigateur, cloud et outils IA, puis les exfiltrait vers un domaine contrôlé par l'attaquant. De plus, sur les machines Linux et macOS, le malware exécutait "sitecustomize.py" pour récupérer des instructions supplémentaires depuis un dépôt GitHub, établissant ainsi un cheval de Troie d'accès à distance qui interrogeait de nouvelles commandes toutes les heures.

Les mainteneurs de LiteLLM ont retracé la faille jusqu'à une combinaison de changements opérationnels et d'exposition des journaux. Bien que le projet ait récemment renforcé son pipeline de publication en signant les images et en utilisant des dépôts privés, les permissions ont été temporairement étendues pour permettre à deux ingénieurs de publier des correctifs quotidiens. Les attaquants ont accédé à trois jeux de credentials GitHub CLI de développeurs, soupçonnant que ces tokens étaient intégrés dans les corps de réponse enregistrés par un déploiement interne de LiteLLM exposé sur Internet. Un token appartenant à un propriétaire d'organisation a permis à l'attaquant de désactiver les protections de branche et de forcer la poussée de modifications malveillantes vers un dépôt imitant l'original, trompant le workflow CI/CD pour qu'il signe et publie les artefacts empoisonnés.

Détails clés

• Versions compromises : LiteLLM v1.107.0 sur PyPI ; v1.107.0, latest, main-latest et main-stable sur Docker et GHCR.
• Fenêtre d'impact : Utilisateurs PyPI entre 11h39 et 13h23 UTC ; utilisateurs Docker entre 11h46 et 14h20 UTC le 21 octobre 2026.
• Comportement du malware : Récolte des credentials via "privcollect" et établissement d'un balise horaire vers un serveur de commande et contrôle en utilisant GitHub comme boîte aux lettres morte.
• Vecteur d'attaque : Des tokens OAuth GitHub CLI divulgués trouvés dans les logs de LiteLLM ont été utilisés pour s'authentifier et manipuler le workflow de publication.
• Post-exploitation : Les credentials AWS volés ont été validés dans les 4,5 heures, les attaquants effectuant des activités de LLMjacking telles que la liste des modèles fondamentaux.
• Statut de mitigation : GitHub a supprimé le dépôt malveillant aux alentours de 13h30 UTC ; LiteLLM a depuis révoqué les permissions et fait pivoter les credentials.

Contexte

Les attaques de la chaîne d'approvisionnement ciblent les dépendances et les processus de construction des logiciels plutôt que les applications destinées aux utilisateurs finaux directement. Dans ce cas, les attaquants n'ont pas eu besoin d'exploiter une vulnérabilité dans le code de LiteLLM lui-même, mais ont plutôt compromis le mécanisme utilisé pour le distribuer. En injectant du code malveillant dans le paquet officiel, auquel font confiance des milliers de développeurs, ils ont assuré une distribution massive sans susciter de suspicion immédiate.

L'utilisation de tokens OAuth GitHub CLI met en évidence un risque courant dans les workflows de développement modernes. Ces tokens accordent un accès programmatique aux ressources GitHub et peuvent être très privilégiés. Lorsque de tels tokens sont involontairement enregistrés en texte clair—souvent par des assistants de codage IA ou des journaux d'application verbeux—ils deviennent des cibles faciles pour les attaquants scannant à la recherche de credentials accessibles. Une fois obtenus, ces tokens peuvent contourner l'authentification multifactorielle si la session est encore active, permettant aux attaquants d'agir comme des développeurs légitimes.

Pourquoi c'est important

Pour les équipes exécutant leur propre logiciel, cet incident souligne la fragilité de la confiance envers les dépendances open-source. Même les projets disposant de pratiques de sécurité robustes, telles que les artefacts signés et les tags immuables, peuvent être compromis si les workflows opérés par des humains sont affaiblis. L'extension temporaire des permissions de publication, destinée à améliorer la vélocité des développeurs, a créé une surface d'attaque exploitée par les adversaires. Cela sert de rappel que les fonctionnalités de commodité dans les pipelines CI/CD doivent être soigneusement limitées et surveillées.

De plus, l'exposition des credentials via les journaux est un problème persistant d'hygiène de sécurité. De nombreuses applications auto-hébergées et passerelles IA enregistrent les corps de requête et de réponse à des fins de débogage. Si ces journaux contiennent des tokens ou des clés sensibles, toute violation de l'infrastructure de journalisation—or même une exposition publique accidentelle d'un point de terminaison de débogage—peut entraîner une compromission catastrophique. Les équipes doivent considérer les journaux comme des réservoirs potentiels de secrets et les traiter avec la même rigueur de sécurité que le contenu des bases de données.

La rapidité avec laquelle les attaquants ont utilisé les credentials volés démontre l'urgence de la réponse aux incidents. Dans les heures suivant l'exfiltration, les adversaires énuméraient activement les ressources cloud et validaient les accès. Pour les responsables IT et DevOps, cela signifie que les mécanismes de détection et de rotation doivent être automatisés et immédiats. Attendre une investigation manuelle avant de faire pivoter les clés laisse aux attaquants amplement le temps d'établir la persistance et de se déplacer latéralement dans les environnements cloud.

Ce que vous pouvez faire

• Vérifier les versions installées : Vérifiez immédiatement si LiteLLM v1.107.0 ou l'un des tags Docker affectés est présent dans votre environnement et supprimez-le si trouvé.
• Faire pivoter tous les credentials : Supposez que tout secret stocké sur les systèmes ayant exécuté la version compromise est exposé. Faites pivoter les clés API, les credentials cloud et les tokens GitHub immédiatement.
• Auditer les journaux pour les tokens : Examinez vos journaux d'application et de passerelle IA pour vous assurer qu'aucun token OAuth ou secret n'est enregistré en texte clair. Implémentez des filtres de sanitisation des journaux.
• Restreindre les permissions de publication : Évitez les extensions temporaires des privilèges de publication. Si nécessaire, utilisez des tokens à durée de vie courte et à portée limitée, et exigez des étapes d'approbation supplémentaires pour la publication sur les registres publics.
• Épingler les versions des dépendances : Épinglez toujours des versions spécifiques des bibliothèques tierces dans vos fichiers de requirements pour empêcher l'installation automatique de mises à jour potentiellement compromises.
• Surveiller les activités suspectes : Consultez les journaux d'audit cloud pour détecter les appels API inhabituels, tels que des listes inattendues de modèles ou l'énumération IAM, qui peuvent indiquer des tentatives de LLMjacking.