L'attaque LiteLLM (24–25 mars 2026)

Le 24 mars 2026, deux versions malveillantes de LiteLLM (v1.82.7 et v1.82.8) ont été publiées sur PyPI suite à la compromission du compte mainteneur du projet. LiteLLM est une interface Python unifiée vers 100+ fournisseurs de modèles LLM (accès via SDK ou proxy MCP). L'attaquant TeamPCP a utilisé un pipeline CI/CD infecté (via Trivy) pour voler le token PyPI du mainteneur, puis a poussé des releases activant un payload de vol de credentials. La v1.82.7 contient un loader dans proxy_server.py qui se déclenche à l'import du proxy, tandis que la v1.82.8 ajoute un fichier .pth (litellm_init.pth) qui s'exécute automatiquement à chaque démarrage de Python.

Une fois lancé, le malware collecte un vaste ensemble d'informations sensibles (variables d'environnement, clés SSH, jetons cloud AWS/GCP/Azure, secrets Kubernetes, fichiers de configuration, historiques shell, wallets crypto, etc.). Il chiffre les données (AES-256 + RSA-4096) et les exfiltre vers models.litellm.cloud. Ensuite, il installe une persistance locale (agent "System Telemetry Service" en ~/.config/sysmon/, unité systemd sysmon.service) qui contacte périodiquement checkmarx.zone/raw pour charger de nouveaux payloads. En outre, si un token Kubernetes privilégié est disponible, le malware crée des pods node-setup-* dans kube-system pour propager le backdoor sur chaque nœud. Cette attaque est particulièrement grave : LiteLLM centralise des clés et tokens très critiques (MCP, API LLM, cloud, DB, etc.), de sorte que la compromission touche potentiellement l'ensemble de l'infrastructure AI (poste développeur, CI, serveurs, clusters Kubernetes).

Contexte et chronologie

L'attaque s'inscrit dans la même campagne TeamPCP qui a ciblé Trivy (19 mars) et Checkmarx/KICS (23 mars). Les événements clés du 24 mars 2026 sont :

• 10:39 UTC – Publication sur PyPI de LiteLLM v1.82.7 malveillante (pas de tag Git correspondant).
• 10:52 UTC – Publication sur PyPI de LiteLLM v1.82.8 malveillante, incluant litellm_init.pth qui s'exécute au démarrage de Python.
• Peu après 11:00 UTC, la compromission est révélée publiquement (GitHub Issues, threads HackerNews) et PyPI met en quarantaine le projet. L'équipe LiteLLM retire les tokens, confirme l'origine via Trivy, et prévient les utilisateurs.
• 14:00 UTC – Mise à jour du blog LiteLLM et mails d'urgence recommandant la rotation des credentials.

Les sources principales (LiteLLM, Snyk, Datadog, Register, BleepingComputer, Upwind, Wiz, Comet, Penligent) confirment ces dates.

Description technique de l'exploit

Vecteurs d'entrée et vulnérabilités ciblées

L'attaquant n'a pas exploité une faille d'application LiteLLM, mais a attaqué la chaîne d'approvisionnement :

• Un jeton PyPI a été dérobé via la compromission d'un job CI (scanner Trivy compromis par TeamPCP).
• Avec ce jeton, deux versions LiteLLM ont été publiées sans passer par le dépôt GitHub officiel (aucune release GitHub associée).
• Il n'y a pas de vulnérabilité traditionnelle à patcher dans LiteLLM lui-même : c'est la confiance dans le dépôt PyPI qui a été brisée.

Chaîne d'attaque détaillée

Les versions malveillantes diffèrent par leur mécanisme d'attaque :

• LiteLLM v1.82.7 : le code malicieux (payload) est injecté dans le fichier litellm/proxy/proxy_server.py. Ce code est encodé en base64 et exécuté dès que le module litellm.proxy est importé ou que l'on exécute la commande litellm --proxy. Il était donc nécessaire que l'application cliente utilise explicitement la fonctionnalité proxy pour déclencher l'infection.
• LiteLLM v1.82.8 : en plus du payload de 1.82.7, un nouveau fichier litellm_init.pth est ajouté. En Python, le module site exécute automatiquement toute ligne de code contenue dans un .pth lors de chaque démarrage de l'interpréteur. Du coup, l'installation de ce paquet infecté suffit à exécuter le payload à CHAQUE appel à python, pytest, ou même un second pip install dans le même environnement. C'est ce qui a fait basculer l'attaque d'un incident classique (import-triggered) à un incident "au plus bas niveau". Aucune interaction ultérieure n'était requise dans la v1.82.8 compromise pour exécuter le code malveillant.

Une fois le code malveillant chargé, la chaîne d'attaque se décompose comme suit :

1. Collecte des secrets : le payload final balaye l'hôte pour voler des informations sensibles :
   • Variables d'environnement et fichiers .env (API keys, tokens).
   • Clés SSH (~/.ssh/id_*, authorized_keys) et configurations SSH (known_hosts).
   • Identifiants de fournisseurs cloud :
     • AWS : clés dans ~/.aws/, métadonnées IMDSv2, ECS container creds, secrets manager (ListSecrets, GetSecretValue via SIGv4).
     • GCP : credentials gcloud et ${GOOGLE_APPLICATION_CREDENTIALS}.
     • Azure : fichier ~/.azure/ et vars (AZURE_*).
   • Secrets Kubernetes : tokens de service accounts, fichiers kubeconfig/admin.conf, et appel direct à l'API pour lister tous les secrets de tous les namespaces.
   • Fichiers d'infra/CI/CD : configs Docker (~/.docker/config.json), Terraform (*.tfstate), configs Ansible/Helm, Jenkins/Travis/Drone YAML.
   • Credentials de base de données : PostgreSQL, MySQL, Redis, MongoDB, LDAP, .netrc, etc.
   • Données d'application : historiques Shell (bash_history, psql_history, etc.), fichiers .git-credentials, webhooks Slack/Discord, wallet crypto (Bitcoin, Ethereum, Cardano, etc.).
   • Tout contenu ressemblant à un secret : recherche de regex api_key, apikey, access_token, etc.
2. Chiffrement et exfiltration : Les données volées sont bundlées dans une archive tpcp.tar.gz. Un schéma hybride est utilisé : on génère une clé de session AES-256 pour chiffrer les données (avec PBKDF2), puis cette clé AES est chiffrée avec une clé RSA-4096 publique embarquée. Le tout est ensuite exfiltré par une requête HTTPS POST vers https://models.litellm.cloud, avec l'en-tête X-Filename: tpcp.tar.gz pour masquer la nature du trafic. Cette infrastructure models.litellm.cloud (fausse URL, pas associée à LiteLLM) est utilisée comme serveur de collecte des attaquants.
3. Persistance locale : Le malware installe un agent persistant dans le home utilisateur :
   • Il crée ~/.config/sysmon/sysmon.py (backdoor Python) et une unité systemd ~/.config/systemd/user/sysmon.service qui lance sysmon.py en tâche de fond à chaque démarrage de session. Ce service se relance automatiquement toutes les 10 secondes (stdout/stderr à nul) et est activé par systemctl --user enable --now.
   • Ce backdoor fait du « beaconing » : au premier lancement, il attend 5 minutes, puis toutes les ~50 minutes va chercher un nouveau payload sur https://checkmarx.zone/raw. S'il y en a un, il télécharge dans /tmp/pglog, donne les droits d'exécution, et l'exécute. Ainsi, les attaquants peuvent injecter de nouveaux binaires à volonté dans les systèmes infectés.
4. Propagation / Worm Kubernetes : Si un token Kubernetes avec RBAC élevé est trouvé, le malware utilise l'API K8s pour propager le backdoor :
   • Il liste tous les nœuds du cluster, puis déploie sur chacun un pod node-setup-<node> en hostPID: true, hostNetwork: true, avec montage du système de fichiers hôte (/host).
   • Chaque pod alpine:latest privilégié utilise chroot /host pour installer la même persistance sysmon sur l'hôte.
   • Cela crée un effet de ver : une seule machine compromise suffit à infecter tout le cluster Kubernetes.

Ces étapes rendent l'attaque extrêmement robuste et furtive. Elle ne se limite pas à voler un jeton PyPI ou un seul secret : il s'agit d'un malware conçu pour survivre, se propager et escalader dans les environnements modernes (dev local, CI, cloud, conteneurs, Kubernetes).

Surface d'attaque IA spécifique

Contrairement aux menaces IT classiques, LiteLLM vise l'écosystème IA/ML. Voici les points clés de la surface d'attaque IA :

Proxy MCP et Gateway LLM : LiteLLM peut fonctionner comme un serveur MCP (Model + Chat Proxy) qui permet à divers agents (Claude, Cursor, agents RAG, etc.) d'accéder à n'importe quel LLM via une API unifiée. Il gère les clés des fournisseurs, le routage, l'authentification et le logging pour les modèles. C'est donc un point central dans les architectures IA. Si cette couche est compromise, l'attaquant a potentiellement accès aux clés de 100+ modèles (Azure, OpenAI, Anthropic, Vertex, etc.) et aux données transmises.

Dépendances transitives dans les frameworks d'agents : De nombreux frameworks d'agents IA (CrewAI, Opik, Mem0, Guardrails, Agno, Camel-AI, etc.) incluent LiteLLM en dépendance directe ou transitive. Ces outils sont massivement téléchargés (5–6 millions de téléchargements mensuels pour certains). Un simple pip install some-agent peut entraîner l'installation de LiteLLM infecté sans que l'utilisateur ne s'en rende compte, surtout dans des chaînes CI/CD automatiques.

Position dans la pile sécurité : LiteLLM gère des secrets hautement sensibles — clés cloud, tokens API, configs d'infrastructure, logs de prompts, etc. LiteLLM se situe au plus près des secrets les plus critiques de la pile : credentials cloud, clés de fournisseurs de modèles... Une compromission ici est un problème de plan de contrôle pour l'infrastructure IA. Le tableau ci-dessous illustre des cas d'usage typiques :

En pratique, un attaquant n'a pas besoin d'accéder à tous ces environnements : la compromission de LiteLLM sur un seul poste développeur ou un unique job CI peut suffire à voler un ensemble considérable de clés. Le « blast radius » est donc immense. Chaque machine ou conteneur qui a installé LiteLLM 1.82.7/1.82.8 doit être traité comme un événement d'exposition complète de credentials. La centralisation que LiteLLM fournit pour les applications IA rend l'attaque particulièrement redoutable dans le domaine IA.

Impact opérationnel et risques

Les risques associés sont sévères :

Exfiltration de credentials : Comme décrit, tout secret stocké ou accessible par le processus LiteLLM malveillant a vraisemblablement été volé. Cela inclut les variables d'environnement CI/CD, les tokens d'accès cloud (AWS/GCP/Azure), les clés SSH privées, les accès Kubernetes et base de données, etc. Les attaquants peuvent reconquérir les comptes exposés et l'intelligence des opérations.

Persistance et présence continue : Grâce au backdoor systemd (sysmon) et au C2 checkmarx.zone, les attaquants disposent d'un accès permanent et peuvent télécharger de nouveaux outils (ransomware, mineur crypto, etc.) ultérieurement. Le remplacement du domaine de Checkmarx/OpenVSX et la création d'un domaine models.litellm.cloud montrent leur capacité à coordonner plusieurs attaques en cascade.

Mouvement latéral : Dans un cloud ou cluster Kubernetes, l'attaquant peut établir une présence sur plusieurs nœuds (via les pods node-setup-*) et potentiellement atteindre des ressources sensibles sur le réseau (serveur de métadonnées, API d'orchestrateur).

Secours/Résilience : Puisque LiteLLM peut être déployé dans divers contextes (serveur, cloud VM, container), la présence du malware est difficile à éradiquer. Certaines versions 1.82.6 ou images Docker officielles non infectées restent sûres, mais il faut vérifier toutes les traces du code malveillant.

Risques réputationnels et de conformité : Un tel incident peut exposer l'entreprise à des violations de données (PII dans env .ENV, clés de clients) et à des obligations de notification. Le fait que l'attaque cible la chaîne d'approvisionnement accentue les sanctions (pannes de production, partenariats détruits).

En résumé, il s'agit d'une campagne sophistiquée de ransomware-like infostealer mais ciblant un composant IA stratégique. Les organisations utilisant LiteLLM ou ses dépendances doivent craindre un compromis complet de leur environnement.

Actions immédiates et mesures de remédiation

En cas de suspicion d'attaque LiteLLM, voici les actions d'urgence prioritaires :

1. Identifier l'exposition : Détecter toutes les installations de LiteLLM v1.82.7/1.82.8. Par exemple, exécuter pip show litellm sur les machines/dev/test containers, ou rechercher dans les logs de build (grep -R "litellm==1.82.7" ...).
2. Isoler les systèmes infectés : Couper l'accès réseau des machines compromises (désactiver internet, réduire les firewalls/groupe de sécurité). Sur Kubernetes, isoler les pods suspects. Bloquer les domaines malveillants (DNS/hosts models.litellm.cloud, checkmarx.zone) pour empêcher toute exfiltration supplémentaire.
3. Rotation immédiate des credentials : Révoquer sans attendre toutes les clés/jetons potentiellement exposés, sur la base du principe que tous ont été compromis. Concrètement :
   • Générez de nouvelles clés d'accès pour tous les comptes cloud (AWS IAM, GCP Service Accounts, Azure AD) et remplacez les anciennes.
   • Recréez clés SSH d'accès aux serveurs et configurations VPN.
   • Regénérez jetons GitHub/GitLab, CI/CD (Jenkins, Travis), Docker registry, PyPI, npm, etc.
   • Changez les mots de passe des bases de données et stockez-les dans un vault.
   • Informez en urgence les équipes concernées de déployer ces nouvelles clés.
4. Nettoyage et patching :
   • Désinstallez LiteLLM v1.82.7/1.82.8 partout (pip uninstall litellm) et purgez le cache pip (pip cache purge).
   • Installez la version propre v1.82.6 sur les environnements concernés, ou passez aux images Docker officielles LiteLLM (sans dépendance PyPI compromise).
   • Recherchez et supprimez les artefacts malveillants : fichiers litellm_init.pth, ~/.config/sysmon/sysmon.py, /tmp/pglog, /tmp/.pg_state. Sur Kubernetes, supprimez tous les pods node-setup-*.
   • Vérifiez les scripts de déploiement. Dans vos pipelines CI/CD, fixez (pin) la version de LiteLLM à 1.82.6 (ou supprimez-la si possible) et passez tout GitHub Actions Git tags à des commits SHA immuables.
5. Audit complet : Passez en revue tous les journaux de connexion, CloudTrail, logs Kubernetes, logs réseau pour détecter d'éventuelles actions non autorisées (ex. connexions anormales, secrets lus, pods créés). Recherchez les IOC connus (voir ci-dessous). Envisagez de refaire les images machine/containers à partir de sources « clean ».
6. Renforcement post-incident : Revoyez la configuration CI/CD pour retirer l'usage de Trivy compromis ou autres outils vulnérables. Activez l'authentification multifacteur sur tous les comptes mainteneurs. Envisagez de faire auditer le pipeline par des tiers, et de collaborer avec le centre incident de LiteLLM ou PyPA si besoin.

Checklist opérationnelle priorisée

• (P1) Confirmer l'installation des versions malveillantes (scanner virtualenv, containers, runners).
• (P1) Isolement immédiat (couper accès internet/domaine malveillant).
• (P1) Rotation complète des secrets (cloud, SSH, CI/CD, base).
• (P2) Désinstallation LiteLLM malveillant + purge cache, détection Sysmon et pods K8s.
• (P2) Audit des logs et authentifications (Kubernetes, CloudTrail, SSH) pour déceler des accès illicites.
• (P2) Mise à jour des workflows (pin GitHub Actions, mettre à jour dépendances).
• (P3) Surveillance IDS/EDR centrée sur les IOC et comportements anormaux (voir ci-dessous).
• (P3) Documentation et revue post-incident, communication aux équipes légales/RH si nécessaire.

Détection et indicateurs de compromission (IoC)

Les indicateurs d'infection comprennent :

Fichiers suspects :

• litellm_init.pth présent dans un répertoire site-packages.
• Scripts persistants : ~/.config/sysmon/sysmon.py et service sysmon.service.
• Fichiers temporaires : /tmp/pglog, /tmp/.pg_state (flag de l'état C2).

Domaines réseau : Tout trafic sortant vers models.litellm.cloud ou checkmarx.zone (ou checkmarx[.]zone). Des sources citent aussi scan.aquasecurtiy.org (typosquat de Aqua) et *.icp0.io/*.trycloudflare.com comme parties de la campagne.

Processus anormaux : Apparition de python qui exécute du code base64 (examen des commandes ps ou outils EDR). Lecture intense de répertoires de clés secrets (~/.aws, ~/.kube, ~/.ssh, etc.). Requêtes fréquentes vers les metadata (169.254.169.254) sans logique métier.

Pod/Kubernetes : Création de pods nommés node-setup-* dans kube-system avec image Alpine privilégiée.

Logs CI/CD : Jobs GitHub/CI exécutant pip install liteLLM==1.82.7/1.82.8. Logs de build affichant du code encodé base64.

Scripts de détection

# Recherche le fichier litellm_init.pth sur l'ensemble du système
echo "[*] Recherche de litellm_init.pth sur le système..."
sudo find / -type f -name 'litellm_init.pth' -print 2>/dev/null \
    && echo "Fichier litellm_init.pth trouvé" || echo "Aucun fichier litellm_init.pth détecté."

# Vérification de la connectivité DNS/HTTP vers les IoC connus
for dom in models.litellm.cloud checkmarx.zone; do
    if host "$dom" >/dev/null 2>&1; then
        echo "⚠ Domaine $dom résolu (alerte potentielle)."
    else
        echo "✅ Domaine $dom non résolu."
    fi
done

# Surveiller les connexions réseau vers les domaines IoC
grep -R "models\.litellm\.cloud" /var/log && echo "Trace d'IoC models.litellm.cloud détectée."

# Script Python pour scanner les IOC sur un hôte
import socket, subprocess
domains = ["models.litellm.cloud", "checkmarx.zone"]
for dom in domains:
    try:
        ip = socket.gethostbyname(dom)
        print(f"[!] Le domaine {dom} ({ip}) est résolu - vérifier les connexions actives.")
    except socket.gaierror:
        print(f"[OK] {dom} non résolu ou bloqué.")
# Vérification de processus Python suspects
try:
    netstat = subprocess.check_output(['netstat','-tunp']).decode()
    if any(d in netstat for d in domains):
        print("[!] Trafic suspect détecté vers un IoC.")
except Exception:
    pass

Recommandations long terme

Au-delà de la réponse immédiate, il est crucial de renforcer la sécurité pour résister à de futures attaques supply-chain :

Réduction de la confiance implicite : Aucun service tiers (GitHub Actions, packages PyPI) ne doit être accepté implicitement. Imposer la signature des packages (Sigstore/TUF), valider les manifests avant exécution, auditer l'usage des libs externes. Pinner les workflows CI sur des commits SHA, et préférer les actions/outils open-source audités.

Sécurisation CI/CD :

• Segmenter les runners CI dans un réseau privé avec accès restreint aux secrets.
• Utiliser des variables d'environnement restreintes (vaults) au lieu de stocker des clés dans les pipelines.
• Exécuter les analyseurs de dépendances (Trivy, etc.) dans des environnements verrouillés (images conteneurisées éphémères).
• Alerter sur les changements inattendus de tag (comme décrit par Aqua/Trivy – cf. piratage du tag @v2).

Inventaire des dépendances (SBOM) : Maintenir un Software Bill of Materials de toutes les dépendances, y compris transitives. Mener des revues de sécurité régulières des bibliothèques critiques pour l'IA. Les équipes de DevOps doivent connaître quelles versions de LiteLLM (et autres libs LLM) sont utilisées dans les clusters.

Least privilege et politique de secrets :

• Sur cloud, privilégier les rôles IAM à permissions minimales ; désactiver l'IMDS sur les workloads si pas utilisé.
• Dans Kubernetes, limiter les comptes de service (pas de token par défaut sans nécessité).
• Sur l'infrastructure, stocker les secrets dans un gestionnaire spécialisé (HashiCorp Vault, AWS Secrets Manager) plutôt que dans des fichiers.
• Utiliser l'authentification à jetons éphémères (OIDC) dans CI/CD.

Monitoring comportemental : Mettre en place des mécanismes de détection au runtime (EDR / CNAPP / CSPM) qui repèrent les comportements suspects (e.g. exfiltration de grands volumes de données chiffrées, création de pods Kubernetes inattendus, etc.). Par exemple, surveiller toute opération Python qui lit massivement ~/.aws, ~/.ssh, ~/.kube, etc.

Tests et drills : Effectuer des exercices de simulation d'incident (table-top, drills sur table). S'assurer que les équipes savent appliquer rapidement la checklist ci-dessus en cas de nouvelle alerte.

Ces recommandations font écho aux leçons tirées de Trivy/KICS : un attaquant exploite une faille de posture (confiance excessive aux composants populaires) plus qu'une vulnérabilité technique isolée. Elles doivent être appliquées en maintenant un suivi continu des menaces dans l'écosystème open-source de l'IA.

Exemples de code en sandbox et playbooks

Avertissement éthique : Les extraits suivants sont inoffensifs et réservés à un environnement de test ou éducatif. Ne jamais exécuter du code malveillant dans un contexte réel.

Simulation d'un .pth malveillant (sandbox) :

# Exemple de contenu de litellm_init.pth (ne fait rien de mal)
import os, base64
data = os.environ.get('TEST_SECRET', 'aucun secret trouvé')
print("[Sandbox .pth] Clé trouvée :", data)

Ce script s'exécute automatiquement au démarrage de Python dans l'environnement de test. Il illustre le mécanisme d'exécution d'un fichier .pth (bien qu'ici il ne fasse que lire une variable TEST_SECRET). En conditions réelles, le malware effectuerait la collecte/exfiltration à cette étape.

Script de détection et IoC :

#!/bin/bash
# Scanner rapide pour IoC LiteLLM

echo "[*] Scannage du système pour LiteLLM compromis..."
find / -type f -name 'litellm_init.pth' 2>/dev/null && \
  echo "⚠ litellm_init.pth détecté !" || echo "Aucun fichier litellm_init.pth trouvé."

# Check des process Python suspects
pgrep -fa python | grep -E "(base64|pglog)" && \
  echo "⚠ Processus Python suspect détecté" || echo "Pas de processus Python suspect."

# Scan DNS pour domaines malveillants
for dom in models.litellm.cloud checkmarx.zone; do
  if dig +short $dom | grep -q '[0-9]\.'; then
    echo "⚠ Domaine accessible : $dom"
  else
    echo "[OK] $dom non résolu"
  fi
done

Playbook de rotation automatisée (exemple Ansible) :

# Playbook Ansible : Rotation des clés AWS d'un utilisateur critique
- hosts: localhost
  vars:
    user_name: "devOpsUser"
    old_key_id: "INSERER_ANCIEN_ID"
  tasks:
    - name: Créer une nouvelle clé d'accès AWS
      aws_iam_access_key:
        user_name: "{{ user_name }}"
        state: present
      register: new_key

    - name: Supprimer l'ancienne clé d'accès AWS
      aws_iam_access_key:
        user_name: "{{ user_name }}"
        access_key_id: "{{ old_key_id }}"
        state: absent

    - name: Afficher la nouvelle clé pour mise à jour
      debug:
        msg: >
          Nouvelle clé AWS créée (ID={{ new_key.access_key.access_key_id }}).
          Veuillez mettre à jour vos applications et pipelines pour utiliser cette clé.

Tableau comparatif des mesures

Mesures de remédiation et leur effet (Cloud vs On-Premise) :

Conclusion

L'incident LiteLLM met en lumière les risques inédits des chaînes logicielles AI. Il s'agit d'une attaque multistade et multivecteur qui exploite à la fois le ciblage de l'écosystème IA (proxies LLM, MCP, frameworks) et les failles de posture dans les pipelines de production. Les organisations doivent maintenant effectuer une remédiation urgente (rotation massive de credentials, nettoyage complet) tout en repensant leur architecture de confiance autour des outils AI.

L'attaque a déjà fait l'objet de rapports officiels (LiteLLM, PyPA) et de nombreuses analyses techniques (Snyk, Upwind, Datadog, Wiz, etc.), toutes datées du 24–25 mars 2026. Les mesures énumérées dans cet article sont basées sur ces sources primaires et résument les meilleures pratiques à court terme et à long terme pour mitiger ce type de menace.

Sources : Publications et rapports du 24-25 mars 2026 — LiteLLM official blog, Snyk, NetSPI, Datadog, BleepingComputer, The Register, Wiz, Comet, Stéphane Robert, Penligent.