PyPI compromis par un clone de LiteLLM qui siphonnait les secrets des développeurs

Un simple pip install a suffi pour transformer des PC de dev en coffres-forts ouverts. En mars 2026, des versions piégées de LiteLLM, un outil très utilisé dans les stacks IA, ont embarqué un infostealer capable de récupérer des secrets déjà présents en clair sur les machines, puis de les envoyer vers une infrastructure contrôlée par les attaquants.

Le cur du problème, c’est la place du poste développeur dans l’entreprise. C’est là que s’accumulent clés SSH, jetons cloud, variables d’environnement, fichiers. env, historiques de commandes, configs Docker et Kubernetes. L’attaque attribuée au groupe TeamPCP n’a pas eu besoin d’exploits sophistiqués, elle a surtout profité d’une réalité banale, les identifiants traînent partout, et l’installation d’un package Python peut exécuter du code.

TeamPCP a piégé LiteLLM 1.82.7 et 1.82.8 sur PyPI

Les versions 1.82.7 et 1.82.8 publiées sur PyPI ont été identifiées comme compromises, avec du code malveillant injecté dans des releases officielles. Le scénario est celui d’une attaque de chaîne d’approvisionnement, tu récupères un package réputé légitime, et tu installes en réalité un collecteur de secrets. Dans un environnement Python, l’installation n’est pas un acte neutre, certains mécanismes se déclenchent immédiatement.

Le cas le plus risqué décrit par les analystes concerne LiteLLM 1.82.8, où un fichier . pth malveillant permet l’exécution automatique quand l’interpréteur Python démarre. Dit autrement, tu peux te faire toucher sans lancer « l’application » au sens habituel, il suffit d’avoir Python qui charge ce qui a été posé sur disque. Pour 1.82.7, l’attention se porte plutôt sur les systèmes qui ont importé le module proxy.

Ce point casse un réflexe courant chez les devs, « j’ai juste installé, je n’ai rien exécuté ». Dans l’écosystème Python, installer peut déclencher des actions, et dans une CI/CD, ça se produit à grande échelle. Tu mets à jour une dépendance, des runners s’exécutent, des environnements se reconstruisent, et la fenêtre d’exposition s’ouvre sur plusieurs machines en parallèle, parfois dans des comptes cloud différents.

Le fait que l’attaque cible un composant lié à l’IA renforce l’impact. LiteLLM sert à abstraire les différences entre fournisseurs de modèles et à brancher facilement des services LLM dans des applications. Quand un outil devient un passage quasi obligé, une compromission ne touche pas seulement un projet isolé, elle peut se diffuser par dépendances directes ou transitives, sans que l’équipe ne s’en rende compte immédiatement.

Le malware a aspiré clés SSH, identifiants AWS, Azure et GCP

Le payload observé a été conçu pour voler des secrets utiles, pas pour faire du bruit. Les collectes décrites couvrent des éléments très concrets, clés SSH, identifiants cloud AWS, Azure et GCP, configurations Docker, données liées à Kubernetes, variables d’environnement, et d’autres fichiers sensibles typiques d’un poste de dev. Ce n’est pas « du malware générique », c’est un aspirateur à accès d’infrastructure.

Les analystes décrivent aussi la collecte d’artefacts qui, dans la vraie vie, finissent souvent sur disque sans intention malveillante. Un fichier . env créé « temporairement », un script de debug, un copier-coller de commande contenant un token, un fichier de config oublié dans un repo local. Tu vois le tableau, la convenance produit des résidus, et ces résidus deviennent une opportunité quand un infostealer arrive.

Le périmètre de recherche inclut aussi des secrets applicatifs et des comptes de services, par exemple des identifiants de bases de données, des configs d’outils, des historiques shell, et des clés d’API variées. Certaines analyses mentionnent des recherches liées à des outils de collaboration comme Slack et Discord, et des éléments liés à des portefeuilles ou environnements crypto, signe que les opérateurs veulent monétiser plusieurs types d’accès selon ce qu’ils trouvent.

Un point à retenir, le poste développeur concentre des accès de production plus souvent qu’on ne veut l’admettre. Un ingénieur peut avoir un rôle cloud étendu « pour dépanner », un kubeconfig local « pour vérifier vite », un token CI « pour relancer un job », puis tout ça reste. L’attaque LiteLLM rappelle que la valeur n’est pas seulement dans le serveur, elle est sur l’endpoint, là où les clés sont créées, testées, copiées et réutilisées.

Un infostealer en 4 couches, chiffrement AES-256 et RSA-4096

Les investigations détaillent une architecture en plusieurs étages. Le schéma décrit parle de 4 couches, avec un lanceur, un orchestrateur, un collecteur et un module de persistance. Le lanceur déclenche l’exécution des étapes suivantes, l’orchestrateur embarque notamment une clé publique RSA-4096 et gère le packaging, puis le collecteur ratisse le système pour récupérer les secrets ciblés.

Avant de sortir de la machine, le butin est chiffré localement. Les mécanismes mentionnés combinent un chiffrement symétrique AES-256 pour les données et un chiffrement asymétrique RSA-4096 pour protéger la clé de session. Cette approche est classique chez les infostealers modernes, elle complique l’analyse côté victime, et elle évite qu’un simple proxy ou un EDR « voit » des secrets en clair sur le réseau.

L’exfiltration a été observée vers un domaine utilisé comme point de collecte, models. litellm[.]cloud, avec un en-tête spécifique X-Filename mentionné dans les analyses, typiquement « tpcp. tar. gz ». Ce genre de détail compte en détection, parce qu’il permet de chercher des traces réseau et de corréler des événements. Dans une entreprise, ce sont souvent ces indicateurs concrets qui déclenchent une chasse proactive.

La persistance est un autre marqueur de gravité. Les éléments décrits incluent l’écriture d’un script dans /. config/sysmon/sysmon. py et l’installation d’une unité utilisateur systemd nommée sysmon. service. Le malware peut aussi maintenir une boucle de polling pour récupérer des charges supplémentaires. Là, on n’est plus dans « un vol ponctuel », on parle d’un point d’appui qui peut survivre et servir à des actions de suivi.

LiteLLM proxy centralise les clés OpenAI, Anthropic et Azure AI

Le risque ne dépend pas uniquement du code malveillant, il dépend de l’endroit où l’outil est placé. Les analyses soulignent que LiteLLM occupe une position privilégiée dans la pile IA, surtout quand il est déployé en mode proxy comme passerelle centralisée. Dans ce modèle, il manipule et concentre des clés d’accès à plusieurs fournisseurs de modèles, ce qui crée un effet « un point, toutes les clés ».

Concrètement, un proxy LiteLLM peut gérer des clés pour OpenAI, Anthropic, Azure AI et d’autres services à la fois. Si ce composant est compromis, l’attaquant ne récupère pas seulement un token isolé, il peut obtenir un portefeuille d’accès à des API LLM, avec un impact financier et opérationnel direct. Une clé volée peut servir à consommer des quotas, à générer des coûts, ou à pivoter vers d’autres ressources.

Les analystes distinguent ce risque du simple usage en bibliothèque SDK, où les identifiants peuvent être fournis « par requête » et ne pas être centralisés de la même manière. Mais dans la pratique, beaucoup d’équipes adoptent le proxy parce qu’il simplifie la gestion multi-fournisseurs, la facturation interne et l’observabilité. C’est pratique, mais ça augmente la surface de concentration, et donc la taille du rayon d’explosion.

Un chiffre ressort dans les analyses, 36% des environnements cloud contiendraient LiteLLM, ce qui donne une idée de l’ubiquité du composant. Même si tu ne l’utilises pas directement, il peut arriver comme dépendance transitive d’un autre outil IA. C’est la mécanique qui rend ces attaques difficiles, tu sécurises ton code, mais tu héritas des risques des briques que tu installes.

Détection et réponse, traiter toute machine touchée comme compromise

Les recommandations opérationnelles sont sans détour, toute machine ayant installé litellm 1.82.7 ou 1.82.8 doit être considérée comme potentiellement compromise. Même logique pour les versions compromises d’un autre package mentionné dans la même campagne, telnyx 4.87.1 et 4.87.2. L’idée n’est pas de « nettoyer vite », mais de partir du principe que des secrets ont pu sortir.

La réponse passe par une rotation large, clés SSH, tokens cloud, identifiants CI/CD, secrets Kubernetes, clés d’API LLM. C’est pénible, oui, et c’est là que je nuance, beaucoup d’équipes sous-estiment le coût réel d’une rotation complète, surtout quand les secrets sont dispersés dans des outils différents. Mais si tu ne rotes pas, tu laisses potentiellement une porte ouverte, parce que l’attaquant n’a pas besoin de revenir sur ta machine pour réutiliser ce qu’il a volé.

Côté détection, les éléments techniques fournis permettent de chasser des indicateurs. Les chemins comme litellm_init. pth, /tmp/pglog, ou les fichiers sous /. config/sysmon sont des points de contrôle. Des requêtes de logs orientées cloud et Kubernetes peuvent aussi aider à repérer des accès anormaux à des secrets, par exemple des appels de type « get/list secrets » avec un user-agent Python. Ce sont des signaux faibles, mais exploitables.

Plus largement, l’incident remet sur la table un sujet que tout le monde repousse, le poste développeur est une infrastructure critique. Tant que des identifiants restent en clair dans des . env et des répertoires home, tant que des clés de prod vivent sur des laptops, un infostealer « banal » suffit. Les équipes sécurité vont pousser vers plus de séparation, comptes à privilèges minimaux, tokens courts, coffre-fort de secrets, et contrôle des dépendances, mais l’équilibre entre vitesse dev et hygiène reste un bras de fer quotidien.