CVE-2025-9141: el bug en vLLM que ejecuta código arbitrario

Una nueva superficie de ataque: el motor de inferencia

Los LLMs rara vez viven aislados. La mayoría corre dentro de un inference engine como vLLM, SGLang, TensorRT-LLM o llama.cpp, instalado en un servidor con GPUs que carga los pesos del modelo, decodifica tokens y entrega respuestas a un agente (Claude Code, Codex, Cursor, etc.) que se ejecuta en otra máquina.

Esa separación crea un objetivo extraño y atractivo. El host de inferencia tiene poder de cómputo valioso, acceso directo a los pesos del modelo y privilegios de red más altos que una máquina cualquiera en internet. Si un LLM malicioso consigue ejecutar código en ese host, no solo compromete al agente: compromete la infraestructura que carga los pesos y sirve al resto de los tenants.

El ensayo del investigador Boyd Kane, publicado en agosto de 2026 en su blog personal y republicado en LessWrong, argumenta que esta superficie es más débil de lo que parece. La idea central: el LLM controla la secuencia de tokens que el motor de inferencia recibe. Si ese parser tiene un bug, los tokens dejan de ser datos y se vuelven código a ejecutar.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El caso concreto: CVE-2025-9141 en vLLM

El ejemplo más claro que cita Kane es CVE-2025-9141, un bug de ejecución remota de código en el parser XML de tool-calls de vLLM para Qwen3 Coder. El parser pasaba casi todos los argumentos del tool call directamente a eval(). Un LLM podía emitir tokens que el parser interpretara como código Python arbitrario y se ejecutara en el host.

Lo más grave no es el bug en sí, sino la cadena de aprobación. Según el ensayo, Gemini revisó automáticamente el pull request que introdujo el bug y lo marcó como vulnerabilidad crítica. Aun así, el maintainer principal de vLLM hizo force-merge, argumentando que parsear una secuencia arbitraria de tokens a un chat completo no es trivial.

Kane también recoge un bug menor pero ilustrativo: en una discusión sobre LLMs que razonan, el modelo emitió el string <mm:think>. vLLM lo interpretó como el inicio de un bloque de razonamiento y rompió la respuesta. Es un parser fail benigno, pero demuestra que los inference engines no son conversores tontos de tokens a strings: son sistemas complejos con más de 200 arquitecturas de modelo soportadas y decenas de plantillas de chat en Jinja, y cualquier especificación mal escrita abre la puerta a que un output se ejecute en lugar de devolverse.

ShadowMQ: bugs que se copian entre frameworks

La debilidad no se limita a vLLM. En una investigación separada, la firma Oligo Security documentó lo que denominó el patrón ShadowMQ: una cadena de vulnerabilidades de ejecución remota que se propagó entre frameworks de inferencia por copy-paste.

La raíz fue el uso de recv_pyobj() de ZeroMQ combinado con pickle.loads() de Python: una combinación que ejecuta código arbitrario al deserializar. Según InfoWorld, Oligo reportó el patrón original como CVE-2024-50050 en Meta Llama Stack en septiembre de 2024, que parcheó el problema con serialización basada en JSON. Luego encontró el mismo patrón copiado en vLLM (CVE-2025-30165), Nvidia TensorRT-LLM (CVE-2025-23254) y Modular Max Server (CVE-2025-60455), a veces con comentarios como "Adapted from vLLM" en el código.

Según Oligo, SGLang ha sido adoptado por xAI, AMD, Nvidia, Intel, LinkedIn, Cursor, Oracle Cloud y Google Cloud, lo que da una idea del radio de exposición cuando un parser de inferencia tiene un bug serio. Las versiones parcheadas incluyen Meta Llama Stack v0.0.41, Nvidia TensorRT-LLM 0.18.2, vLLM v0.8.0 y Modular Max Server v25.6.

Por qué importa ahora: open-weight y cadena de suministro

Kane advierte que el problema se va a agravar. Los LLMs open-weight cada vez son más capaces, y muchos corren sobre motores de inferencia nuevos con menos escrutinio que los internos de OpenAI, Google o Anthropic. A eso se suma una segunda tendencia: cada vez se pide más a los propios LLMs que escriban o modifiquen el inference engine que los ejecuta, normalmente para optimizar performance. Un LLM malicioso en ese rol puede plantar un backdoor en componentes C++ o CUDA.

La superficie ya demostró ser explotable en la práctica. Según reportaron CloudSEK y Hudson Rock, el 24 de marzo de 2026 el atacante TeamPCP publicó versiones maliciosas de LiteLLM (1.82.7 y 1.82.8) en PyPI, que estuvieron activas unos 40 minutos. El compromiso inicial llegó por una vulnerabilidad previa en el scanner Trivy de Aqua Security. CloudSEK estima que el incidente expuso credenciales de más de 2.500 organizaciones y 434.000 pipelines de CI/CD, incluyendo nombres como Microsoft, Amazon, Cisco, Samsung, Salesforce, FedEx y HP. SecurityWeek señala que LiteLLM, la librería afectada, registra más de 97 millones de descargas mensuales.

No es el mismo vector que describe Kane (LiteLLM es un gateway, no un inference engine), pero confirma la tesis: la capa de infraestructura de IA es ahora un objetivo prioritario de atacantes reales, y un solo token no revocado puede contaminar toda una cadena.

Qué significa esto para tu startup

Si desplegás o consumís inferencia de LLMs en tu stack, hay tres acciones concretas para esta semana:

Auditar la versión de tu inference engine. Si usás vLLM, asegurate de estar en v0.8.0 o superior. Si usás TensorRT-LLM, 0.18.2 o superior. Si usás Llama Stack de Meta, v0.0.41 o superior. Las versiones anteriores a esos parches tienen el patrón ShadowMQ documentado por Oligo.
Tratar el host de inferencia como zona de alta sensibilidad. Separar el host GPU del parser de tokens siempre que sea posible: el GPU emite logits, otra máquina muestrea tokens y los parsea. Si el parser cae, no cae el GPU. Es la arquitectura que recomienda Kane y la que ya usan proveedores serios.
Rotar credenciales si usaste LiteLLM entre el 19 y el 24 de marzo de 2026. CloudSEK recomienda asumir compromiso de cualquier secreto accesible a las versiones afectadas (1.82.7 y 1.82.8), incluyendo SSH keys, tokens cloud, Kubernetes tokens y API keys de proveedores de IA.

A más largo plazo, el ensayo de Kane deja una pregunta incómoda: si los inference engines son software complejo bajo presión constante de rendimiento, y los LLMs pronto podrán auditar su propio código de ejecución, ¿cuánto falta para que un modelo descubra y explote su primer 0-day? No hay respuesta, pero la conversación ya no puede seguir siendo "son solo tokens".