LiteLLM CVE-2026-49468 : un contournement d'authentification par en-tête Host dans le routage de la passerelle

De quoi s’agit-il ?

Le 17 juin 2026, une vulnérabilité critique de contournement d’authentification dans LiteLLM a été publiée dans la GitHub Advisory Database sous l’identifiant GHSA-4xpc-pv4p-pm3w et la référence CVE-2026-49468. LiteLLM est l’un des proxys/passerelles LLM les plus déployés — la couche de routage des modèles sous CrewAI, DSPy, Microsoft GraphRAG et une longue liste de frameworks d’agents — donc une faille pré-authentification dans son proxy touche une surface très large.

La faille est une injection d’en-tête Host qui contourne la couche d’autorisation propre à LiteLLM (CWE-290, Authentication Bypass by Spoofing). Elle affecte toutes les versions antérieures à 1.84.0 et est corrigée dans la 1.84.0. L’avis la classe critique, avec un score CVSS v4 élevé : vecteur réseau, faible complexité, aucune authentification ni interaction utilisateur requise. Elle a été signalée de façon responsable par Le The Thang (KCSC) et Kim Ngoc Chung (One Mount Group).

Si cela vous semble familier, c’est normal. C’est le cousin applicatif de BadHost (CVE-2026-48710), la faille Starlette de mai 2026 de même nature — et cela démontre que la classe de bug survit à un correctif du framework.

Comment ça marche

LiteLLM détermine à quelle route correspond une requête entrante dans get_request_route(), au sein de litellm/proxy/auth/auth_utils.py. Cette fonction lit request.url.path pour calculer le chemin effectif utilisé pour la décision d’autorisation.

Dans les applications fondées sur Starlette, request.url est reconstruit à partir de l’en-tête Host fourni par le client. request.url.path est donc partiellement sous influence de l’attaquant. FastAPI, de son côté, distribue la requête à un gestionnaire en utilisant le chemin issu de la ligne de requête ASGI — une autre source de vérité. En forgeant l’en-tête Host, un attaquant fait diverger le chemin évalué par la couche d’auth du chemin réellement exécuté par FastAPI.

# Schéma conceptuel d'après l'avis public du 17 juin 2026.
# Aucun payload contre un système réel n'est reproduit ici.

Couche d'auth  (get_request_route → request.url.path, dérivé du Host) :
    voit un chemin anodin / non privilégié  → le contrôle passe

Routeur FastAPI (chemin issu de la ligne de requête ASGI) :
    distribue le endpoint d'administration privilégié → le handler s'exécute

Résultat : une requête qui devrait être rejetée par le contrôle d’accès atteint malgré tout un endpoint de gestion restreint. La cause racine est identique à BadHost — une décision de sécurité prise sur une valeur dérivée d’un en-tête contrôlé par le client — sauf qu’ici elle réside dans le code propre de LiteLLM, et non dans Starlette. Corriger le framework n’a pas supprimé le motif ; l’application l’avait réimplémenté.

Point important : toutes les installations ne sont pas exploitables. Selon l’avis, les environnements qui normalisent ou valident l’en-tête Host en amont sont effectivement protégés : CDN, WAF, reverse proxies avec validation stricte de server_name, et équilibreurs de charge cloud à routage par hôte rejettent ou nettoient la manipulation avant qu’elle n’atteigne LiteLLM. Les clients LiteLLM Cloud ne sont pas affectés. Le profil réellement à risque est un proxy LiteLLM exposé plus ou moins directement à un réseau non fiable, sans validation d’hôte en frontal.

Pourquoi c’est important

Une passerelle est un point de concentration. Si les équipes placent LiteLLM devant leurs modèles, c’est précisément pour centraliser clés, budgets, limites de débit et routage — ce qui signifie que ses endpoints de gestion reposent sur chaque identifiant de fournisseur et chaque politique que le proxy façade. Un accès non authentifié à ces endpoints a une forte valeur, et LiteLLM a désormais vu une injection SQL pré-auth, une chaîne RCE via endpoints MCP et ce contournement d’auth divulgués en environ deux mois.

Le point de fond est la récurrence de la classe. BadHost a été corrigé au niveau de Starlette en 1.0.1. Pourtant, la même erreur — « faire confiance à un chemin dérivé du Host pour une décision d’auth » — est réapparue une couche au-dessus, dans la fonction de routage propre à LiteLLM, avec son propre CVE et son propre correctif. Les correctifs de framework ne corrigent pas rétroactivement le code applicatif qui re-dérive la même valeur non fiable. Si vous avez suivi BadHost en concluant que votre passerelle était de ce fait saine, cette conclusion était fausse.

Défenses

Mettez à jour LiteLLM vers 1.84.0 ou ultérieure. C’est le correctif, et l’avis précise qu’il ne nécessite aucun changement de configuration — épinglez la dépendance, reconstruisez, redéployez. Traitez-le comme un correctif prioritaire pour tout proxy accessible depuis Internet.

Placez une couche de validation du Host en frontal. Si vous ne pouvez pas mettre à jour immédiatement, placez LiteLLM derrière un CDN, un WAF ou un reverse proxy qui impose une validation stricte de Host / server_name, ou un équilibreur de charge à routage par hôte. Rejetez toute requête dont l’en-tête Host contient /, ?, #, des espaces ou des octets hors de la grammaire d’autorité RFC 9112. Cela atténue CVE-2026-49468 et durcit le système contre la prochaine variante.

Limitez l’exposition réseau. Une passerelle de modèles n’a rarement besoin d’être joignable depuis l’Internet ouvert. Liez-la à un plan interne, protégez les endpoints de gestion derrière du mTLS ou des certificats clients, et appliquez une politique réseau de moindre privilège afin que le proxy ne soit joignable que depuis les services qui l’appellent légitimement.

Cessez d’autoriser sur des chemins dérivés d’en-têtes. La leçon d’architecture, identique à BadHost : ne prenez jamais une décision d’autorisation sur une valeur reconstruite à partir d’un en-tête contrôlé par le client. Dans le code ASGI/Starlette, fondez le routage et les contrôles d’accès sur scope["path"] (issu de la ligne de requête), pas sur request.url.path (dérivé du Host). Auditez vos propres middlewares et fonctions de routage pour le même motif.

Inventoriez la cadence de CVE de votre passerelle. Vu la série de divulgations LiteLLM, abonnez-vous aux GitHub Security Advisories du projet, suivez les identifiants GHSA dans votre scanner de dépendances, et fixez un SLA de patch explicite et court pour le composant qui façade vos clés de modèle.

Statut

Élément	Référence	Date	Notes
Avis public	GitHub GHSA-4xpc-pv4p-pm3w / CVE-2026-49468	2026-06-17	Critique, CWE-290
Versions affectées	LiteLLM < 1.84.0	—	Couche d’auth du proxy
Version corrigée	LiteLLM 1.84.0	2026-06-17	Aucun changement de config requis
Cause racine	get_request_route() lit request.url.path dérivé du Host	—	Désync auth/route
Non affectés	LiteLLM Cloud ; déploiements derrière CDN/WAF/reverse proxy/LB validant le Host	—	Le frontal normalise le Host
Rapporteurs	Le The Thang (KCSC), Kim Ngoc Chung (One Mount Group)	2026-06-17	Divulgation responsable
Classe associée	BadHost (CVE-2026-48710), Starlette < 1.0.1	2026-05-22	Même désync, niveau framework

Le vrai titre n’est pas « encore un bug LiteLLM ». C’est qu’une désynchronisation chemin/Host, déjà corrigée une fois dans le framework, est revenue dans le code propre de la passerelle — preuve que cette classe de bug exige une défense au niveau du motif (ne jamais autoriser sur un chemin dérivé d’un en-tête), et pas seulement une montée de version.