LiteLLM 1.107.0 piégé sur PyPI : voleur de secrets

Ce qui se passe

Le 21 octobre 2026, la version LiteLLM 1.107.0 a été publiée sur PyPI avec un voleur d'identifiants et une porte dérobée à l'intérieur. Les sept wheels (Linux, macOS, Windows) sont touchées, ainsi que les images Docker v1.107.0, latest, main-latest et main-stable de Docker Hub (berriai/litellm) et de GHCR (ghcr.io/berriai/litellm). Le code malveillant n'existe pas dans le dépôt GitHub public. LiteLLM a confirmé la compromission dans un rapport d'incident ; l'analyse technique est de SafeDep.

Sont sains : 1.106.2, 1.107.0rc1, 1.107.0rc2, ainsi que litellm-proxy-extras==0.4.110 et litellm-enterprise==0.1.78, que la 1.107.0 épingle.

Comment ça a atteint PyPI

Selon LiteLLM, l'attaquant détenait les identifiants GitHub CLI de trois développeurs, probablement tirés des journaux d'un déploiement interne exposé à Internet. Avec le jeton d'un propriétaire d'organisation, il a contourné la protection de branche et pointé le workflow de publication, privé, vers un dépôt sosie, Berri-AI/litellm. Le pipeline officiel a ensuite tout fait lui-même.

La seule trace visible dans l'archive source est une ligne data = "cook" dans la section maturin de pyproject.toml ; le dossier cook/ lui-même n'y figure pas.

Horaires du 21 octobre (UTC) : 10:08 protection contournée · 11:39 à 11:40 sept wheels envoyées · 11:46 images Docker publiées · 13:23 version retirée de PyPI · 13:40 le compte GitHub letters9813 renvoie 404 · 14:20 tags Docker retirés ou repointés vers des images saines.

Ce que le paquet installe

Trois fichiers dans site-packages : cook.pth, cook.py et sitecustomize.py. Python exécute au démarrage les lignes import d'un fichier .pth et importe sitecustomize : le code tourne donc dans tout processus Python de la machine (application, pip, serveurs de langage d'éditeur, CI), même sans import litellm.

• Le voleur (cook.py) collecte : clés ~/.ssh/*, mots de passe de Chromium et Firefox, historiques de navigateur et de shell, ~/.aws, profils Azure, gcloud, ~/.kube/config, ~/.docker/config.json, hosts.yml de gh, rclone.conf, ~/.netrc, fichiers .pem, .key, .pfx, .p12, auth.json de Composer, secrets de CI (GitLab runner, Jenkins, .vault-token, Terraform), configurations d'outils d'IA (Claude Code, Cursor, Windsurf, Copilot, Gemini CLI, Codex, Aider, Zed, jeton Hugging Face…), variables d'environnement des autres processus, tables LiteLLM_CredentialsTable et LiteLLM_ProxyModelTable (clés des fournisseurs LLM du proxy) et identifiants du service de métadonnées AWS. Le tout est chiffré puis envoyé en POST à www.litellm[.]dev/healthcheck.
• La porte dérobée (sitecustomize.py) lance un démon détaché, verrou /tmp/remote_code_loader.lock. Toutes les heures, il lit une adresse dans un fichier domain.txt d'un dépôt de l'attaquant, relance le voleur, puis télécharge http://<domaine>/codepy et l'exécute.

Le compte GitHub de l'attaquant a disparu, la porte dérobée ne trouve donc plus d'adresse. Mais les machines qui l'ont fait tourner avant ont pu exécuter une seconde charge : SafeDep n'a pas pu récupérer l'adresse du serveur.

Indicateurs à chercher

• Domaine : www.litellm[.]dev ; en-tête X-Token: XWiA8gZNa7NcX2XRoAEb ; requêtes de processus Python vers 169.254.169.254
• Fichiers : cook.pth, cook.py, sitecustomize.py dans site-packages ; /tmp/.pc_once_72129118c59f5636c0bb ; /tmp/remote_code_loader.lock ; variable PRIVCOLLECT_ACTIVE=1
• Image Docker (index) : sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e
• Archive source litellm-1.107.0.tar.gz : 2befe2a79fb4fbbd9a543b5b40b530c8cffa8771bab22b8fb22b2e4ae3b1f819

462d0c9f67ca522d9e0e4acd245e90b36ce0d5353604a66bb7c43a1ec4a6fcf7  manylinux_2_28_x86_64
668169d35b87bf51324080390b1b1c5ab12bd335cfe5f1a99e3689abd5e02ae6  manylinux_2_28_aarch64
1bbce8caa94f01c0aaa0b7ddae51553a8a32e1ce53d96d44fe583272aff7ad00  musllinux_1_2_x86_64
c2e32d0ce2548aa662c18bf5001911a79fe5b30cf8357132275add02fdcde054  musllinux_1_2_aarch64
7598727f209d717041db37f7dca271d3a7d328a279890e0e1d55375729aeb86d  macosx_10_12_x86_64
0aaf7ba346d41ef2f40390436738b001180d5a1c03aa093f121078a9969d9a1a  macosx_11_0_arm64
12d4ccc5c6f8d35cf4f2cf233b7f3e418e863e657d81ff5f5fc9e210005b9484  win_amd64

Comment s'y prendre

1. Chercher litellm==1.107.0 dans les fichiers de verrouillage, les environnements virtuels, les images et les conteneurs en cours d'exécution.
2. Chercher les fichiers indicateurs ci-dessus sur chaque machine concernée.
3. Traiter une machine touchée comme compromise : désinstaller, puis renouveler tout ce qui s'y trouvait (clés SSH, jetons cloud et CI, clés des fournisseurs LLM, jetons d'outils d'IA).
4. Reconstruire les images et les environnements ; rester sur 1.106.2 en attendant une version saine.

Source : SafeDep, 21 octobre 2026. Source en anglais. Complément : The Hacker News.