Backdoor Litellm : comment TeamPCP a détourné la chaîne d'approvisionnement via Trivy en 2026

Vous avez déjà installé litellm sans vous douter que le paquet pouvait devenir une porte dérobée ? En moins de 24 heures, la version 1.82.7 a permis à l’acteur malveillant TeamPCP de récupérer des clés SSH, des secrets Kubernetes et même des portefeuilles cryptographiques. Selon le rapport ENISA 2025, 38 % des incidents de sécurité en 2024 concernaient la chaîne d’approvisionnement, ce qui montre à quel point la compromission d’un seul paquet Python peut déclencher une cascade d’exfiltrations. Cet article décortique le mécanisme du backdoor litellm, les vecteurs d’injection, l’impact sur les clusters Kubernetes et les actions concrètes à mettre en place dès aujourd’hui.

Comprendre le risque du backdoor litellm dans la chaîne d’approvisionnement

L’attaque repose sur une compromission du workflow CI/CD de litellm, notamment l’utilisation de Trivy pendant la construction des wheels. Deux versions - 1.82.7 et 1.82.8 - ont été publiées le 24 mars 2026, exploiter l’ISC Stormcast du 24 mars 2026 pour anticiper les menaces cyber en France, puis retirées de PyPI dès que la compromission a été détectée. L’objectif principal était de placer un credential harvester capable de balayer les fichiers de configuration (.env), les clés SSH et les jetons de service Kubernetes. En pratique, chaque import de litellm.proxy.proxy_server déclenchait immédiatement le payload, ce qui signifie que tout script Python invoquant litellm était infecté.

“The payload is a three-stage attack: a credential harvester sweeping SSH keys, cloud credentials, Kubernetes secrets, cryptocurrency wallets, and .env files; a Kubernetes lateral movement toolkit deploying privileged pods to every node; and a persistent systemd backdoor (sysmon.service) polling ‘checkmarx[.]zone/raw’ for additional binaries,” - Endor Labs researcher Kiran Raj.

Analyse technique du payload : du harvester de credentials au service systemd

Mécanisme d’injection via le fichier proxy_server.py

Dans la version 1.82.7, le code malveillant a été inséré dans litellm/proxy/proxy_server.py. La logique s’exécute lors de l’import du module, ce qui permet de contourner toute forme d’interaction utilisateur. Le fragment suivant illustre la technique :

# payload inserted in litellm/proxy/proxy_server.py
import base64, subprocess, os
payload = base64.b64decode('aW1wb3J0IHN1YnByb2Nlc3M...')
exec(payload)  # exécute le code malveillant en mémoire

Le malware VoidStealer contourne l’encryption de Chrome et vole votre clé maître

Le payload décodé démarre un orchestrateur qui télécharge un fichier tpcp.tar.gz chiffré depuis le domaine models.litellm.cloud via une requête HTTPS POST. Le fichier contient le harvester et le composant de persistance.

Nouvelle vecteur .pth et exécution silencieuse

La version 1.82.8 introduit un fichier litellm_init.pth placé à la racine du wheel. Les fichiers .pth sont automatiquement traités par le module site.py lors du démarrage de l’interpréteur Python, ce qui rend l’exécution invisible à l’utilisateur. Le code contenu dans le .pth crée un sous-processus qui lance le même payload base64, mais cette fois-ci en arrière-plan, évitant toute trace dans les logs d’import.

“Python .pth files placed in site-packages are processed automatically by site.py at interpreter startup,” - Endor Labs.

Impact sur les environnements Kubernetes et les secrets exposés

Le second volet de l’attaque exploite le toolkit de déplacement latéral Kubernetes. Une fois le harvester installé, il interroge le token du service-account (s’il existe) pour lister les nœuds du cluster. Pour chaque nœud, il crée un pod privilégié qui chroot dans le système d’exploitation hôte, puis dépose un service systemd nommé sysmon.service. Ce service lance un script Python stocké dans ~/.config/sysmon/sysmon.py, qui interroge régulièrement checkmarx.zone/raw pour récupérer des charges utiles additionnelles.

Les conséquences sont multiples :

• Vol de clés SSH et de secrets cloud (AWS, GCP, Azure) stockés dans les ConfigMaps ou Secrets.
• Exfiltration de portefeuilles cryptographiques présents dans les dossiers utilisateurs.
• Création d’un pivot persistant au sein du cluster, rendant la remédiation difficile sans redémarrage complet des nœuds.

Selon JFrog, plus de 1 200 paquets Python ont été compromises entre 2023 et 2025, dont plusieurs ont servi de vecteur à des campagnes similaires.

Mesures d’urgence et bonnes pratiques de défense

Audit des versions et nettoyage

1. Lister les installations : pip list | grep litellm pour identifier les versions 1.82.7 ou 1.82.8.
2. Revenir à une version propre (≥ 1.82.6) : pip install --upgrade litellm==1.82.6.
3. Supprimer les artefacts résiduels : rechercher les fichiers litellm_init.pth, proxy_server.py modifiés et le répertoire ~/.config/sysmon.
4. Vérifier les pods : kubectl get pods -A -o wide | grep privileged pour détecter les pods inattendus.
5. Analyser les logs réseau : filtrer les connexions sortantes vers models.litellm.cloud ou checkmarx.zone.

Renforcement des pipelines CI/CD

• Isoler les outils d’analyse : exécuter Trivy et KICS dans des conteneurs éphémères avec des droits limités.
• Signer les wheels : appliquer la norme PEP 458 et vérifier les signatures avant publication.
• Activer la surveillance de la chaîne d’approvisionnement : intégrer des solutions comme Snyk ou GitGuardian pour détecter les modifications de fichiers sensibles.
• Faire appliquer la politique de moindre privilège sur les runners GitHub Actions, en refusant les permissions de création de pods.

Comparatif des versions litellm - avant et après compromission

Recommandations pour sécuriser la chaîne d’approvisionnement open source

• Adopter le modèle SBOM (Software Bill of Materials) pour chaque build et vérifier la provenance des dépendances.
• Mettre en place une politique de revues de code obligatoire pour tout changement de setup.py ou pyproject.toml.
• Utiliser la vérification de l’intégrité des paquets via cosign ou in-toto afin de garantir que le wheel publié n’a pas été altéré.
• Éduquer les développeurs sur les risques des fichiers .pth et sur la nécessité de limiter les imports dynamiques.
• Surveiller les indicateurs de compromission (IOC) : création de services systemd inhabituels, trafic HTTPS vers des domaines non répertoriés, processus Python sans parent.

En suivant ces bonnes pratiques, vous réduirez considérablement la surface d’exposition de vos environnements CI/CD et de vos clusters Kubernetes. La porte dérobée litellm montre que même les bibliothèques les plus populaires peuvent devenir des vecteurs d’attaque lorsqu’elles sont manipulées dans une chaîne d’approvisionnement non protégée. Restez vigilants, automatisez la détection, et assurez-vous que chaque composant de votre infrastructure possède une traçabilité claire.

“The open source supply chain is collapsing in on itself,” - Gal Nagli, head of threat exposure at Wiz.

Cette mise en garde souligne l’importance d’une défense en profondeur à chaque étape du cycle de vie du logiciel. Le temps de réaction est crucial : chaque minute compte lorsqu’il s’agit d’empêcher la propagation d’un credential harvester à l’échelle d’un cluster. Gardez à l’esprit que la remise en état d’un environnement compromis ne se limite pas à supprimer le paquet : il faut également éradiquer les services persistants, révoquer les secrets exposés et renforcer les contrôles d’accès.

En 2026, la menace persiste, mais les équipes qui adoptent une approche proactive et basée sur les standards (ANSSI, ISO 27001, RGPD) seront mieux armées pour contrer les futures campagnes de TeamPCP. Fraude streaming IA : comment des chansons factices ont généré 10 millions de dollars