Passerelles LLM : LiteLLM CVE-2026-59822 au KEV, LightLLM CVE-2026-90919 en RCE 9.8

Deux vulnérabilités visant l'infrastructure qui sert les modèles de langage, publiées ou confirmées exploitées à quelques jours d'intervalle :

Corrections : LiteLLM 1.84.0. Pour LightLLM, toutes les versions jusqu'à 1.2.0 sont affectées ; NVD n'expose pas de version corrigée — vérifie le dépôt du projet.

C'est la deuxième CVE LiteLLM ajoutée au KEV en quatre mois, après l'injection SQL de mai. Et ces deux failles illustrent chacune un défaut de conception typique d'une infrastructure construite très vite.

CVE-2026-59822 — LiteLLM : une authentification qui échoue en ouvrant

Prior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key.

Relis la dernière phrase lentement, parce qu'elle décrit une erreur qu'on retrouve partout.

1. La requête arrive avec un en-tête Authorization inventé.
2. La validation de la clé LiteLLM échoue — normal.
3. Au lieu de rejeter la requête, le code bascule sur un chemin de repli OAuth2.
4. Ce chemin de repli produit un objet d'authentification vide.
5. Un objet vide est traité comme une authentification réussie.

C'est un fail-open : quand le contrôle ne sait pas quoi décider, il laisse passer. La règle de conception inverse — tout ce qui n'est pas explicitement autorisé est refusé — est la plus ancienne de la sécurité, et elle est la première à céder quand on ajoute des modes d'authentification à la hâte.

Pourquoi « MCP » aggrave la situation

MCP (Model Context Protocol) est le mécanisme par lequel un modèle appelle des outils : lire des fichiers, interroger une base, appeler une API, envoyer un message. Atteindre l'outillage MCP sans clé, ce n'est pas seulement consommer du crédit de modèle : c'est pouvoir déclencher les actions que ces outils permettent, avec les identifiants que la passerelle détient pour les exécuter.

Le C:H du vecteur le confirme : c'est l'accès aux données qui est en jeu, pas seulement la facture.

CVE-2026-90919 — LightLLM : pickle sur le réseau

LightLLM through 1.2.0 contains a remote code execution vulnerability in the Config Server's unauthenticated /visual_register WebSocket endpoint that passes the first client frame directly to pickle.loads().

Il n'y a pas grand-chose à analyser, et c'est justement le point : désérialiser du pickle reçu du réseau est une exécution de code par définition. Le format pickle de Python permet à un objet de préciser, via __reduce__, quelle fonction appeler à la reconstruction. Un attaquant fournit un objet qui dit « appelle os.system avec cette commande ». Ce n'est pas un bug dans pickle, c'est sa spécification — la documentation Python le signale en tête de page.

L'erreur est une hypothèse d'architecture : le Config Server a été pensé pour un réseau de confiance, entre composants d'un même déploiement. Dès que le port est joignable par autre chose, l'hypothèse tombe.

Ce que contient un serveur d'inférence

• Des GPU — une ressource que les attaquants monétisent directement (minage, revente de capacité)
• Les poids des modèles, parfois propriétaires et coûteux à produire
• Les requêtes des utilisateurs, qui contiennent souvent des données sensibles
• Un accès réseau vers les systèmes qui alimentent le modèle

Le point commun

LiteLLM et LightLLM ne partagent ni code ni éditeur. Ils partagent un contexte : des projets de l'écosystème IA, adoptés massivement en production avant d'avoir mûri côté sécurité. On y retrouve les erreurs que le reste de l'industrie a appris à éviter il y a quinze ans — repli permissif sur l'authentification, désérialisation d'objets arbitraires, services internes supposés inaccessibles.

Ce n'est pas un reproche à ces projets : c'est une caractéristique de la vitesse d'adoption. Mais elle a une conséquence opérationnelle — ces composants méritent la même discipline de mise à jour que n'importe quel service exposé, et ils n'y sont presque jamais soumis.

Identifier ton exposition

# LiteLLM
pip show litellm | grep -i version
docker ps --format '{{.Image}}' | grep -i litellm

# LightLLM
pip show lightllm | grep -i version
# Ports ouverts par le déploiement — le Config Server ne doit pas être joignable hors du cluster
ss -tlnp | grep -i python

Détection

LiteLLM

• Requêtes vers les endpoints MCP portant un en-tête Authorization qui ne correspond à aucune clé émise
• Appels d'outils MCP non attribuables à une clé connue dans les journaux de la passerelle
• Consommation de modèle ou appels d'outils hors du profil habituel

LightLLM

• Connexions WebSocket vers /visual_register depuis des adresses extérieures au déploiement
• Processus enfants inattendus du processus Config Server
• Utilisation GPU sans rapport avec la charge d'inférence observée

Mitigation

1. LiteLLM : passer en 1.84.0 ou ultérieur

C'est au KEV : l'échéance CISA était le 16 septembre.

2. LightLLM : isoler le Config Server immédiatement

En attendant une version corrigée, le port du Config Server ne doit être joignable que par les autres composants du déploiement. Règle de pare-feu, NetworkPolicy Kubernetes, ou liaison sur une interface interne — c'est la seule mesure efficace tant que pickle.loads() reste dans le chemin.

3. Pour toute l'infrastructure IA

• Aucune passerelle ni serveur d'inférence exposé sur Internet sans authentification en frontal (reverse proxy, VPN)
• Des clés à portée minimale : une clé qui ne donne pas accès aux outils MCP ne peut pas servir à les appeler
• Les identifiants des outils MCP traités comme des secrets de production, avec rotation

4. Si tu suspectes une compromission

• LiteLLM : faire tourner toutes les clés API de la passerelle et les identifiants des fournisseurs de modèles et des outils MCP qu'elle détient
• LightLLM : considérer l'hôte comme compromis au niveau système ; reconstruire plutôt que nettoyer

Pourquoi surveiller en continu votre infrastructure IA

Les composants de l'écosystème LLM sont déployés par les équipes produit et data, souvent en dehors des processus de la DSI, et évoluent à un rythme de publication que personne ne suit manuellement. Deux CVE en quelques jours, dont une déjà exploitée, sur des briques que la plupart des organisations n'ont inscrites dans aucun inventaire.

Avec cveo.tech, inventorie tes passerelles LLM, serveurs d'inférence et bibliothèques IA avec leur version exacte, et reçois une alerte automatique dès qu'une CVE critique les concerne.