CVE-2025-62164 PoC: vLLM's Completions Data-Plane Bug That Turns Embeddings In an Attack Surface

Resumen ejecutivo

A medida que madura la infraestructura de modelos de grandes lenguajes (LLM), la superficie de ataque se desplaza de las interfaces de gestión tradicionales ("Plano de control") al flujo real de datos de inferencia ("Plano de datos").

CVE-2025-62164 representa una vulnerabilidad que cambia el paradigma en vLLMel motor estándar de la industria para el servicio LLM de alto rendimiento. Este fallo permite a los atacantes utilizar como arma el /v1/completaciones inyectando virus maliciosos incrustaciones rápidas. Al explotar mecanismos de deserialización inseguros dentro de la lógica de carga de PyTorch, un atacante puede provocar la corrupción de memoria, lo que lleva a la denegación de servicio (DoS) y la potencial ejecución remota de código (RCE), todo ello sin necesidad de claves de API válidas (dependiendo de la configuración de despliegue).

Este análisis desglosa la causa técnica raíz, proporciona una prueba de concepto (PdC) conceptual y esboza los pasos inmediatos de corrección para los ingenieros de la plataforma de IA.

El vector de ataque: Por qué las incrustaciones son peligrosas

En las interacciones LLM estándar, los usuarios envían texto. Sin embargo, los motores de inferencia avanzados como vLLM admiten entradas de incrustación (datos de tensor) directamente a través de la API. Esto está pensado para optimizar el rendimiento y los flujos de trabajo multimodales, pero abre una puerta peligrosa: Deserialización directa de objetos.

La vulnerabilidad reside en cómo vLLM procesa estos tensores entrantes. En concreto, el motor confía implícitamente en la estructura de los datos serializados proporcionados por el usuario, asumiendo que se trata de una representación matemática inofensiva.

La ruta del código vulnerable

El fallo crítico está en vllm/entrypoints/renderer.py dentro del cargar y validar incrustación función.

Python

# Representación simplificada de la lógica vulnerable
importar antorcha
importar io
importar pybase64

def _load_and_validate_embed(embed: bytes):
    # PELIGRO: Deserialización de flujos binarios no fiables
    tensor = torch.load(
        io.BytesIO(pybase64.b64decode(embed, validate=True)),
        weights_only=True, # La falsa sensación de seguridad
        map_location=torch.device("cpu"),
    )
    devolver tensor

En weights_only=Verdadero tiene por objeto evitar la ejecución de código Python arbitrario (una vulnerabilidad común de Pickle), es insuficiente para prevenir la corrupción de memoria cuando se trabaja con tipos de tensor específicos de PyTorch.

Profundización técnica: Explotación de tensores dispersos

El núcleo de CVE-2025-62164 aprovecha una desconexión entre las banderas de seguridad de PyTorch y su manejo de Tensores dispersos.

1. El turno de PyTorch 2.8+: Las versiones más recientes de PyTorch omiten por defecto las costosas comprobaciones de integridad de los tensores dispersos para mejorar el rendimiento.
2. El Bypass: Un atacante puede construir un tensor "Sparse COO" (Formato de Coordenadas) malformado. Incluso con weights_only=Verdadero, carga.antorcha deserializará esta estructura.
3. Corrupción de la memoria: Dado que los índices del tensor disperso no se validan con respecto al tamaño declarado durante la carga, las operaciones posteriores (como convertir el tensor a formato denso o moverlo a la memoria de la GPU) dan como resultado un error Escritura fuera de límites (OOB).

Esta escritura OOB bloquea el intérprete de Python inmediatamente (DoS). Con un sofisticado heap spraying y manipulación de la disposición de la memoria, esta primitiva puede ser escalada para obtener el control del puntero de instrucción, logrando RCE.

Análisis de la prueba de concepto (PdC)

Descargo de responsabilidad: Este PdC sólo tiene fines educativos y defensivos.

1. Construcción de la carga útil

El atacante crea un tensor PyTorch serializado que viola las restricciones de consistencia interna.

Python

importar torch
importar io
importar base64

def generar_exploit_payload():
    buffer = io.BytesIO()
    
    # Crear un tensor disperso diseñado para activar la escritura OOB en el acceso
    # Los índices específicos estarían diseñados para apuntar fuera de la memoria asignada
    # tensor_malformado = torch.sparse_coo_tensor(indices=..., values=..., size=...)
    
    # Para demostración, simulamos la serialización
    # En un ataque real, este búfer contiene el flujo binario pickle
    torch.save(tensor_malformado, buffer)
    
    # Codificar para transporte JSON
    return base64.b64encode(buffer.getvalue()).decode('utf-8')

2. La solicitud de explotación

El atacante envía este payload al endpoint de finalización estándar.

POST http://target-vllm-instance:8000/v1/completions

JSON

{
  "model": "meta-llama/Llama-2-7b-hf",
  "prompt": {
    "embedding": ""
  },
  "max_tokens": 10
}

3. El resultado

• El mejor caso: El proceso vLLM worker encuentra un fallo de segmentación y se bloquea. Si el orquestador (por ejemplo, Kubernetes) lo reinicia, el atacante puede simplemente reenviar la solicitud, creando una denegación de servicio persistente.
• En el peor de los casos: La corrupción de memoria sobrescribe los punteros de función, lo que permite al atacante ejecutar shellcode en el contexto del contenedor.

Evaluación de impacto

• Disponibilidad (Alta): Este es un DoS trivial de ejecutar. Una sola petición puede derribar un nodo de inferencia. En entornos de clúster, un atacante puede iterar a través de los nodos para degradar todo el clúster.
• Confidencialidad e integridad (crítica): Si se consigue el RCE, el atacante obtiene acceso a las variables de entorno (que a menudo contienen tokens Hugging Face, claves S3 o claves WandB) y a los pesos del modelo propietario cargados en memoria.

Remediación y mitigación

1. Actualizar inmediatamente

La vulnerabilidad está parcheada en vLLM v0.11.1.

• Acción: Actualiza tus imágenes Docker o paquetes PyPI a la última versión inmediatamente.
• Arregla la lógica: El parche implementa una lógica de validación estricta que rechaza los formatos de tensor no seguros antes de que interactúen con el asignador de memoria.

2. Sanitización de entrada (nivel WAF/Gateway)

Si no puede actualizar inmediatamente, debe bloquear el vector de ataque en la puerta de enlace.

• Acción: Configure su pasarela API (Nginx, Kong, Traefik) para inspeccionar los cuerpos JSON entrantes.
• Regla: Bloquear cualquier solicitud de /v1/completaciones donde el consulte contiene un objeto con incrustación llave.

3. Segmentación de la red

Asegúrese de que su servidor de inferencia no está expuesto directamente a la Internet pública. El acceso debe estar mediado por un servicio backend que depure las entradas y gestione la autenticación.

Conclusión

CVE-2025-62164 sirve como llamada de atención para la seguridad de la IA. No podemos seguir tratando los "Modelos" y los "Embeddings" como datos inertes. En la era de la IA, los datos son códigoy deserializarlo requiere el mismo nivel de escrutinio que ejecutar un ejecutable binario.

Para los equipos que realizan Pen-testing en infraestructuras de IA (como Penligent.ai), la comprobación de los puntos finales de serialización expuestos en los motores de inferencia debería ser ahora una parte estándar del ámbito de compromiso.

Nota del autor: Mantenga su infraestructura de IA segura. Valide siempre las entradas, no confíe nunca en los datos serializados y mantenga las versiones de vLLM fijadas a la última versión estable.