LiteLLM CVE-2026-49468: una elusión de autenticación por cabecera Host en el enrutado del gateway

¿Qué es esto?

El 17 de junio de 2026 se publicó en la GitHub Advisory Database una vulnerabilidad crítica de elusión de autenticación en LiteLLM, con el identificador GHSA-4xpc-pv4p-pm3w y la referencia CVE-2026-49468. LiteLLM es uno de los proxys/gateways de LLM más desplegados — la capa de enrutado de modelos bajo CrewAI, DSPy, Microsoft GraphRAG y una larga lista de frameworks de agentes — por lo que un fallo previo a la autenticación en su proxy alcanza una superficie muy amplia.

El fallo es una inyección de cabecera Host que elude la propia capa de autorización de LiteLLM (CWE-290, Authentication Bypass by Spoofing). Afecta a todas las versiones anteriores a la 1.84.0 y está corregido en la 1.84.0. El aviso lo califica de crítico, con una puntuación CVSS v4 alta: vector de red, baja complejidad, sin autenticación ni interacción del usuario requeridas. Fue reportado de forma responsable por Le The Thang (KCSC) y Kim Ngoc Chung (One Mount Group).

Si esto le resulta familiar, es normal. Es el primo a nivel de aplicación de BadHost (CVE-2026-48710), el fallo de Starlette de mayo de 2026 de la misma naturaleza — y demuestra que la clase de bug sobrevive a un parche del framework.

Cómo funciona

LiteLLM decide a qué ruta corresponde una petición entrante dentro de get_request_route(), en litellm/proxy/auth/auth_utils.py. Esa función lee request.url.path para calcular la ruta efectiva utilizada en la decisión de autorización.

En las aplicaciones basadas en Starlette, request.url se reconstruye a partir de la cabecera Host suministrada por el cliente. Por tanto, request.url.path está parcialmente bajo la influencia del atacante. FastAPI, por su parte, despacha la petición a un manejador usando la ruta tomada de la línea de petición ASGI — otra fuente de verdad. Al manipular la cabecera Host, un atacante hace que la ruta que evalúa la capa de autenticación diverja de la ruta que FastAPI ejecuta realmente.

# Esquema conceptual según el aviso público del 17 de junio de 2026.
# No se reproduce ningún payload contra un sistema real.

Capa de auth  (get_request_route → request.url.path, derivado del Host):
    ve una ruta inofensiva / no privilegiada  → el control pasa

Enrutador FastAPI (ruta de la línea de petición ASGI):
    despacha el endpoint de administración privilegiado → se ejecuta el handler

Resultado: una petición que debería ser rechazada por el control de acceso alcanza igualmente un endpoint de gestión restringido. La causa raíz es idéntica a BadHost — una decisión de seguridad tomada sobre un valor derivado de una cabecera controlada por el cliente — solo que aquí reside en el código propio de LiteLLM, no en Starlette. Parchear el framework no eliminó el patrón; la aplicación lo había reimplementado.

Punto clave: no todas las instalaciones son explotables. Según el aviso, los entornos que normalizan o validan la cabecera Host aguas arriba están efectivamente protegidos: CDN, WAF, reverse proxies con validación estricta de server_name y balanceadores de carga en la nube con enrutado por host rechazan o limpian la manipulación antes de que llegue a LiteLLM. Los clientes de LiteLLM Cloud no están afectados. El perfil realmente en riesgo es un proxy LiteLLM expuesto más o menos directamente a una red no confiable, sin validación de host por delante.

Por qué importa

Un gateway es un punto de concentración. Si los equipos colocan LiteLLM delante de sus modelos es precisamente para centralizar claves, presupuestos, límites de tasa y enrutado — lo que significa que sus endpoints de gestión descansan sobre cada credencial de proveedor y cada política que el proxy fachada. Un acceso no autenticado a esos endpoints tiene un valor alto, y LiteLLM ha visto ya una inyección SQL previa a la autenticación, una cadena RCE vía endpoints MCP y esta elusión de autenticación divulgados en unos dos meses.

El punto de fondo es la recurrencia de la clase. BadHost se corrigió a nivel de Starlette en la 1.0.1. Sin embargo, el mismo error — «confiar en una ruta derivada del Host para una decisión de autenticación» — reapareció una capa más arriba, en la función de enrutado propia de LiteLLM, con su propio CVE y su propio parche. Los parches de framework no corrigen retroactivamente el código de aplicación que re-deriva el mismo valor no confiable. Si siguió BadHost y concluyó que su gateway estaba por ello limpio, esa conclusión era errónea.

Defensas

Actualice LiteLLM a la 1.84.0 o posterior. Es la corrección, y el aviso señala que no requiere ningún cambio de configuración — fije la dependencia, reconstruya, redespliegue. Trátelo como un parche prioritario para cualquier proxy accesible desde Internet.

Coloque una capa de validación del Host por delante. Si no puede actualizar de inmediato, ponga LiteLLM tras un CDN, un WAF o un reverse proxy que imponga validación estricta de Host / server_name, o un balanceador con enrutado por host. Rechace toda petición cuya cabecera Host contenga /, ?, #, espacios o bytes fuera de la gramática de autoridad RFC 9112. Esto mitiga CVE-2026-49468 y endurece el sistema frente a la próxima variante.

Restrinja la exposición de red. Un gateway de modelos rara vez necesita ser accesible desde la Internet abierta. Vincúlelo a un plano interno, proteja los endpoints de gestión con mTLS o certificados de cliente, y aplique una política de red de mínimo privilegio para que el proxy solo sea accesible desde los servicios que legítimamente lo invocan.

Deje de autorizar sobre rutas derivadas de cabeceras. La lección de arquitectura, idéntica a BadHost: nunca tome una decisión de autorización sobre un valor reconstruido a partir de una cabecera controlada por el cliente. En código ASGI/Starlette, base el enrutado y los controles de acceso en scope["path"] (de la línea de petición), no en request.url.path (derivado del Host). Audite sus propios middlewares y funciones de enrutado en busca del mismo patrón.

Inventaríe la cadencia de CVE de su gateway. Dada la racha de divulgaciones de LiteLLM, suscríbase a los GitHub Security Advisories del proyecto, siga los identificadores GHSA en su escáner de dependencias y fije un SLA de parche explícito y corto para el componente que fachada sus claves de modelo.

Estado

Elemento	Referencia	Fecha	Notas
Aviso público	GitHub GHSA-4xpc-pv4p-pm3w / CVE-2026-49468	2026-06-17	Crítico, CWE-290
Versiones afectadas	LiteLLM < 1.84.0	—	Capa de auth del proxy
Versión corregida	LiteLLM 1.84.0	2026-06-17	Sin cambios de config
Causa raíz	get_request_route() lee request.url.path derivado del Host	—	Desincronía auth/ruta
No afectados	LiteLLM Cloud; despliegues tras CDN/WAF/reverse proxy/LB que validan el Host	—	El frontal normaliza el Host
Reportantes	Le The Thang (KCSC), Kim Ngoc Chung (One Mount Group)	2026-06-17	Divulgación responsable
Clase asociada	BadHost (CVE-2026-48710), Starlette < 1.0.1	2026-05-22	Misma desincronía, nivel framework

El titular no es «otro bug de LiteLLM». Es que una desincronización de ruta/Host, ya corregida una vez en el framework, regresó en el código propio del gateway — prueba de que esta clase de bug exige una defensa a nivel de patrón (nunca autorizar sobre una ruta derivada de una cabecera), y no solo una subida de versión.