CVE-2025-62164 es una vulnerabilidad de alta gravedad en vLLMuno de los motores de inferencia LLM de código abierto más utilizados. El problema vive dentro del API de finalización y se activa cuando el servidor procesa incrustaciones de avisos proporcionadas por el usuario. En las versiones afectadas (0.10.2 hasta 0.11.1 inclusive), vLLM deserializa los tensores utilizando torch.load() sin una validación sólida. Un tensor disperso manipulado puede colarse y causar un escritura fuera de límites durante la densificaciónque bloquea de forma fiable el trabajador y puede escalarse a ejecución remota de código en las condiciones adecuadas. El proyecto envió una solución en vLLM 0.11.1. (NVD)

Dos cosas hacen que esta CVE sea diferente de los habituales bichos de la pila de IA. En primer lugar, es un fallo en el plano de datosEn segundo lugar, se encuentra en la intersección exacta de la interfaz de usuario de administración y el punto final de inferencia. En segundo lugar, se encuentra en la intersección exacta de deserialización insegura y deriva de comportamiento ascendenteuna combinación que sigue apareciendo a medida que madura la infraestructura del LLM.

Qué lugar ocupa vLLM en la pila y por qué aumenta el riesgo

vLLM es una capa de inferencia de rendimiento optimizado. Los equipos lo despliegan como una API SaaS pública, detrás de una pasarela empresarial o como backend de servicio para sistemas de agentes multiusuario. En todos estos casos, vLLM está cerca de Internet y de los recursos de la GPU. Eso suena a ingeniería de rendimiento; también significa los usuarios de la API con pocos privilegios pueden acceder a rutas de código privilegiadas. (wiz.io)

Así que el radio de explosión no es sutil. Un único punto final bloqueable puede provocar la inanición de la GPU, la acumulación de colas, la rotación del autoescalador e incidentes ruidosos con los vecinos. Si la explotación se estabiliza en RCE, la flota de inferencia se convierte en un punto de apoyo legítimo para la intrusión en la cadena de suministro.

La vulnerabilidad en un párrafo

El endpoint Completions en versiones vulnerables de vLLM permite a los clientes pasar incrustaciones rápidas en lugar de texto en bruto. vLLM reconstruye esos tensores mediante torch.load() sin suficientes comprobaciones de integridad, tipo o estructura. Desde PyTorch 2.8.0 desactiva por defecto las comprobaciones de integridad de los tensores dispersosun tensor disperso malicioso puede eludir las protecciones internas de límites y provocar un escritura en memoria fuera de límites cuando to_dense() se llama. El resultado inmediato y repetible es DoS remoto (fallo del trabajador). Con una disposición y control de la memoria favorables, la misma primitiva podría convertirse plausiblemente en RCE en el host. (NVD)

Anatomía de la causa raíz: Cómo el "cómodo paso de incrustación" se convirtió en corrupción de memoria

Un sumidero de deserialización en un punto final público

torch.load() es potente por diseño. Está pensado para restaurar tensores y gráficos de objetos desde fuentes fiables (puntos de control, canalizaciones internas). En el caso de vLLM, se utiliza en un campo que puede ser rellenado por una API. Eso cambia el límite de confianza de "artefacto de modelo interno" a "entrada de Internet no fiable", que es históricamente donde la deserialización insegura explota. (NVD)

Aunque este problema se manifiesta como corrupción de memoria en lugar de una clásica cadena pickle-RCE, el error subyacente es el mismo: tratar una estructura binaria compleja como si fuera un parámetro más de la solicitud.

El cambio de comportamiento de PyTorch 2.8.0 fue la chispa

Tanto el aviso de vLLM como NVD apuntan a un cambio en PyTorch: las comprobaciones de integridad de los tensores dispersos están ahora desactivadas por defecto. Anteriormente, los tensores dispersos malformados tenían más probabilidades de ser rechazados antes de que la ruta del código alcanzara la densificación. Con las comprobaciones desactivadas, la falta de pre-validación de vLLM se volvió explotable de forma consistente. (NVD)

Se trata de un modelo mental útil para la infraseguridad de la IA: Los defectos de aguas arriba pueden convertir silenciosamente "inseguro pero inactivo" en "inseguro y armable".

La realidad del impacto: DoS está garantizado, RCE es un techo

Todos los escritos públicos coinciden en que el DoS remoto es fiable. Una sola petición malformada puede matar a un trabajador; las peticiones repetidas pueden mantener una flota inestable. (ZeroPath)

La RCE se describe como potencial por una buena razón. La corrupción de la memoria proporciona una vía, pero el armamento depende del comportamiento del asignador, las banderas de endurecimiento, los límites del contenedor y cuánto control tiene el atacante sobre la región corrupta. Hay ninguna lista CISA KEV y ninguna cadena de exploits in-the-wild ampliamente confirmada hasta el 25 de noviembre de 2025, pero tratar la corrupción de memoria del plano de datos como "sólo DoS" sería un error. (wiz.io)

Versiones afectadas y estado de las correcciones

(NVD)

Quién debe entrar en pánico primero: Modelos de amenaza que importan

Si quieres una lente de priorización práctica, piensa en dónde pueden entrar las incrustaciones en tu sistema.

Los puntos finales públicos de vLLM son el caso obvio de alto riesgo. Incluso si las personas que llaman necesitan una clave API, el listón está bajo: un usuario normal con acceso básico puede ser suficiente para colapsar sus trabajadores. (wiz.io)

A continuación vendrán las plataformas "LLM como servicio" multiusuario. El peligro es que las incrustaciones fluyan en indirectamente - a través de cadenas de herramientas, plugins, marcos de agentes o servicios ascendentes que pasan incrustaciones como una optimización. Cuantos más lugares acepten cargas no textuales, más complicado será el límite de confianza.

Por último, no descartes las demostraciones comunitarias y las implantaciones educativas. A menudo no están autenticadas, no se supervisan lo suficiente y quedan expuestas mucho después de que el propietario se olvide de que existen.

Formas seguras de confirmar la exposición (sin sondeos arriesgados)

El triaje más rápido es el basado en versiones.

python -c "import vllm; print(vllm.__version__)"
# afectado si 0.10.2 <= versión < 0.11.1

(NVD)

Desde el punto de vista operativo, busque un patrón de fallos de los trabajadores o reinicios bruscos vinculadas a solicitudes de finalización inusualmente grandes o estructuralmente extrañas. En la práctica, los picos de cuelgues aparecen primero; la explotación sofisticada (si es que llega) viene después. (ZeroPath)

Una comprobación canaria inofensiva -terminación estándar, sin paso de incrustación- es útil para la estabilidad de referencia en torno a los parches:

importar peticiones, json, tiempo

HOST = "https:///v1/completions"
headers = {"Authorization": "Bearer "}

carga útil = {
    "model": "tu-nombre-modelo",
    "prompt": "chequeo",
    "max_tokens": 4
}

for i in range(5):
    r = requests.post(HOST, headers=headers, data=json.dumps(payload), timeout=10, verify=False)
    print(i, r.código_estado, r.texto[:160])
    time.sleep(1)

Parchee rápido, luego endurezca el plano de datos

La solución real es simplemente actualizar a vLLM 0.11.1 o posterior. Todo lo demás es un parche. (NVD)

Después de eso, trate las "entradas de inferencia binaria" como sumideros de alto riesgo. Si su producto realmente necesita el paso a través de la incrustación, bloquéelo con una validación estricta del esquema: aplique los tipos de tensor esperados, las formas, los tamaños máximos y prohíba los formatos dispersos a menos que los admita explícitamente. Incluso una lista de permisos tonta bloquea la clase específica de estructuras malformadas en las que se basa esta CVE. (wiz.io)

Por el lado de la infraestructura, bloquea el radio de explosión. Los trabajadores de vLLM deben ejecutarse con los mínimos privilegios, sistemas de archivos de sólo lectura siempre que sea posible, sin montajes de host sensibles y perfiles seccomp/AppArmor de contenedor. Si alguien alguna vez encadena la corrupción de memoria en la ejecución de código, lo quieres atrapado en una caja que no pueda alcanzar secretos o rutas laterales.

Por qué CVE-2025-62164 es importante para la seguridad de la IA como disciplina

Este incidente es un claro ejemplo de cómo la seguridad de la IA se está alejando de los clásicos manuales de aplicaciones web.

La nueva frontera es planos de datos modelo-serviciotensores, incrustaciones, blobs multimodales y artefactos serializados que se mueven a través de APIs porque son rápidos y convenientes. También son estructuralmente ricos y frágiles - perfectos para errores de corrupción si deserializas sin paranoia.

También es un recordatorio de que la superficie de riesgo de una pila LLM es composición. vLLM no "inventó" la inseguridad del tensor disperso; un valor por defecto de PyTorch cambió, y una capa de validación faltante convirtió ese cambio en una CVE. La ingeniería de inferencias necesita ahora el mismo nivel de escrutinio de dependencias que los equipos del núcleo dan por sentado.

Validación controlada cuando las PdC son confusas o llegan tarde

Las CVEs de AI infra a menudo llegan antes que las PoCs públicas estables, o con PoCs que son demasiado arriesgadas para apuntar a clústeres de servicio de producción. El enfoque defendible consiste en industrializar un bucle más seguro: información autorizada → hipótesis → validación exclusiva en laboratorio → pruebas auditables.

En los flujos de trabajo agénticos al estilo Penligent, puede hacer que los agentes ingieran el aviso vLLM y el registro NVD, deriven las condiciones de exposición exactas (versiones, ruta de incrustación, suposiciones de PyTorch) y generen un plan de validación de riesgo mínimo que se ejecuta sólo en una réplica aislada. Así obtendrás pruebas reales (huellas de versiones, firmas de fallos, deltas pre y post parche) sin tener que jugar con tus GPUs. (NVD)

Igualmente importante es el hecho de que la información basada en pruebas facilita la explicación de la urgencia a los responsables de operaciones. El "hemos parcheado porque lo dice un blog" no sobrevive a la revisión de incidentes. "CVE-2025-62164 PoC: vLLM's Completions Data-Plane Bug That Turns Embeddings In an Attack Surface (CVE-2025-62164 PoC: fallo en el plano de datos de las finalizaciones de vLLM que convierte las incrustaciones en una superficie de ataque)