En bref
- La version 1.107.0 a été publiée sur l'index de paquets Python et distribuée dans des images de conteneurs officielles.
- Le code malveillant visait des identifiants de développeurs, des accès au cloud, des clés privées, des données de navigateurs et certaines données du proxy LiteLLM.
- Microsoft a observé sur Windows et macOS des comportements compatibles avec la découverte, le chiffrement et la transmission réalisés par le collecteur.
- La présence du paquet indique une exposition potentielle, mais elle ne prouve pas que la collecte et l'envoi des données ont abouti.
Une compromission qui dépassait l'usage de LiteLLM
Le 21 octobre 2026, une version compromise de LiteLLM, numérotée 1.107.0, a été publiée sur Python Package Index. Cet index, appelé PyPI, distribue des bibliothèques prêtes à être installées dans des projets Python. La même version a aussi circulé dans des images de conteneurs officielles. Ces images regroupent une application et ses dépendances pour l'exécuter dans un environnement isolé.
Le risque ne concernait pas seulement les passerelles LiteLLM réellement utilisées. LiteLLM relie habituellement des applications à des fournisseurs de modèles d'intelligence artificielle. Pourtant, démarrer Python dans un environnement affecté pouvait suffire à activer le programme malveillant. Microsoft cite même un cas Windows où l'installation d'une dépendance sans rapport a déclenché le collecteur.
Des comptes de développement au coeur de la chaîne de publication
Selon les responsables de LiteLLM, des identifiants GitHub volés ont servi à modifier le processus de publication. Ce processus automatise la préparation et la diffusion d'une nouvelle version. Il aurait été redirigé vers Berri-AI/litellm, un dépôt ressemblant au dépôt légitime BerriAI/litellm. Un autre compte de développement compromis aurait ensuite validé l'étape d'approbation pour la production.
Cette séquence constitue une attaque contre la chaîne d'approvisionnement logicielle. L'attaquant ne vise pas directement chaque utilisateur, mais le mécanisme qui lui livre un composant jugé fiable. Les postes de développeurs, agents de construction, systèmes de test et conteneurs pouvaient donc recevoir le même code. Microsoft précise toutefois ne pas avoir établi comment l'accès initial et les identifiants ont été obtenus.
Deux portes ouvertes au démarrage de Python
L'analyse technique de Microsoft porte sur les fichiers wheel compromis, le format utilisé pour distribuer des paquets Python installables. Trois fichiers, cook.pth, cook.py et sitecustomize.py, étaient placés dans le répertoire général de bibliothèques. Python consulte normalement cet emplacement pendant son initialisation. Le fichier cook.pth lui ordonnait alors d'importer cook.py, qui décodait, décompressait puis exécutait le collecteur nommé PRIVCOLLECT.
Une seconde voie reposait sur sitecustomize.py et ciblait les systèmes de type Unix. Elle pouvait récupérer du code Python depuis un serveur distant, puis le compiler et l'exécuter sans vérifier sa signature. Le serveur était indiqué par un fichier hébergé sur GitHub, modifiable après la publication du paquet. Lors de l'examen cité, ce fichier était vide. Microsoft n'a donc confirmé ni récupération ni exécution d'une seconde charge.
Un inventaire étendu de secrets accessibles
Le collecteur cherchait des éléments d'authentification dans plusieurs outils de développement, applications d'intelligence artificielle et services cloud. Il visait aussi des configurations de gestionnaires de paquets, des variables d'environnement et des secrets montés dans les systèmes. Des clés SSH, utilisées pour sécuriser des connexions distantes, figuraient également parmi les cibles. Les données de navigateurs et certains historiques locaux complétaient cet inventaire.
Quand certaines conditions étaient réunies, un module séparé interrogeait deux tables de la base du proxy LiteLLM. Il tentait d'y lire des identifiants et des paramètres de modèles, avec une limite de 500 lignes par requête. Une cible présente dans le code ne signifie cependant pas que sa lecture a réussi. L'accès dépendait des droits du processus et des fichiers réellement disponibles sur la machine.
Des observations solides, mais pas une preuve pour chaque installation
La méthode de Microsoft combine l'examen du paquet avec des observations recueillies sur des appareils Windows et macOS. Ces traces correspondaient aux étapes prévues par le code, notamment la découverte du système, le chiffrement et une connexion sortante. Le collecteur rassemblait ses résultats, les chiffrait avec une clé créée pour chaque exécution, puis tentait de les envoyer vers une adresse contrôlée par l'attaquant.
L'interprétation doit rester prudente pour chaque machine. Un lancement de Python ne prouve pas que le fil d'exécution en arrière-plan a terminé son travail. Un processus bref pouvait s'arrêter avant la fin, tandis qu'un marqueur local pouvait manquer après un échec d'écriture. Microsoft recommande donc de croiser fichiers, processus, traces cryptographiques, connexions réseau et usages ultérieurs des identifiants, plutôt que de conclure sur le seul paquet.
Pourquoi supprimer LiteLLM ne suffit pas
Les fichiers de démarrage étaient installés hors du répertoire normal de LiteLLM. Effacer seulement l'application pouvait donc les laisser dans l'environnement Python. Microsoft conseille d'identifier toutes les copies, y compris dans les caches, miroirs internes, fichiers de verrouillage, résultats de construction et images de conteneurs. L'enquête doit se faire depuis un système sain, sans lancer Python ni pip dans l'environnement suspect.
La remise en état passe par une reconstruction depuis des éléments vérifiés et par la suppression des trois fichiers de démarrage. Microsoft recommande aussi de renouveler, depuis une machine saine, les identifiants accessibles au compte touché. Cette opération couvre notamment les clés de fournisseurs de modèles, les accès cloud, les secrets d'automatisation, les jetons de code source et les sessions de navigateur. Les sessions concernées doivent aussi être révoquées.
Ce qui reste à confirmer
Microsoft n'a pas déterminé l'origine de l'accès initial ni confirmé la récupération d'une seconde charge sur Unix. La présence de LiteLLM 1.107.0 ou d'un fichier générique établit une exposition potentielle, pas une collecte réussie. Les observations citées concernent Windows et macOS, sans décompte de systèmes touchés ni mesure globale des données effectivement envoyées.