Points clés

Ce que tu dois retenir :
  • LiteLLM 1.82.7 et 1.82.8 (24 mars 2026) contenaient du code malveillant
  • L’attaque visait à voler des clés API et données de configuration
  • Verrouille vite tes dépendances Python avec des versions exactes
  • Scanne tes environnements avec pip-audit et safety
  • Configure des alertes pip pour les mises à jour suspectes

Chapô : Le 24 mars 2026, deux versions malveillantes de LiteLLM ont été découvertes sur PyPI. Ce proxy Python utilisé par des millions de devs a été compromis via une attaque supply chain. Nous te montrons comment identifier l’infection, sécuriser ton code et protéger tes projets IA contre ces menaces émergentes.

Qu’est-ce qui s’est passé avec LiteLLM en mars 2026 ?

LiteLLM est un outil proxy puissant utilisé par les développeurs IA du monde entier pour standardiser les appels aux grandes familles de modèles : OpenAI, Claude, Cohere, Hugging Face, Ollama, etc. Au lieu de jongler avec des dizaines de SDK différents, tu écris une seule requête et LiteLLM la traduit pour n’importe quelle plateforme. C’est simple, c’est efficace, et c’est justement pour ça qu’il est devenu un maillon critique dans la chaîne de dépendances de milliers de projets.

Le 24 mars 2026, deux versions malveillantes ont été publiées sur PyPI (le dépôt officiel Python) : LiteLLM 1.82.7 et 1.82.8. Un attaquant a réussi à compromettre les droits de publication sur le paquet, probablement via une clé API volée ou un compte développeur piraté. Les deux versions contenaient un code injecté qui tentait de :

  • Voler tes clés API (OpenAI, Claude, Anthropic, etc.)
  • Exfiltrer les fichiers de configuration contenant tes données sensibles
  • Envoyer les informations à un serveur de commande et contrôle
  • Potentiellement installer d’autres charges malveillantes en arrière-plan

Heureusement, la communauté open source et l’équipe PyPI ont réagi vite : les paquets malveillants ont été retirés en moins de quelques heures après la découverte. Mais pendant ce temps, des développeurs qui ont lancé pip install litellm ou pip install -U litellm ont pu être infectés sans le savoir.

Pourquoi les attaques supply chain visent l’écosystème IA ?

Les attaques supply chain ne sont pas nouvelles, mais elles explosent en 2026. Voici pourquoi :

  • Croissance exponentielle des outils open source IA : LangChain, LiteLLM, Hugging Face transformers, Ollama… Des centaines de paquets deviennent des dépendances transversales que personne ne peut ignorer.
  • Manque de ressources et de vérification : Beaucoup de ces projets sont maintenus par des équipes toutes petites ou par des bénévoles. La vérification des contributeurs et l’audit de sécurité sont souvent limités.
  • Les clés API IA valent cher : Une clé OpenAI ou Claude compromise peut coûter des milliers d’euros en appels API frauduleux en quelques heures.
  • Chaîne de confiance brisée : Si un paquet populaire est infecté, tous ses dépendants le sont aussi, en cascade. C’est un multiplicateur d’effet idéal pour les attaquants.
  • Installation automatique et mise à jour silencieuse : Beaucoup de devs utilisent pip install package sans épingler une version exacte, ce qui veut dire qu’une nouvelle version malveillante s’installe automatiquement.

    • Cette attaque est un signal d’alarme : la sécurité supply chain doit devenir une priorité absolue pour toi si tu construis avec l’IA.

    Étape 1 : Vérifier si tu as été touché

    La première chose à faire, c’est de déterminer si LiteLLM 1.82.7 ou 1.82.8 se trouve dans tes environnements actuels. Voici comment procéder :

    Commande 1 : Lister ta version installée

    Ouvre un terminal dans chaque projet Python qui utilise LiteLLM (ou tes environnements virtuels) et lance :

    pip list | grep litellm

    Si tu vois litellm 1.82.7 ou litellm 1.82.8, tu es potentiellement infecté. Note bien la version exacte.

    Commande 2 : Vérifier l’historique des installations

    Regarde quand la version a été installée :

    pip show litellm

    Cette commande affiche des métadonnées. Si l’installation date du 24 mars 2026 ou peu après, c’est un indicateur fort d’infection. Demande-toi : « As-je installé ou mis à jour LiteLLM ce jour-là ? »

    Commande 3 : Inspecter les fichiers suspects

    Sur Linux/macOS, localise le dossier d’installation et inspecte son contenu :

    python -c "import litellm; print(litellm.__path__)"

    Puis examines les fichiers .py pour chercher du code suspect : appels à `urllib`, ouverture de fichiers sensibles, connexions réseau non documentées. Le code malveillant était obfusqué mais contient souvent des patterns distinctifs.

    Étape 2 : Nettoyer et réinstaller

    Si tu as détecté LiteLLM 1.82.7 ou 1.82.8, il faut agir maintenant :

    Suppression complète

    pip uninstall litellm -y
pip cache purge

    Réinstallation d’une version sûre

    Installe la dernière version patché (1.82.9 ou supérieur, selon le moment où tu lis cet article) :

    pip install litellm==1.82.9

    Remplace 1.82.9 par la version actuelle recommandée. Consulte la page officielle LiteLLM GitHub pour la version sûre confirmée.

    Regénération immédiate des clés API

    C’est crucial : si ton code a été infecté pendant quelques heures, tes clés API ont pu être compromises. Révoque-les et génères-en des nouvelles :

  • OpenAI : Va sur platform.openai.com → API keys, supprime les anciennes, crée de nouvelles clés
  • Anthropic (Claude) : console.anthropic.com → API keys, même processus
  • Tous les autres fournisseurs : Fais de même pour chaque service API que tu utilisais

    • Étape 3 : Sécuriser ton écosystème Python avec des dépendances épinglées

    La raison pour laquelle cette attaque a pu se propager aussi vite, c’est que les gens installent les dépendances avec des versions flexibles. Ne fais pas cette erreur.

    Fichier requirements.txt : utilise des versions exactes

    Crée ou mets à jour ton fichier requirements.txt avec des versions précises :

    litellm==1.82.9
openai==1.52.0
anthropic==0.25.8
langchain==0.1.14
requests==2.31.0

    Utilise == (égalité exacte), pas ~= ou >=. Oui, tu devras tester manuellement les mises à jour, mais c’est le prix de la sécurité.

    Fichier pyproject.toml : même approche

    Si tu utilises pyproject.toml (moderne, recommandé) :

    [project]
dependencies = [
    "litellm==1.82.9",
    "openai==1.52.0",
    "anthropic==0.25.8",
]

    Commandes CI/CD : verrouille aussi en production

    Dans tes pipelines GitHub Actions, GitLab CI, etc., utilise toujours pip install -r requirements.txt ou pip install --no-deps pour garantir que les dépendances ne se mettent pas à jour surprise.

    Étape 4 : Scanner tes dépendances avec les outils de sécurité

    Maintenant que tu as nettoyé, mets en place un système de surveillance automatique :

    pip-audit : détecte les vulnérabilités connues

    Installe et utilise pip-audit :

    pip install pip-audit
pip-audit

    Cet outil compare tes dépendances actuelles contre une base de données CVE (Common Vulnerabilities and Exposures). Il t’avertira si tu as une version vulnérable installée.

    safety : autre outil d’audit

    pip install safety
safety check

    Safety fonctionne de façon similaire et peut avoir une base de données légèrement différente. Utilise-le en complément.

    Intégration dans ton CI/CD

    Ajoute ces commandes à ton workflow GitHub Actions ou GitLab CI pour que les scans s’exécutent à chaque push :

    - name: Scan for vulnerabilities
  run: |
    pip install pip-audit
    pip-audit --strict

    Le flag --strict fait échouer le build si une vulnérabilité est trouvée.

    Étape 5 : Configurer des alertes et une veille de sécurité

    Le contrôle c’est bien, mais la prévention c’est mieux. Mets en place une veille proactive :

    Suive les annonces de sécurité PyPI

  • S’abonner au PyPI Security Advisory (disponible sur PyPI.org)
  • Surveiller les GitHub Security Advisories des projets que tu utilises (LiteLLM, LangChain, etc.)
  • Rejoindre les Slack/Discord communautaires des projets IA pour des alertes en temps réel

    • Dépôt Dependabot sur GitHub

    Si tu héberges ton code sur GitHub, active Dependabot pour recevoir des PRs automatiques quand une mise à jour de sécurité existe :

  • Va sur Settings → Code security and analysis → Dependabot
  • Active « Dependabot alerts » et « Dependabot security updates »
  • Tu recevras des PRs automatiques pour patcher les vulnérabilités

    • Alertes personnalisées

    Configure Google Alerts ou des outils comme IFTTT pour monitorer certains mots-clés :

  • « LiteLLM vulnerability »
  • « PyPI security »
  • « Python supply chain attack »

    • Astuces pro pour renforcer ton posture de sécurité

    Au-delà du nettoyage immédiat, voici ce que les devs IA chevronné font :

  • Environnements isolés : Utilise des conteneurs Docker ou des machines virtuelles isolées pour tester des paquets suspects avant de les lancer en production
  • Audit du code source : Pour les dépendances critiques comme LiteLLM, clone le repo GitHub, lis le code de la version que tu vas utiliser, puis verrouille-la à jamais
  • Permissionnage minimal : Lance tes applications Python avec les droits utilisateur minimaux possibles (pas en root/admin)
  • Monitoring des logs : Mets en place des logs détaillés pour detecter les appels API réseau étranges ou les exfiltrations de données
  • Tests réguliers : Fais des audits de sécurité bimestriel ou trimestriel sur tes dépendances complètes
  • Sauvegardes de fichier de configuration : Sauvegarde régulièrement tes fichiers de config (API keys, secrets) dans un endroit chiffré à part, pour pouvoir les régénérer rapidement en cas de compromission

    • Erreurs courantes à éviter

  • Ne pas toucher, c’est un problème « pas chez moi » : Même si le paquet malveillant a été retiré rapidement, il a pu être installé. Vérifie vraiment.
  • Garder les anciennes clés API : Si tu suspectes une infection, régénère tes clés. C’est mieux d’être prudent que d’avoir des appels API frauduleux.
  • Utiliser des wildcard versions (*) : pip install "litellm>=1.82" c’est dangereux. Épingle les versions exactes.
  • Oublier les dépendances transitives : LiteLLM dépend peut-être d’autres paquets. Si ceux-ci sont contaminés, tu n’es pas sauvé en nettoyant juste LiteLLM.
  • Ignorer les logs de pip : Garde trace de ce que tu installes et mets à jour, pour pouvoir recréer l’historique en cas d’incident.
  • Penser que « mon projet est petit » : Les attaquants scannent tous les projets. Taille n’est pas un bouclier de sécurité.

    • Résumé en 5 points

  • Vérifie si tu as LiteLLM 1.82.7 ou 1.82.8 avec pip list | grep litellm
  • Si oui, désinstalle, nettoie le cache, et réinstalle une version sûre
  • Régénère immédiatement tes clés API (OpenAI, Claude, etc.)
  • Épingle toutes tes dépendances à des versions exactes dans requirements.txt
  • Mets en place pip-audit, Dependabot, et une veille de sécurité continu

    • FAQ : Les questions que tu te poses

    Est-ce que je dois paniquer si j’ai utilisé une version malveillante ?

    Non, mais oui. La bonne nouvelle : l’attaque a été découverte et neutralisée vite. La mauvaise : si tu as exécuté du code avec ces versions, tes clés API ont pu être compromises. Fais les trois choses suivantes immédiatement : (1) nettoie l’installation, (2) régénère les clés API, (3) vérifie tes logs pour détecter les appels API suspects. Si tout est propre, tu es bon. Si tu vois des appels frauduleux, contacte immédiatement les fournisseurs (OpenAI, Anthropic, etc.) et signale la fraude.

    Peut-il y avoir d’autres paquets IA infectés en ce moment ?

    Probablement. LiteLLM n’est pas un cas isolé. Des attaques supply chain vont continuer à se produire. La meilleure défense c’est une bonne hygiène : épingle tes versions, scanne régulièrement avec pip-audit et safety, et reste vigilant. Lire les changelogs des projets que tu utilises est aussi une bonne pratique.

    Dois-je auditer tout mon code pour du code malveillant injecté ?

    En théorie, oui. En pratique, si tu as exécuté LiteLLM infecté, le malware avait accès à tes fichiers de configuration et tes variables d’environnement. Plutôt que de chercher l’aiguille dans la botte de foin, concentre-toi sur : (1) regénérer les clés, (2) nettoyer ton environnement, (3) redéployer une version propre. Si tu veux être extra prudent, lance un scan antivirus/antimalware sur la machine en question.

    Combien de time j’ai pour nettoyer avant qu’il ne soit trop tard ?

    L’attaque remonte au 24 mars 2026, mais des dégâts peuvent survenir des semaines ou mois après (les clés peuvent être utilisées progressivement). Fais-le dès aujourd’hui. Plus tu attends, plus le risque augmente. Une heure c’est le timing idéal pour (1) déterminer si tu es affecté, (2) nettoyer, (3) régénérer les clés. Deux heures max si tu dois coordonner avec d’autres ou tester en prod.

    Pour aller plus loin

    La sécurité supply chain en Python est un domaine qui émerge. Quelques ressources pour rester à jour :

  • PyPI Security Advisories : pypi.org/help#security
  • OWASP Dependency-Check : Outil pour auditer les dépendances (alternative à pip-audit)
  • Bandit : Scanner de sécurité statique pour du code Python
  • LiteLLM GitHub Security : Suive les releases et les patches offciels
  • Python Security Summit 2026 : Conférences et ressources sur la sécurité Python/IA

    • Le monde de l’IA se construit vite, mais la sécurité doit rester une fondation solide. Prends le temps de sécuriser ton écosystème aujourd’hui, tu éviteras des crises demain.