JFrog détecte un code malveillant dans LiteLLM sur PyPI

JFrog a découvert du code malveillant dans LiteLLM 1.107.0, une bibliothèque Python reliant des applications à des fournisseurs de LLM. La charge a été trouvée dans les sept wheels PyPI de cette version. Ces fichiers s’exécutent au démarrage de Python dans l’environnement concerné. L’application n’a pas besoin d’importer LiteLLM pour déclencher ce comportement. LiteLLM est téléchargée des centaines de millions de fois chaque mois depuis PyPI. Cette version constitue aussi le deuxième détournement de LiteLLM observé cette année. L’alerte concerne donc les environnements ayant installé cette version, même lorsque LiteLLM n’est pas utilisée directement par l’application. Lire le décryptage de JFrog.

Trois fichiers supplémentaires sont présents dans les sept wheels de LiteLLM 1.107.0. Ils se lancent à chaque démarrage de Python dans l’environnement affecté. La charge utile collecte des identifiants cloud, SSH, CI/CD et navigateur. Elle récupère aussi des jetons associés aux outils de codage par IA. Un canal d’exécution de code à distance s’ouvre ensuite toutes les heures. Cette exécution persiste donc au-delà d’un simple lancement de l’application. Le comportement touche les environnements qui ont installé la wheel, y compris lorsque le code applicatif n’importe jamais le module LiteLLM. Les wheels exactes doivent ainsi être distinguées du dépôt source correspondant dans le contrôle des versions installées. Consulter l’article original.

JFrog détaille la charge malveillante

Les hôtes concernés incluent les endpoints de développeurs, les workers CI/CD, les workloads cloud, les conteneurs et les déploiements de proxy LiteLLM. Tout hôte ayant installé la wheel malveillante peut avoir exposé ses identifiants accessibles. Ces identifiants pourraient ensuite servir à pousser du code malveillant. Ils pourraient aussi permettre de publier d’autres packages compromis. Le canal horaire d’exécution de code élargit l’usage possible de la charge après son installation. L’impact ne se limite donc pas à la machine qui exécute une application utilisant LiteLLM. Il concerne également des environnements techniques où Python démarre pour d’autres tâches. Cette portée explique la recommandation d’isoler les environnements affectés.

Guy Korolevski explique qu’une seule installation compromise peut donner à un attaquant la possibilité de pousser du code malveillant en aval. Le chercheur en sécurité chez JFrog insiste aussi sur la différence entre un dépôt source sain et l’artefact réellement installé. Selon lui, les équipes doivent vérifier la wheel exacte et contrôler les versions avant leur arrivée dans un build. Cette distinction est centrale dans le cas de LiteLLM 1.107.0, car les sept wheels contiennent les fichiers supplémentaires. Le contrôle doit donc porter sur l’artefact distribué, ainsi que sur la version sélectionnée dans les environnements de construction et d’exécution.

Les environnements doivent être reconstruits

Les prochaines mesures concernent tout environnement dans lequel LiteLLM 1.107.0 s’est exécutée. JFrog recommande de l’isoler et de le reconstruire. Tous les identifiants accessibles doivent également être renouvelés. Cette consigne couvre les identifiants cloud, SSH, CI/CD et navigateur collectés par la charge utile. Elle concerne aussi les jetons des outils de codage par IA. Guy Korolevski formule directement cette recommandation pour les cas où la version 1.107.0 s’est exécutée quelque part dans l’environnement. Le renouvellement vise à limiter l’usage ultérieur de secrets potentiellement exposés. La reconstruction vise les hôtes et environnements concernés par cette installation malveillante.