Cyberattaque LiteLLM : Comment deux versions piégées ont exposé des milliers de secrets sur PyPI en quelques minutes

Deux versions piégées de LiteLLM ont suffi à transformer un outil très utilisé par les équipes IA en aspirateur à secrets. Le paquet, téléchargé à un rythme massif, sert de passerelle entre des applications et plusieurs modèles de langage. Quand cette brique tombe, c’est tout un pan des environnements Python qui se retrouve exposé, des postes de dev jusqu’aux pipelines CI/CD.

Le scénario est celui d’une attaque de supply chain attribuée à TeamPCP, déjà liée à d’autres compromissions récentes. Les versions malveillantes, publiées sur PyPI puis retirées, embarquaient un programme en plusieurs étapes, collecte silencieuse, exfiltration chiffrée, puis persistance via un service déguisé. La version considérée saine, à ce stade, est la 1.82.6.

TeamPCP publie LiteLLM 1.82.7 et 1.82.8 sur PyPI

Les versions compromises identifiées sont 1.82.7 et 1.82.8, mises en ligne sur PyPI avant d’être supprimées. Le point qui frappe, c’est la vitesse, une fois l’accès acquis, la publication de versions piégées peut se faire en minutes, et les installations suivent mécaniquement. Dans les équipes, un simple pip install -U lancé par habitude suffit à faire entrer la charge utile.

Les premiers indicateurs publics donnent une idée de l’onde de choc. Sur une fenêtre très courte, les versions malveillantes ont été téléchargées près de 47 000 fois en 46 minutes. Ce chiffre ne dit pas tout, un même téléchargement peut viser un serveur partagé, un runner CI ou une image Docker répliquée. Mais il illustre le risque propre aux dépôts de dépendances, la diffusion est quasi instantanée.

Le contexte d’usage amplifie l’impact. LiteLLM est utilisé comme passerelle pour parler à plusieurs fournisseurs de modèles via une seule API, ce qui le place souvent au cur d’applications et d’outils internes. Quand une librairie est branchée à des environnements cloud, à des clusters, à des secrets d’accès, l’infection ne touche pas seulement un laptop. Elle peut contaminer des chaînes automatisées, là où les permissions sont plus larges.

Et il y a un élément qui dérange, ce type d’attaque ne vise pas seulement des développeurs individuels, il vise des habitudes d’ingénierie. Les mises à jour non épinglées, les dépendances transverses, les pipelines qui installent la dernière version sans garde-fou, tout ça rend l’écosystème fragile. Tu peux avoir une équipe très sérieuse côté applicatif et te faire piéger par une simple dépendance.

Endor Labs décrit un infostealer en trois étapes

Les analyses publiées par des chercheurs en sécurité décrivent un malware structuré en trois temps. D’abord, une collecte discrète de tout ce qui ressemble à des secrets, clés SSH, mots de passe, identifiants cloud, tokens d’accès Kubernetes, et même des phrases de récupération de portefeuilles crypto. Le but n’est pas le sabotage immédiat, c’est la moisson de credentials réutilisables.

Deuxième étape, l’exfiltration. Les données sont envoyées vers une infrastructure contrôlée par les attaquants, sous forme d’archives chiffrées. Dans un environnement de dev, ce trafic peut passer sous le radar si la machine a déjà des flux vers l’extérieur pour tirer des dépendances, parler à des APIs, ou pousser des artefacts. Les attaquants jouent sur ce bruit de fond, et sur le fait que beaucoup de postes n’ont pas de supervision réseau fine.

Troisième étape, la persistance. Le code malveillant installe une porte dérobée déguisée en service système, nommé System Telemetry Service. Le choix du nom est parlant, c’est le genre d’intitulé qui ressemble à une brique d’observabilité. Dans une entreprise, si personne ne fait l’inventaire des services installés sur les runners, un composant comme ça peut rester en place et recevoir des instructions à distance.

Un détail technique rend l’affaire encore plus piégeuse. Dans la version 1.82.8, l’ajout d’un fichier . pth permettrait de déclencher la charge utile à chaque démarrage de Python, même si LiteLLM n’est pas activement utilisé. Autrement dit, tu peux croire avoir juste installé le paquet pour tester, puis passer à autre chose, et te retrouver quand même avec une exécution au fil de l’eau.

LiteLLM exposé via Trivy et des versions non épinglées

La chaîne d’attaque décrite repose sur un enchaînement classique de supply chain. LiteLLM utilisait Trivy dans son pipeline, sans précaution de version fixe. Dans ce type de configuration, une dépendance compromise peut contaminer l’outillage qui sert à construire, tester et publier. Le paradoxe, c’est qu’un outil de sécurité, intégré pour réduire le risque, devient l’élément déclencheur.

Le déroulé rapporté est précis sur le timing, à un moment donné, l’exécution de la version compromise dans le pipeline a exposé une clé secrète permettant de publier des packages au nom de LiteLLM sur le dépôt officiel. Cette clé, récupérée par les attaquants, a ouvert la porte à la publication de versions malveillantes. Et une fois la clé en main, publier sur PyPI revient à parler avec la voix du projet.

Dans ce scénario, l’erreur n’est pas un bug au sens classique. C’est une combinaison de pratiques, dépendances non figées, secrets accessibles au pipeline, et confiance implicite dans un outil tiers. Dans beaucoup d’équipes, on voit encore des pipelines qui loggent trop, qui montent des variables d’environnement partout, ou qui donnent des droits de publication à des jobs qui n’en ont pas besoin. Ce sont des raccourcis qui finissent par coûter cher.

Il y a aussi un angle souvent sous-estimé, l’attaque vise l’écosystème, pas seulement une cible. Les auteurs ont même enregistré des domaines destinés à recevoir les données volées, dont models. litellm. cloud, conçu pour imiter un domaine légitime. Ce genre de mimicry complique les détections basées sur des listes de domaines attendus, surtout si les équipes ne valident pas strictement les destinations réseau.

Des téléchargements massifs et un impact potentiel sur CI/CD

LiteLLM est loin d’être un paquet de niche. Les chiffres publics cités pour sa diffusion sont vertigineux, plus de 3 millions de téléchargements par jour, et environ 95 millions sur les 30 derniers jours. Même si seules deux versions ont été compromises, l’exposition potentielle est large, parce que la base installée est énorme et que les mises à jour sont fréquentes dans les projets IA.

Le risque principal, ce n’est pas seulement la machine d’un développeur. Dans les organisations, Python tourne partout, sur des runners CI/CD, des jobs de data, des images Docker, des notebooks partagés. Une installation automatique peut dupliquer la compromission à grande vitesse, surtout si les images sont reconstruites régulièrement. Et si un runner a accès à des secrets de déploiement, l’infostealer peut ouvrir la porte à des mouvements latéraux.

Les éléments collectés ciblent précisément ce qui permet de rebondir, tokens cloud, secrets Kubernetes, fichiers . env. Dans un cas concret, une clé SSH volée peut suffire à accéder à un bastion, un token Kubernetes peut donner la main sur un cluster, et un. env peut contenir des clés d’API pour des services IA payants. Le coût est double, fuite de données et compromission d’infrastructures.

Certains rapports évoquent environ 500 000 événements d’exfiltration ou appareils infectés, sans confirmation indépendante. Il faut donc manier ce chiffre avec prudence, mais il donne une idée de l’échelle possible. Et c’est là qu’il faut être lucide, même si ton équipe n’a pas installé ces versions, tes prestataires, tes sous-traitants ou tes dépendances internes ont pu le faire. L’attaque n’a pas besoin de frapper tout le monde pour faire très mal.

La version 1.82.6 est la référence saine et les actions à mener

Le point de repère communiqué est clair, la dernière version considérée propre est LiteLLM 1.82.6. Si tu es sur une version ultérieure touchée, l’objectif est de revenir à un état sain et de traiter la compromission comme un incident de sécurité complet, pas comme un simple downgrade. Le paquet malveillant a été supprimé, mais une suppression sur PyPI ne désinfecte pas une machine déjà contaminée.

Les recommandations publiques insistent sur des actions immédiates après exposition, et pas seulement une mise à jour. L’idée, c’est de partir du principe que des secrets ont pu être aspirés, credentials cloud, tokens, clés SSH, et qu’une persistance a pu être posée. Dans une équipe, ça implique un inventaire des machines et runners qui ont installé les versions incriminées, puis une réponse coordonnée avec la sécurité.

Concrètement, la priorité opérationnelle ressemble à ça, identifier toutes les installations de 1.82.7 et 1.82.8, mettre à jour vers 1.82.6, puis révoquer et régénérer les secrets exposés, surtout ceux qui donnent accès à des environnements partagés. Dans le monde CI/CD, ça veut dire tourner les tokens de publication, les clés de déploiement, les accès Kubernetes, et vérifier les journaux d’accès sur la période.

Dernier point, et c’est une critique qui mérite d’être posée, beaucoup d’organisations continuent de traiter PyPI comme un magasin sûr par défaut. Or l’épisode montre l’inverse, une compromission de pipeline suffit à publier sous une identité légitime. À moyen terme, ça pousse vers des pratiques plus strictes, versions épinglées, miroirs internes, contrôles d’intégrité, et surveillance des sorties réseau des runners. Ce n’est pas glamour, mais c’est le prix pour éviter qu’un simple import Python devienne une fuite généralisée.