El 2 de septiembre CISA incorporó a su catálogo KEV un fallo con CVSS 6,5 que afecta a una librería ausente del inventario de casi cualquier organización. Entró en la misma tanda de siete vulnerabilidades explotadas que dos fallos de SonicWall SMA, una centralita Sangoma, Artifactory, Kestra y un segundo fallo de LiteLLM (CVE-2026-59822). La librería se llama Starlette, es el marco ASGI de Python en el que se apoya FastAPI, y procesa cada petición HTTP que recibe LiteLLM, vLLM o cualquiera de los muchos servidores MCP escritos en Python.
El fallo, CVE-2026-48710, recibió el nombre de BadHost de sus descubridores en badhost.org y es público desde que OSTIF detalló el caso el 26 de mayo; Starlette 1.0.1, publicada antes de esa fecha, lo corrige. La novedad del verano está en el uso que se le ha dado. Wiz lo ha visto en sus honeypots y Microsoft valora que una intrusión real entró por esa vía: en ambos casos, encadenado con un fallo de LiteLLM que permite ejecutar código en la pasarela de IA sin credenciales. Una vez dentro, el objetivo son las credenciales de proveedores de modelos que la pasarela custodia.
En Hard2bit comprobamos la versión de Starlette de forma sistemática en las revisiones de agentes de IA desde junio. El motivo es sencillo: la mayoría de los equipos no sabe qué versión de esa librería viaja dentro de sus contenedores.
Qué se puede explotar y desde cuándo
El aviso del proyecto Starlette describe el fallo con precisión. Las versiones anteriores a 1.0.1 construyen la URL de cada petición pegando la cabecera Host a la ruta y analizando de nuevo el resultado, sin validar antes que la cabecera respete la gramática de los RFC 9112 y 3986. El enrutador de Starlette, en cambio, selecciona la función que atiende la petición a partir de la ruta original. En consecuencia, un middleware que decida según la URL reconstruida y el enrutador que ejecuta la función pueden interpretar rutas distintas para una misma petición.
La puntuación CVSS asignada a CVE-2026-48710 es 6,5: impacto bajo en confidencialidad e integridad y nulo en disponibilidad. Quienes lo descubrieron dejaron escrito en badhost.org que esa cifra se queda corta para todo lo que se apoya en Starlette, porque el fallo aislado no filtra información. Su efecto consiste en desactivar los controles que dependen de request.url, que casi siempre son los que protegen prefijos como /admin o /v1/models, separan a los inquilinos de una plataforma, aplican cuotas o facturación y protegen contra CSRF. El daño final lo determina la aplicación que hay detrás de esos controles.
Cronología: de una auditoría de vLLM al catálogo KEV
La secuencia de fechas explica por qué un fallo publicado en mayo ocupa titulares en septiembre.
- Enero de 2026. Un analista de X41 D-Sec localiza el fallo mientras audita vLLM en un encargo gestionado por OSTIF y financiado por el proyecto Alpha-Omega, según cuentan OSTIF y CSO Online. El objeto de la auditoría era el servidor de inferencia; el fallo estaba en la librería de la que depende.
- 20 de abril. Se publica CVE-2026-42271, una inyección de comandos en las rutas de la API de LiteLLM que prueban configuraciones de servidores MCP. Se considera de impacto limitado porque solo la puede usar quien tenga una credencial de API válida del proxy.
- 8 de mayo. LiteLLM 1.83.7 corrige esa inyección y actualiza además la versión de Starlette que incorpora, según la cronología de Horizon3.
- 26 de mayo. OSTIF publica los detalles ampliados de BadHost y justifica el paso por la lentitud con la que se adoptaba Starlette 1.0.1 y por los servicios vulnerables que seguían apareciendo expuestos en Internet. El Centro de Ciberseguridad de Bélgica (CCB) emite su aviso el 28 de mayo.
- 1 de junio. Horizon3 confirma que BadHost permite saltarse la autenticación de LiteLLM, con lo que CVE-2026-42271 pasa a ser ejecución remota de código sin credenciales. La cadena completa recibe una valoración de CVSS 10.
- 9 de junio. CISA incorpora el fallo de LiteLLM al catálogo KEV. En los honeypots de Wiz, esa vía se emplea para instalar mineros de criptomonedas.
- 26 y 27 de agosto. Microsoft Threat Intelligence publica el análisis de tres intrusiones en infraestructura de IA, una de ellas en una pasarela LiteLLM. Un día después, Wiz publica 90 días de telemetría de sus honeypots.
- 2 de septiembre. CISA añade CVE-2026-48710 al catálogo KEV. Según recoge The Hacker News, la directiva BOD 26-04 da a las agencias federales hasta el 16 de septiembre para corregirlo.
Cómo engaña una sola cabecera al middleware
Una aplicación web trabaja con dos versiones de cada petición: la que llegó por la red, sin procesar, y los objetos que el marco monta encima para facilitar el trabajo al programador. En Starlette, el enrutador se guía por la primera y el objeto request.url pertenece a la segunda. Si la cabecera Host lleva caracteres que dentro de una URL separan la ruta de la consulta o del fragmento, la reconstrucción mueve esos límites y request.url.path ya no coincide con la ruta que el enrutador ejecutará.
Con esa discrepancia, un middleware de autenticación que compare request.url.path con una lista de prefijos protegidos examina una ruta manipulada, decide que no exige credenciales y deja pasar la petición. El enrutador de Starlette, que no consulta la cabecera Host, ejecuta la función asociada a la ruta legítima con todas sus consecuencias. Al atacante le basta con saber qué ruta quiere alcanzar; no necesita credenciales ni la intervención de ningún usuario.
La huella que deja BadHost es igual de sencilla: peticiones cuya cabecera Host no contiene un nombre de máquina válido. Horizon3 lo incluye entre sus indicadores de compromiso, y ese campo es lo primero que hay que revisar en los registros del proxy inverso o, a falta de proxy, en los del servidor ASGI.
La combinación con LiteLLM muestra cómo BadHost multiplica el alcance de otro fallo. CVE-2026-42271 permite a un usuario autenticado indicar un comando que el proxy ejecutará como subproceso al probar un servidor MCP por stdio. Aislado, ese fallo exige credenciales; precedido de BadHost, cualquiera desde Internet llega a esa ruta sin ellas. Wiz describe a los atacantes enviando una configuración de servidor MCP ficticia cuyo comando descarga y arranca un minero, y respondiendo después con un saludo MCP correcto para que la prueba de conexión figure como superada.
En esas mismas sesiones de honeypot, Wiz observó cómo los atacantes obtenían la credencial maestra del proxy LiteLLM leyendo directamente el estado de los módulos de Python cargados en memoria, sin necesidad de rastrear ficheros en disco.
Quién está expuesto y con qué condiciones
OSTIF enumera como afectados FastAPI, LiteLLM, vLLM, los proyectos de inferencia de texto, la mayoría de los proxies compatibles con la API de OpenAI, servidores MCP, entornos de ejecución de agentes, paneles de evaluación e interfaces de gestión de modelos. Para dimensionarlo sirve una cifra del informe sobre el estado de la IA en la nube que cita Wiz: el 90 % de los entornos cloud ejecuta software de IA autoalojado.
Para que BadHost sea explotable deben darse dos condiciones al mismo tiempo. Primera: algún middleware, dependencia o decorador de la aplicación toma decisiones de seguridad a partir de request.url o request.url.path. Segunda: las peticiones llegan al servidor ASGI (uvicorn, hypercorn, daphne o granian) sin atravesar un proxy inverso que rechace cabeceras Host mal formadas. OSTIF indica que nginx, Apache httpd y Cloudflare descartan la petición maliciosa con su configuración por defecto, con una salvedad: los frontales que terminan HTTP/3 o QUIC hay que probarlos aparte, porque su validación de Host no siempre se comporta como la de HTTP/1.1.
Las dos condiciones coinciden sobre todo en los despliegues que menos atención reciben: un proxy LiteLLM arrancado con docker compose para un equipo de datos, un servidor vLLM sobre la GPU del laboratorio o un servidor MCP interno a la escucha en un puerto alto. Pocos de esos sistemas tienen nginx delante y muchos son alcanzables desde la VPN corporativa o desde una subred que en su día se consideró de confianza. Ese perímetro difuso es el terreno natural de BadHost, y un análisis de superficie de ataque que abarque la red interna suele localizarlo antes que el escáner de vulnerabilidades.
A la exposición se suma un problema de inventario. Casi nadie instala Starlette de forma deliberada: entra como dependencia transitiva de FastAPI, de LiteLLM o del SDK de MCP. La base de avisos de GitLab vincula quince avisos RHSA de Red Hat con este único CVE, uno por cada producto que incorporaba la librería como dependencia. Sin un SBOM o un escaneo de imágenes, la manera más fiable de saber si se está afectado consiste en revisar contenedor por contenedor.
Detección y contención inmediata
La señal más temprana de BadHost es la cabecera Host. Registrar su valor en el proxy inverso y alertar cuando contenga una barra, un signo de interrogación o una almohadilla permite ver los intentos antes de que se ejecute nada más. Cuando el servidor ASGI está expuesto sin proxy, ese registro tiene que generarlo la aplicación.
En el caso concreto de las pasarelas de IA, Horizon3 aconseja vigilar las peticiones a /mcp-rest/test/connection y /mcp-rest/test/tools/list, dos rutas que en una instalación normal apenas reciben tráfico, junto con cualquier subproceso que arranque desde el proceso de LiteLLM. Microsoft, que reconstruyó una intrusión completa con la telemetría de los equipos, publica consultas KQL de búsqueda de amenazas con la misma lógica. Buscan el proceso de la pasarela como padre de una shell, de un intérprete de Python o de curl, y lo cruzan con tres tipos de señal:
- lecturas de /proc/1/environ, el fichero que dentro de un contenedor expone las variables de entorno del proceso principal;
- líneas de comando que mencionan DATABASE_URL o las tablas LiteLLM_ProxyModelTable y LiteLLM_VerificationToken;
- conexiones salientes hacia direcciones IP sin nombre de dominio o hacia dominios de callback fuera de banda.
Cuando aparece alguna de esas señales en una pasarela LiteLLM, la contención sigue el orden inverso al habitual. Antes de detener el contenedor hay que dar por copiadas las credenciales: en la intrusión que reconstruyó Microsoft, lo primero que hizo el atacante fue leer el entorno del proceso y filtrarlo buscando credenciales de proveedor, la clave maestra, cadenas de conexión y contraseñas de la interfaz. Por eso la rotación de las credenciales de proveedores de modelos, de las claves virtuales emitidas por el proxy y de la cadena de conexión a la base de datos precede a cualquier otra medida.
Después de rotar las credenciales toca revisar las cuentas de los proveedores de IA en busca de consumo anómalo, modelos nuevos o credenciales creadas sin autorización. Es el rastro que un servicio de threat hunting persigue cuando el atacante ya ha abandonado el servidor.
Parcheo, y qué hacer si no se puede parchear
La corrección de BadHost es Starlette 1.0.1; en LiteLLM, la versión 1.83.7 o posterior, que cierra además la inyección de comandos. La dificultad está en que actualizar el paquete en el host apenas sirve cuando la librería va empaquetada en una imagen. OSTIF pide reconstruir y desplegar de nuevo cada contenedor, entorno virtual y artefacto que fije o incorpore Starlette, y advierte de que el listado de paquetes del host no prueba nada.
Si reconstruir no es viable a corto plazo, hay tres mitigaciones que actúan sobre las condiciones que hacen explotable el fallo.
- Sustituir request.url y request.url.path por request.scope["path"] en cualquier middleware, dependencia o decorador que tome decisiones de seguridad. Es el valor sin reconstruir, y OSTIF lo considera la corrección duradera, porque esta clase de fallo puede volver a aparecer.
- Poner un proxy inverso que rechace cabeceras Host mal formadas delante de cada aplicación servida por ASGI, y verificar con el comprobador remoto de badhost.org que la configuración elegida lo hace. El CCB belga recomienda además evitar la autenticación basada en la ruta y vincular la comprobación de credenciales al endpoint concreto de la API.
- Retirar de Internet las superficies de administración y de gestión de claves. Microsoft propone tratar las pasarelas de IA como almacenes de secretos de Tier 0, el nivel de mayor criticidad: autenticación tanto en la API como en la interfaz, puertos de gestión restringidos, claves virtuales por equipo con límites de gasto en lugar de una clave maestra compartida, y secretos guardados en un gestor dedicado y no en variables de entorno del proceso.
Buena parte de las guías de endurecimiento para agentes de IA se centran en la inyección de prompts y en los permisos de las herramientas. Los casos publicados por Microsoft y Wiz muestran a atacantes que entraron por un fallo web clásico, leyeron variables de entorno y consultaron una base de datos PostgreSQL. Por esa razón, la auditoría de seguridad de agentes de IA y servidores MCP que realizamos en Hard2bit dedica tanto tiempo a la capa HTTP y al despliegue como al agente.
Qué vigilar en las próximas semanas
La entrada de un fallo en el catálogo KEV suele preceder en pocos días a su incorporación a los escáneres masivos. Wiz, remitiéndose a investigadores externos, relaciona la explotación de la cadena de LiteLLM con operadores vinculados al ransomware Qilin; Microsoft describe robo de credenciales, persistencia mediante claves SSH y tareas programadas, y minería de criptomonedas. Ninguno de los dos informes recoge todavía un uso de BadHost contra aplicaciones FastAPI corrientes ajenas al ecosistema de IA. Esa es la evolución que hay que seguir, porque la superficie es muchísimo mayor y el fallo es el mismo.
El IDOR de Langflow y las campañas de LLMjacking ya habían enseñado que la infraestructura de IA concentra credenciales y que quien la ataca sabe dónde buscarlas. BadHost añade a esa lección una puerta de entrada que no está en la aplicación de IA sino en la librería web que la sirve.
Hay un segundo frente: los SDK y herramientas que llevan Starlette embebido y que pueden no aparecer en ningún escaneo de paquetes. Un servidor MCP escrito con el SDK de Python y publicado como imagen hace seis meses contiene la versión de Starlette que existía entonces. Qué versión incluye la imagen y cuándo se reconstruyó por última vez: esa es la consulta que un programa de gestión de vulnerabilidades debería trasladar al proveedor esta misma semana.
Este artículo combina información técnica de avisos públicos con datos de investigaciones de terceros (OSTIF, X41 D-Sec, Horizon3, Wiz y Microsoft), con la información disponible a fecha de publicación. Las configuraciones y medidas descritas son orientativas: cada despliegue debe validarlas en un entorno de pruebas antes de aplicarlas en producción. Las atribuciones a grupos y el alcance de la actividad pueden evolucionar a medida que avancen las investigaciones.
