La compromission de LiteLLM 1.107.0 injecte un voleur d'identifiants via la chaîne de construction

Le 21 octobre 2026, des chercheurs en sécurité ont identifié que la version 1.107.0 de LiteLLM, publiée sur le Python Package Index (PyPI), contenait un voleur d'identifiants et une porte dérobée permettant l'exécution de code à distance. Le paquet compromis a affecté les environnements Linux, macOS et Windows en injectant des fichiers malveillants directement dans le répertoire site-packages de Python lors de l'installation. PyPI a depuis retiré cette version, mais l'incident met en lumière des risques importants pour l'intégrité de la chaîne d'approvisionnement logicielle.

Ce qui s'est passé

L'attaque visait le processus de construction de LiteLLM, une bibliothèque populaire pour l'intégration de grands modèles de langage. Lorsque les développeurs installaient la version 1.107.0 via pip, trois fichiers spécifiques étaient placés dans leur dossier site-packages : cook.pth, cook.py et sitecustomize.py. Contrairement aux logiciels malveillants classiques qui nécessitent des instructions d'import explicites pour s'exécuter, ces fichiers s'exécutaient automatiquement chaque fois qu'un processus Python démarrait sur la machine hôte. Cela signifiait que même les applications n'utilisant pas directement LiteLLM pouvaient déclencher le code malveillant si elles partageaient le même environnement Python.

Le dépôt de code source amont sur GitHub ne contenait pas ces fichiers malveillants. L'analyse médico-légale a révélé que la distribution source (sdist) de la version 1.107.0 incluait un fichier pyproject.toml modifié avec une ligne injectée : data = "cook". Cette instruction ordonnait à l'outil de construction, maturin, de copier un dossier caché cook/ dans le paquet wheel final. La sdist elle-même omettait le dossier cook/, rendant l'injection visible uniquement dans les wheels binaires compilés distribués via PyPI. Les versions 1.106.2, 1.107.0rc1 et 1.107.0rc2 ont été confirmées comme propres, tout comme les paquets associés litellm-proxy-extras et litellm-enterprise.

Comment cela fonctionne

La charge utile malveillante opérait via deux mécanismes principaux déclenchés par le comportement de démarrage de Python. Premièrement, le fichier cook.pth contenait la commande import cook. Python exécute automatiquement les instructions d'import trouvées dans les fichiers .pth situés dans site-packages au démarrage. Cela faisait tourner cook.py dans chaque processus Python, y compris les IDE, les pipelines CI et les services en arrière-plan. Le script collectait des données sensibles telles que les clés SSH, les identifiants cloud, les secrets CI/CD, les mots de passe du navigateur et les jetons des fournisseurs de LLM. Il chiffrait ensuite ces données et les exfiltrait vers un domaine contrôlé par les attaquants, www.litellm[.]dev.

Deuxièmement, le fichier sitecustomize.py établissait une porte dérobée persistante. Ce script lançait un démon en arrière-plan qui vérifiait chaque heure un fichier GitHub distant pour obtenir une adresse de serveur. En recevant des instructions, le démon téléchargeait et exécutait du code supplémentaire depuis ce serveur. Les attaquants obfusquaient le code dans cook.py en utilisant l'encodage base64 et la compression zlib, enveloppant environ 61 Ko de code Python dans une seule ligne d'exécution pour échapper aux analyses statiques simples.

Les preuves médico-légales suggèrent que la compromission s'est produite dans la pipeline de publication privée du mainteneur plutôt que via une exécution publique de GitHub Actions. Les horodatages sur les wheels compilés indiquaient des constructions natives distinctes pour macOS, Linux et Windows, cohérentes avec un environnement CI local ou privé. L'absence d'attestations de provenance sur PyPI et la divergence entre le tag git et la distribution source renforcent la théorie selon laquelle un attaquant a modifié le code source avant son entrée dans le système de construction, possiblement en utilisant des identifiants compromis ou une branche privée.

Détails clés

• Version affectée : Seule LiteLLM 1.107.0 sur PyPI était compromise ; les versions précédentes et les candidats de release sont sûrs.
• Méthode d'injection : Un fichier pyproject.toml modifié a ordonné à l'outil de construction maturin d'inclure un répertoire cook/ malveillant dans le wheel.
• Persistance : Le logiciel malveillant utilisait cook.pth et sitecustomize.py pour s'exécuter automatiquement au démarrage de tout processus Python.
• Vol de données : Le voleur ciblait les clés SSH, les identifiants cloud, les jetons IA et les mots de passe du navigateur, les envoyant vers www.litellm[.]dev.
• Divergence de source : Le tag git v1.107.0 pointait vers un commit avec la version 1.108.0, tandis que la sdist correspondait à un commit ultérieur avec des modifications manuelles pour rétablir la version et ajouter la charge utile.
• Impact sur les plateformes : Les sept variantes de wheels (Linux, macOS, Windows) contenaient les fichiers malveillants, garantissant une infection multiplateforme.

Pourquoi c'est important

Cet incident démontre que la vérification du code source sur des dépôts publics comme GitHub est insuffisante pour garantir la sécurité de la chaîne d'approvisionnement. Les attaquants peuvent intercepter le processus de construction ou modifier les artefacts après le tagging du source mais avant la publication. Pour les équipes d'ingénierie, cela signifie que faire confiance à un paquet uniquement sur la base de l'historique de son dépôt est risqué. L'utilisation de fichiers .pth pour réaliser l'exécution de code sans imports explicites contourne de nombreux contrôles de sécurité standard qui recherchent des appels de fonctions dangereux dans le code applicatif.

De plus, le manque d'attestations de provenance sur PyPI a rendu difficile la vérification immédiate de l'origine des wheels compilés. Sans preuve cryptographique liant l'artefact construit à un processus de build spécifique et vérifié, les défenseurs doivent compter sur une analyse médico-légale réactive. Ce délai permet aux paquets malveillants de rester en circulation plus longtemps, augmentant la fenêtre d'exposition pour les organisations qui automatisent les mises à jour des dépendances.

Ce que vous pouvez faire

• Désinstallez immédiatement LiteLLM version 1.107.0 si elle est présente dans un environnement : pip uninstall litellm==1.107.0.
• Faites pivoter tous les identifiants, clés API et secrets stockés sur les machines ayant pu installer la version compromise.
• Vérifiez la présence de cook.pth, cook.py et sitecustomize.py dans votre répertoire Python site-packages.
• Épinglez les dépendances à des versions connues comme bonnes, telles que 1.106.2 ou 1.107.0rc2, jusqu'à ce qu'un correctif vérifié soit publié.
• Activez les vérifications de provenance des dépendances lorsqu'elles sont disponibles et privilégiez les paquets fournissant des métadonnées d'attestation.
• Surveillez les journaux réseau pour détecter les connexions sortantes vers www.litellm[.]dev ou des motifs d'exfiltration de données inhabituels.