LiteLLM CVE-2026-42208 : SQL Injection sur l'AI Gateway, déjà dans le KEV

LiteLLM est devenu en quelques mois l'AI Gateway de référence — utilisé par des milliers d'entreprises pour proxyfier leurs appels vers OpenAI, Anthropic, Bedrock, Vertex AI… avec gestion centralisée des clés, rate limiting, observabilité et facturation interne. Le 8 mai 2026, l'éditeur a publié CVE-2026-42208, une SQL injection critique (CVSS 9.8) qui permet à un attaquant non authentifié de lire — et potentiellement modifier — la base de données du proxy, incluant les clés API qu'elle gère. La vulnérabilité a été ajoutée au catalogue CISA KEV le jour même.

Si vous opérez une instance LiteLLM en production, patcher est urgent : vos clés API LLM (souvent à plusieurs milliers d'euros de crédit) et vos identifiants utilisateurs sont en jeu.

Détails techniques

Composant vulnérable

Lorsqu'un client appelle une route LLM de LiteLLM (ex: POST /chat/completions), le proxy vérifie la validité de la clé fournie dans l'en-tête Authorization. Cette vérification fait une requête SQL contre la base interne du proxy.

Dans les versions vulnérables, la valeur de la clé fournie par l'appelant est mixée dans le texte de la requête SQL au lieu d'être passée comme paramètre séparé (paramétrage SQL classique). Concrètement, le code construit quelque chose comme :

# Pseudo-code reconstitué — pattern vulnérable
query = f"SELECT * FROM keys WHERE token = '{auth_header}'"
db.execute(query)

Un attaquant peut donc envoyer un en-tête Authorization spécialement conçu qui injecte du SQL arbitraire dans la requête. La vulnérabilité est atteinte via le chemin de gestion d'erreur du proxy, ce qui signifie qu'elle est exploitable sans clé API valide.

Caractéristiques

Produits et versions affectés

Vérifiez votre version :

# Docker
docker inspect <litellm-container> --format '{{.Config.Image}}'

# Pip / Python
pip show litellm | grep Version

# Helm
helm list -A | grep litellm

Exploitation et impact

Conditions d'exploitation

Toute instance LiteLLM accessible via HTTP/HTTPS — typiquement en interne sur Kubernetes, mais aussi un nombre non négligeable d'instances exposées via Ingress ou directement sur Internet (déploiements multi-tenant SaaS).

PoC générique

# Exemple d'en-tête Authorization malveillant
curl -X POST "https://litellm.example.com/chat/completions" \
  -H "Authorization: Bearer ' UNION SELECT api_key,2,3,4 FROM keys-- " \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4","messages":[]}'

La réponse d'erreur du proxy peut révéler des données extraites de la base.

Conséquences

1. Vol massif de clés API LLM

LiteLLM stocke en base toutes les clés API qu'il proxifie : OpenAI, Anthropic, Bedrock, Vertex AI, Azure OpenAI. Un attaquant qui les exfiltre peut :

• Brûler des milliers d'euros de crédit en quelques heures (les clés OpenAI permettent typiquement plusieurs milliers de $ de tokens par jour)
• Utiliser les clés pour des charges illicites : génération massive de contenu pour scam, désinformation, fraude
• Persister en récupérant les clés régulièrement (rotation des clés côté providers : 24-72h minimum)

2. Vol des clés virtuelles LiteLLM

LiteLLM crée des clés virtuelles émises à chaque utilisateur interne. Les voler permet d'usurper l'identité de n'importe quel utilisateur dans le système.

3. Modification de configuration

Si le compte SQL utilisé par LiteLLM a les permissions d'écriture (cas courant), l'attaquant peut :

• Créer des comptes admin
• Désactiver les limites de quota / rate limiting
• Modifier les routages pour intercepter le trafic

4. Vol des historiques de conversations

LiteLLM stocke les requêtes/réponses LLM (selon la configuration). Données potentiellement sensibles : prompts contenant des données métier, code propriétaire, données clients, etc.

Détection et IOC

Logs LiteLLM

Activez le logging détaillé et chassez les requêtes Authorization avec des motifs SQL injection :

# Logs typiques d'une tentative
grep -E "Authorization.*['\"].*(UNION|SELECT|INSERT|UPDATE|DROP|--|;)" /var/log/litellm/access.log

Indicateurs :

• En-têtes Authorization contenant des quotes simples, UNION, SELECT, --
• Volume anormal de réponses 500 sur les routes LLM (les payloads SQLi mal formés crashent le parser)
• Réponses dont la taille body est anormalement grande (extraction de données)

Logs base de données

Côté Postgres / MySQL hébergeant LiteLLM :

-- Postgres : activer le log des requêtes lentes / suspectes
SET log_statement = 'mod';
SET log_min_duration_statement = 100;

Recherchez :

• Requêtes SELECT sur la table keys ou user_api_keys avec des UNION inhabituels
• Accès aux tables sensibles depuis l'utilisateur LiteLLM

Indicateurs de compromission

• Hausse anormale de la facturation OpenAI/Anthropic/Bedrock dans la semaine suivant l'exposition publique de la CVE (>3 jours sans patch = suspicion forte)
• Création de clés virtuelles non sollicitées
• Accès depuis IPs externes inconnues sur les routes admin

Mitigation et patch

Action immédiate : patcher en 1.83.7

# Docker
docker pull ghcr.io/berriai/litellm:v1.83.7
docker compose up -d

# Pip
pip install --upgrade litellm==1.83.7

# Helm
helm upgrade litellm berriai/litellm --version <chart-version-correspondante>

Procédure de réponse à incident (à exécuter même si vous patchez immédiatement)

Si votre instance était exposée Internet pendant la fenêtre de vulnérabilité (toute version 1.81.16 → 1.83.6 entre fin avril 2026 et la date de patch) :

1. Faire tourner toutes les clés API LLM stockées dans LiteLLM (côté providers : OpenAI, Anthropic, Bedrock, etc.)
2. Révoquer toutes les clés virtuelles LiteLLM et en émettre de nouvelles
3. Auditer les logs de facturation OpenAI/Anthropic des 30 derniers jours pour détecter des usages anormaux
4. Vérifier l'intégrité de la table users (création de comptes admin non sollicitée)
5. Faire tourner les credentials de la base de données utilisée par LiteLLM

Hardening durable

• Limiter les permissions SQL du compte de base de données utilisé par LiteLLM (read/write sur les tables nécessaires uniquement, pas de CREATE, pas de GRANT)
• Mettre un WAF devant (Cloudflare, AWS WAF, ModSecurity) avec un ruleset SQL injection actif sur les routes /chat/completions, /embeddings, etc.
• Restreindre l'accès réseau à l'instance LiteLLM : VPN, mTLS, IP allowlist
• Activer un logging d'audit et envoyer vers un SIEM
• Faire tourner régulièrement les clés API LLM même hors incident (toutes les 90 jours)

Pourquoi surveiller en continu vos outils AI

L'écosystème AI/LLM évolue à une vitesse extrême : LiteLLM ne fait pas partie des outils traditionnellement scannés par les inventaires de vulnérabilités, et pourtant il manipule des clés API à très haute valeur (plusieurs milliers d'euros de crédit par jour) et des données potentiellement sensibles. Une CVE comme celle-ci, ajoutée au CISA KEV en 24h, peut coûter cher si elle reste non patchée quelques jours.

Avec cveo.tech, inventoriez vos outils d'infrastructure AI (LiteLLM, LangChain proxies, vLLM, OpenLLM…) au même titre que vos applications classiques et soyez alerté automatiquement dès qu'une CVE critique cible une de vos versions exactes — pour patcher avant que vos clés API ne soient revendues sur le dark web.