Descripción general
Se ha identificado una vulnerabilidad en vLLM que permite eludir el mecanismo de autenticación del middleware AuthenticationMiddleware de la API OpenAI. El hallazgo fue realizado durante una auditoría de código fuente llevada a cabo por x41sec. La explotación permite utilizar la API sin proporcionar la clave configurada mediante VLLM_API_KEY o el parámetro --api-key.
Detalles técnicos
El problema reside en la forma en que vLLM extrae la ruta de la URL dentro del middleware de autenticación. En el archivo vllm/entrypoints/openai/api_server.py, la variable url_path se obtiene a partir del objeto URL reconstruido por starlette basándose en el scope de la solicitud entrante:
from starlette.datastructures import URL, Headers, MutableHeaders, State
# ...
url_path = URL(scope=scope).path.removeprefix(root_path)
headers = Headers(scope=scope)
if url_path.startswith("/v1") and not self.verify_token(headers):
response = JSONResponse(content={"error": "Unauthorized"}, status_code=401)
return response(scope, receive, send)
return self.app(scope, receive, send)
El scope de la solicitud incluye la cabecera Host: del cliente, y starlette reconstruye la URL completa con el siguiente patrón:
f"{scheme}://{host_header}{path}"
Ni starlette ni ninguno de los servidores ASGI disponibles, incluyendo uvicorn (que es el servidor utilizado por vLLM), filtran correctamente la cabecera Host: para detectar caracteres inválidos. Esto permite a un atacante inyectar caracteres especiales de URL como / o ? dentro de la cabecera Host:, logrando así controlar la URL reconstruida y, en particular, el valor del atributo .path resultante.
El enrutamiento de FastAPI y starlette opera sobre la ruta HTTP real de la solicitud y no depende del atributo .path parseado a partir de la URL reconstruida. Esto crea una discrepancia: un atacante puede alcanzar un endpoint mediante una ruta determinada mientras presenta un valor diferente en el atributo .path, engañando al middleware de autenticación para que no aplique la verificación del token.
Impacto
La vulnerabilidad afecta a las siguientes configuraciones:
- Instancias de vLLM que utilizan una clave de API (
VLLM_API_KEYo--api-key) para proteger la API OpenAI y que exponen dicha API directamente a potenciales atacantes.
Las instancias que se encuentran detrás de un servidor web conforme con el RFC, como nginx, no se ven afectadas, ya que estos servidores filtran correctamente las cabeceras Host: malformadas antes de que la solicitud llegue a vLLM.
Contexto y relevancia
Esta vulnerabilidad es especialmente crítica en entornos donde vLLM se despliega directamente expuesto a redes no confiables sin un proxy inverso intermedio. Un atacante que explote este fallo puede acceder libremente a los modelos de IA servidos por vLLM, incurriendo en costes computacionales no autorizados, extrayendo información procesada por el modelo o abusando de la infraestructura para otros fines maliciosos. La raíz del problema combina una confianza implícita en datos controlables por el cliente dentro de starlette y la ausencia de validación de la cabecera Host: en los servidores ASGI.
