IRCNF

Una vulnerabilidad en Starlette permite a atacantes eludir la autenticación en aplicaciones FastAPI con autenticación basada en ruta

OSTIF / X41 D-Sec
Compartir:
Una vulnerabilidad en Starlette permite a atacantes eludir la autenticación en aplicaciones FastAPI con autenticación basada en ruta

Investigadores de seguridad de X41 D-Sec, trabajando en una auditoría financiada por OSTIF del framework de inferencia vLLM, descubrieron una vulnerabilidad crítica de omisión de autenticación en Starlette — el framework ASGI de Python que sustenta a FastAPI y a un amplio ecosistema de infraestructura de agentes de IA. Registrada como CVE-2026-48710 y denominada BadHost, la falla permite a un atacante manipular la cabecera HTTP Host para que Starlette reporte una ruta URL diferente a la que el servidor web realmente enrutó — evitando cualquier middleware que utilice request.url.path para decisiones de control de acceso. La corrección está disponible en Starlette 1.0.1.

El alcance de la exposición es amplio. Starlette tiene más de 400,000 dependientes en GitHub y más de 325 millones de descargas semanales en PyPI. Las aplicaciones afectadas incluyen cualquier cosa construida sobre FastAPI con middleware de autenticación basado en ruta, junto con un conjunto específico de herramientas de infraestructura de IA: vLLM, LiteLLM, servidores Model Context Protocol (MCP), FastMCP, Google's ADK-Python, Ray Serve y BentoML son todas vulnerables cuando hay middleware de autenticación personalizado.

Cómo funciona el ataque

Las solicitudes HTTP incluyen una cabecera Host que identifica el dominio de destino. Starlette construye su objeto request.url concatenando la cabecera Host cruda con la ruta de la solicitud, y luego vuelve a analizar la cadena combinada en un objeto URL. El problema: Starlette no validaba que la cabecera Host cumpliera con la gramática RFC 9112 antes de usarla en esta construcción. Un atacante puede inyectar caracteres separadores de ruta — /, ? o # — en la cabecera Host, lo que desplaza lo que el analizador ve como ruta, consulta y fragmento cuando vuelve a analizar la URL ensamblada.

El resultado es una vista dividida: el servidor ASGI enruta la solicitud a la ruta real (por ejemplo, /admin), pero request.url.path — lo que lee el middleware de autenticación — reporta la ruta controlada por el atacante (/health, o cualquier otra ruta benigna que el middleware permitiría). El informe de X41 incluye una prueba de concepto tan simple como:

curl -H 'Host: foo?' localhost:8000/admin

En un servidor vulnerable con autenticación basada en ruta, esto devuelve 200 OK desde el endpoint protegido /admin en lugar de un 403 Forbidden.

La razón por la que la vulnerabilidad pasó desapercibida durante tanto tiempo es que surge de la interacción de tres capas que cada una parece razonable de forma aislada: los servidores ASGI pasan la cabecera Host cruda sin validación; Starlette confía en ella para la construcción de URL; y los desarrolladores de middleware asumen que request.url.path es un valor seguro y autoritativo del servidor para el control de acceso. Ninguna capa individual está rota por sí sola.

Quiénes están afectados

La vulnerabilidad es más relevante para aplicaciones que controlan el acceso a endpoints protegidos mediante middleware que verifica la ruta de la solicitud. Este es un patrón común en aplicaciones FastAPI donde un prefijo de ruta (como /admin, /internal o /v1/private) determina la autorización. Las aplicaciones que utilizan los decoradores Depends() o Security() integrados de FastAPI a nivel de ruta individual generalmente no se ven afectadas, porque esos mecanismos verifican la autorización en el momento de la resolución de la ruta, no mediante inspección de ruta en el middleware.

El impacto en la infraestructura de IA es la preocupación más aguda. Los servidores MCP — que implementan el Model Context Protocol para conectar agentes de IA a herramientas y fuentes de datos — están particularmente expuestos porque la especificación MCP exige endpoints de descubrimiento OAuth no autenticados, lo que brinda a los atacantes una ruta de evasión confiable conocida sin necesidad de adivinar qué rutas están desprotegidas. vLLM y LiteLLM, ampliamente utilizados para servir y hacer proxy de modelos de lenguaje grandes en producción, se ven afectados cuando están detrás de middleware de autenticación personalizado basado en Starlette. Google's ADK-Python, el SDK de Python para construir agentes de IA con los modelos de Google, también está en la lista de afectados.

Remediación

La corrección principal es actualizar a Starlette 1.0.1, que rechaza las cabeceras Host que contienen caracteres inválidos en lugar de usarlas para la construcción de URL. Para las aplicaciones que no pueden actualizar de inmediato, la mitigación es reemplazar cualquier uso de request.url.path en middleware de autenticación o autorización con scope["path"] — la ruta del ámbito ASGI, que proviene directamente de la línea de solicitud HTTP y no se ve influenciada por la cabecera Host. La recomendación a largo plazo es evitar la autenticación basada en ruta en middleware por completo, favoreciendo los mecanismos a nivel de ruta Depends() y Security() de FastAPI.

El equipo de investigación publicó herramientas de detección junto con la divulgación: reglas Semgrep, consultas CodeQL para análisis estático y un escáner gratuito en badhost.org que puede probar endpoints directamente. El escáner admite tres modos: específico de MCP, autodescubrimiento de infraestructura de IA y prueba de rutas personalizadas, para que los equipos evalúen la exposición sin leer todo el aviso.

CVE-2026-48710 fue descubierto el 27 de enero de 2026 y coordinado para divulgación pública el 21–22 de mayo de 2026, tras el parche Starlette 1.0.1. Los detalles técnicos completos están en el aviso de X41 en x41-dsec.de.

Originally reported by OSTIF / X41 D-Sec. Read the original article for additional details.

View original source
Compartir: