vLLM: una sola regex puede congelar un worker de inferencia

¿Qué es esto?

El 6 de julio de 2026 se publicó un aviso de seguridad para vLLM, uno de los motores de inferencia y servicio de código abierto más implantados para grandes modelos de lenguaje. El fallo es una debilidad de denegación de servicio en la función de salidas estructuradas: el parámetro de la API que permite a un cliente restringir la salida de un modelo para que cumpla una expresión regular entregaba ese patrón suministrado por el usuario directamente al compilador de gramática, sin ningún límite de tiempo ni de complejidad. Una sola petición con un patrón malicioso podía inmovilizar indefinidamente un worker de inferencia. Se clasifica como un fallo de complejidad ineficiente de expresiones regulares (CWE-1333), más conocido como ReDoS, y afecta a todas las versiones anteriores a la 0.24.0, donde queda corregido.

No es un ataque a nivel de prompt ni un jailbreak del modelo. Es un fallo de disponibilidad clásico de la capa de servicio que resulta estar alojado en una función propia de los LLM, exactamente el tipo de superficie que crece a medida que los equipos incorporan la decodificación restringida a sus API de producción.

Cómo funciona

Las salidas estructuradas permiten a una aplicación obligar a un modelo a emitir texto conforme a un esquema —JSON, una gramática o una expresión regular en bruto— restringiendo el decodificador en cada token. Para ello, la regex elegida debe compilarse en una máquina de estados que consulta el sampler.

En las versiones afectadas, ese paso de compilación se ejecutaba sin protección. En el backend xgrammar, el patrón llegaba directamente al compilador de regex. En el backend outlines, la validación rechazaba algunas construcciones estructurales como los lookarounds y las backreferences, pero no realizaba ningún análisis de complejidad: un patrón construido con cuantificadores anidados pasaba así todas las comprobaciones y luego explotaba. Ciertas formas de regex llevan al compilador a explorar un número exponencial de estados, de modo que una cadena corta y de apariencia inofensiva se traduce en un trabajo prácticamente ilimitado. Como la petición se acepta a través de la red sin autenticación y la compilación ocurre antes de cualquier generación, una sola llamada manipulada basta para bloquear el worker y privar de servicio a todas las peticiones legítimas que se le enrutan. El impacto reportado afecta solo a la disponibilidad —sin ejecución de código ni divulgación de datos—, con un vector de ataque de red y sin privilegios necesarios. Deliberadamente no reproducimos aquí ningún patrón desencadenante; lo importante es el mecanismo, no una carga lista para usar.

Por qué importa

vLLM ocupa el centro de un gran número de pilas de LLM autoalojadas y empresariales, a menudo tras una pasarela interna que confía en quienes la invocan. Las salidas estructuradas son una forma habitual de hacer que las respuestas del modelo sean procesables por programas, así que el parámetro vulnerable no es un rincón oscuro, sino una función a la que se recurre precisamente en las canalizaciones automatizadas de alto rendimiento, donde un bloqueo inadvertido causa más daño. En un despliegue multiinquilino compartido, un solo inquilino capaz de fijar la regex puede degradar el servicio de todos los demás en el mismo grupo de workers, y un endpoint expuesto convierte una petición de una línea en una caída de bajo coste. Es un recordatorio útil: la capa de servicio de los LLM hereda todos los riesgos ordinarios de un servicio web además de los propios de los modelos. Debilidades de disponibilidad vecinas en el mismo motor —desde un fallo de agotamiento de memoria por subida de audio hasta la superficie de ataque más amplia de la capa de servicio— apuntan a la misma lección.

Defensas

Actualice vLLM a la 0.24.0 o posterior. Es la corrección principal y completa: el parche añade un paso de compilación acotado, de modo que un patrón hostil falla rápido en lugar de bloquearse. El aviso también documenta un control de tiempo límite de compilación (VLLM_REGEX_COMPILATION_TIMEOUT_S, con cinco segundos por defecto) que lanza un error en vez de bloquear indefinidamente, dándole un valor que registrar y sobre el que alertar.

Más allá del parche, trate el parámetro regex como entrada no confiable. Si su aplicación no necesita expresiones regulares suministradas por el cliente, desactive o fije en el código el patrón de las salidas estructuradas en lugar de dejar pasar valores del usuario. Donde deba aceptarlas, valide la longitud y la complejidad del patrón antes de compilar y rechace los cuantificadores anidados. No exponga el endpoint de inferencia directamente: exija autenticación y aplique límites de tasa por cliente para que un único cliente no pueda monopolizar los workers.

Para la detección, vigile los workers de inferencia que dejan de responder o cuyo consumo de CPU se dispara durante una compilación, y controle los errores de tiempo límite de compilación una vez aplicada la corrección. Las herramientas de sistema habituales —top/htop para localizar un worker bloqueado, un rastreo del proceso sospechoso para ver si está atascado en la compilación de regex— revelarán un intento en curso.

Estado

Elemento	Detalle
Afectado	vLLM, todas las versiones anteriores a 0.24.0
Corregido en	vLLM 0.24.0 (PR #45118)
Debilidad	CWE-1333, complejidad ineficiente de expresiones regulares (ReDoS)
Impacto	Denegación de servicio — solo disponibilidad; sin autenticación, red, sin privilegios
Gravedad	CVSS 4.0 8.7 (alta, CNA) / CVSS 3.1 7.5 (alta, NVD); calificación del sitio: media
Referencia	CVE-2026-55574 (publicado el 2026-07-06); aviso GHSA-rwxx-mrjm-wc2m