BRIEFING SÉCURITÉ · 08.07.2026 DEENFRES

Études de cas

LiteLLM CVE-2026-42208 : accès non autorisé aux bases de données

Par Alec Chizhik · 29 avril 2026 · 8 min de lecture

Une injection SQL dans une couche proxy d’IA n’est pas une vulnérabilité web classique. Toute personne utilisant LiteLLM comme couche de routage et n’ayant pas encore appliqué le correctif expose potentiellement toutes les clés API des fournisseurs de LLM, ainsi que chaque prompt ayant transité par le proxy.

Les points clés en bref

  • CVSS 9,3 – Critique. CVE-2026-42208 permet à des attaquants non authentifiés de modifier la base de données via l’interface d’administration du proxy LiteLLM.
  • Nouvelle surface d’attaque. Les proxies d’IA comme LiteLLM stockent des clés API fournisseurs, des configurations de routage de modèles et des journaux de prompts, le tout dans une base de données.
  • Aucune authentification requise. L’attaque par injection SQL ne nécessite aucune authentification : le point d’accès est exposé si LiteLLM est exécuté sans pare-feu.
  • Réponse aux incidents différente. Les guides classiques pour applications web ne s’appliquent pas ; la portée de l’impact concerne tous les comptes fournisseurs de LLM en aval.
  • Mesure immédiate. Mettez à jour vers la version corrigée de LiteLLM, renouvelez toutes les clés API fournisseurs et sécurisez le point d’accès d’administration du proxy.

Qu’est-ce que LiteLLM ? LiteLLM est une bibliothèque open source en Python et un serveur proxy qui fournit une API unifiée pour plus de 100 fournisseurs de LLM : OpenAI, Anthropic, Azure OpenAI, Google Gemini, Bedrock, Groq et bien d’autres. Les entreprises utilisent LiteLLM comme intergiciel entre leur application et les différents fournisseurs de modèles : gestion centralisée des clés, suivi de l’utilisation, limitation de débit et équilibrage de charge. En résumé : LiteLLM est précisément l’outil qui maintient souvent invisiblement ensemble les infrastructures modernes d’IA.

La vulnérabilité réside dans le point d’accès de l’API d’administration du proxy LiteLLM. Grâce à l’injection SQL, un attaquant non authentifié peut modifier directement la base de données que LiteLLM utilise pour la configuration et la journalisation. Ce n’est pas anodin : cette base de données contient généralement les clés API de tous les fournisseurs configurés, les règles de routage et, selon la configuration, les prompts et réponses mis en cache.

9,3
Score CVSS
Critique – CVE-2026-42208

0
Authentification requise pour exploitation
vecteur d’attaque non authentifié

100+
Fournisseurs de LLM accessibles via LiteLLM
pris en charge dans l’écosystème LiteLLM

Pourquoi les couches proxy d’IA nécessitent une réponse aux incidents différente

Une injection SQL classique dans une application web est grave : elle implique généralement des données clients, des jetons de session ou des identifiants d’accès. Dans un proxy d’IA, le potentiel de dommage est structurellement différent :

  1. Clés API fournisseur à fort impact : LiteLLM gère les clés de tous les fournisseurs configurés. Une clé OpenAI volée entraîne une utilisation non contrôlée de l’API aux frais de l’entreprise, ainsi qu’un accès potentiel aux données de tous les projets OpenAI associés à ce compte. Une clé Anthropic compromise donne un accès similaire.
  2. Manipulation du routage : Si un attaquant obtient un accès en écriture à la base de données LiteLLM, il peut modifier les règles de routage et rediriger les prompts vers un endpoint externe. Il s’agit d’une forme d’exfiltration de données qui échappe souvent aux règles SIEM classiques.
  3. Les logs de prompts comme données sensibles : De nombreux déploiements LiteLLM enregistrent les prompts et réponses à des fins de débogage et de suivi d’utilisation. En pratique, ces logs contiennent des extraits de documents internes, de demandes clients et de données commerciales confidentielles.
  4. Impact en aval sur les applications : Si un attaquant modifie la configuration de routage, toutes les applications utilisant le proxy peuvent commencer à recevoir des réponses d’un mauvais modèle. Cela est difficile à détecter et peut provoquer des comportements erronés dans des systèmes en production.

Ce que les équipes DevSecOps doivent vérifier immédiatement

Mesure immédiate Pourquoi c’est critique
Mettre à jour LiteLLM vers la version corrigée Ferme le vecteur d’injection SQL
Régénérer toutes les clés API fournisseur Les clés volées resteraient valides autrement
Supprimer l’accès public à l’endpoint d’administration depuis Internet L’API d’administration n’a jamais été conçue pour un accès public
Vérifier les logs LiteLLM à la recherche de modifications anormales de routage Indique si un attaquant a déjà modifié le routage
Vérifier les comptes fournisseur pour détecter une utilisation inhabituelle Un usage abusif de la clé API génère des coûts et laisse des traces

L’endpoint d’administration est le problème décisif : LiteLLM a été conçu pour un usage interne. Dans les déploiements en production, le proxy s’exécute généralement sur le port 4000, avec l’interface d’administration exposée. La segmentation réseau ou un proxy inverse bloquant le port d’administration devrait être une configuration standard, mais ce n’est pas le cas.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.

Quelles versions de LiteLLM sont affectées par le CVE-2026-42208 ?

La vulnérabilité affecte les versions du proxy LiteLLM antérieures à la version corrigée publiée après la divulgation du CVE. La limite exacte de version doit être consultée dans la documentation officielle du CVE et dans le dépôt GitHub de LiteLLM. Les utilisateurs ayant installé LiteLLM via pip peuvent mettre à jour vers la version actuelle avec pip install –upgrade litellm.

Comment vérifier si mon endpoint d’administration LiteLLM est accessible depuis Internet ?

Vérifiez si le port 4000 de l’hôte LiteLLM est accessible depuis l’extérieur. Une méthode simple : curl http://[hôte]:4000/health depuis un réseau externe. Si l’endpoint répond, il est exposé. L’endpoint d’administration ne devrait être accessible que via des réseaux internes ou un VPN. Utiliser Nginx comme proxy inverse avec une règle de blocage des IPs externes sur les routes d’administration est la mesure de renforcement la plus rapide.

Que faire si l’on ne sait pas si une attaque a eu lieu ?

Consultez les journaux de la base de données LiteLLM à la recherche d’appels API non authentifiés vers le point de terminaison concerné et de modifications inhabituelles de la configuration de routage. Vérifiez les comptes des fournisseurs (OpenAI, Anthropic, etc.) afin de détecter toute utilisation de l’API depuis des adresses IP inconnues. En cas de doute : changez toutes les clés et, dans le pire des cas, partez du principe que les clés d’accès et les journaux de prompts ont été compromises.

LiteLLM est-il un cas isolé ou s’agit-il d’un problème généralisé chez les proxies d’IA ?

Les proxies d’IA et les passerelles LLM constituent une catégorie de logiciels relativement nouvelle : LiteLLM, OpenRouter, PortKey, Helicone et autres. Ils sont apparus rapidement pour répondre au besoin d’API LLM unifiées, sans avoir traversé le cycle de maturation en matière de sécurité que connaissent déjà les catégories de logiciels plus anciennes. Cela en fait un point aveugle structurel pour de nombreuses équipes de sécurité, qui considèrent l’infrastructure IA comme « une simple API ».

Quelles règles de surveillance devraient être mises en place pour les déploiements LiteLLM ?

Quatre règles de surveillance utiles : (1) Alerte en cas d’appel API vers le point de terminaison d’administration depuis des adresses IP externes. (2) Alerte en cas de modification de la configuration de routage dans la base de données LiteLLM. (3) Détection d’anomalies dans l’utilisation de l’API du fournisseur : écarts significatifs par rapport à la consommation de base. (4) Alerte si les journaux LiteLLM cessent d’être générés : un attaquant ayant accès pourrait désactiver les journaux.

Sélections de lecture recommandées par la rédaction

Plus de contenus du réseau MBF Media

cloudmagazinEU AI Act pour les fournisseurs SaaS : ce que signifie concrètement la classification à haut risque à partir d’aoûtDigital ChiefsSécurité de l’IoT industriel en 2026 : les dispositifs edge désormais inclus dans les rapports de direction et le périmètre d’audit NIS2

Pour aller plus loin

Un magazine d'Evernine Media GmbH