La capa de servicio es la superficie de ataque: fallos de concurrencia en vLLM y SGLang

En resumen La mayoría de las pruebas de seguridad de LLM apuntan al modelo: jailbreaks, inyección de prompts, alucinación. Pero un cuerpo creciente de trabajos sostiene que el framework de servicio —el motor que agrupa peticiones en lotes, comparte una caché KV entre inquilinos y planifica el tiempo de GPU— es su propia frontera de seguridad, y más permeable. Un artículo publicado en mayo de 2026, Continuous Discovery of Vulnerabilities in LLM Serving Systems with Fuzzing (arXiv 2605.11202), presenta GRIEF, un fuzzer greybox que muta trazas de peticiones concurrentes con marca temporal. En campañas iniciales de 8 horas contra vLLM y SGLang reveló 15 vulnerabilidades, 10 confirmadas por los mantenedores, incluidas 2 CVE asignadas, todas disparadas por peticiones perfectamente válidas que solo se vuelven peligrosas cuando se solapan.

¿Qué es esto?

Un motor de inferencia moderno como vLLM o SGLang no es una capa fina sobre un modelo. Para alcanzar sus objetivos de uso de GPU ejecuta batching continuo, una caché KV paginada compartida, compartición de prefijos, decodificación especulativa, multiplexado de adaptadores LoRA y un planificador multiinquilino. Todo ello crea estado mutable compartido entre peticiones de usuarios distintos. Las pruebas estándar nunca lo ejercitan: las evaluaciones de seguridad del modelo comprueban si una respuesta aislada es segura, las pruebas de API si una petición aislada se gestiona correctamente, y los fuzzers clásicos buscan caídas por bytes malformados. Ninguno examina qué ocurre cuando decenas de peticiones individualmente válidas compiten por la misma caché y el mismo planificador bajo concurrencia realista.

GRIEF (arXiv 2605.11202) es el primer intento sistemático de hacer fuzzing de esa superficie. Su modelo de amenaza es deliberadamente débil: un cliente de API sin privilegios que envía peticiones bien formadas por endpoints documentados, sin tráfico malformado, sin acceso privilegiado y sin colocalización de host. El resultado es la primera evidencia empírica de que la pila de servicio es «una superficie de vulnerabilidad distinta e infraprobada».

Cómo funciona

La idea clave está en la abstracción de entrada. En lugar de mutar una cadena de bytes o un prompt aislado, GRIEF trata una traza de peticiones con marca temporal como unidad de fuzzing: una secuencia de eventos de cliente que captura cuándo se solapan las peticiones, qué forma llevan y qué peticiones deben compartir una identidad de prompt semántica. El fuzzer muta el co-batching, la reutilización de caché de prefijos, el co-planificado de adaptadores, el momento de cancelación y la presión sobre el planificador, y luego usa oráculos ligeros —anomalías de latencia, telemetría de la caché KV, comparación de salidas entre ejecuciones— para señalar ejecuciones sospechosas. Como el servicio de LLM es ruidoso y no determinista, todo caso sospechoso pasa por una etapa de reproducción controlada con voto mayoritario y verificación de log-probabilidades de tokens, separando los fallos reales del jitter de planificación.

Los hallazgos se agrupan en tres clases de impacto (Tabla 1 del artículo):

Clase de fallo               Total  vLLM  SGLang  Confirmados  Impacto representativo
Corrupción de estado/aislam.    7     5      2        7         Contaminación de salida entre peticiones
Patología de rendimiento        4     2      2        2         Denegación de servicio «vecino ruidoso»
Caída / vivacidad               2     1      1        1         Pérdida de disponibilidad (proceso)

En la clase de aislamiento, una carga concurrente hizo que una petición reutilizara estado de caché KV obsoleto de otra petición, contaminando la salida de la víctima: una ruptura de aislamiento sin caída ni error en los registros. En la clase de rendimiento, una petición válida pero moldeada por el atacante externalizó su coste sobre los usuarios co-planificados, elevando la latencia del primer token y reduciendo el rendimiento útil a casi cero. En la clase de vivacidad, un lote de peticiones válidas con adaptador LoRA violó un invariante del planificador y abortó el proceso de servicio; como la caída se diferió respecto al disparador, los registros mostraban un prefill normal y respuestas correctas hasta el fallo.

Esa clase de patología de rendimiento es precisamente lo que otro artículo de febrero de 2026, Rethinking Latency Denial-of-Service: Attacking the LLM Serving Framework, Not the Model (arXiv 2602.07878), formaliza como la estrategia «Fill and Squeeze»: Fill agota la caché KV global para inducir bloqueo de cabeza de cola, Squeeze fuerza al planificador a preempciones repetidas. Los autores reportan hasta 20–280× de ralentización en el tiempo hasta el primer token con un coste de ataque un 30–40 % menor que ataques de ralentización previos a nivel de modelo, atacando el estado del planificador FCFS, no el modelo.

Por qué importa

Dos propiedades empeoran el cuadro. Primero, ninguno de estos fallos requiere una entrada malformada ni un error explícito: son silenciosos. Un inquilino cuya salida fue contaminada por el estado de caché KV de otro usuario no recibe señal alguna de que algo salió mal; un operador que vigila paneles «solo caídas» ve un servidor sano. El trabajo empírico citado por los autores de GRIEF estima que más del 35 % de los fallos de motores de inferencia se manifiestan como anomalías sin caída. Segundo, la barrera para el atacante es baja: un usuario de API de pago corriente en un endpoint multiinquilino compartido puede, ajustando el ritmo de sus peticiones, degradar o contaminar a otros inquilinos. Para quien opera una flota vLLM o SGLang compartida —equipos de plataforma internos, proveedores de inferencia bajo demanda— esto es un problema de confidencialidad y disponibilidad entre inquilinos, no una nota al pie sobre la calidad del modelo. Encaja directamente con Unbounded Consumption del OWASP LLM Top 10 y con los requisitos clásicos de aislamiento de inquilinos.

Defensas

Actuar no exige ningún payload; las mitigaciones son arquitectónicas.

• Probar la concurrencia, no solo las peticiones. Añada fuzzing de la capa de servicio o reproducción de trazas concurrentes (el enfoque de GRIEF) a la CI de cualquier motor autoalojado. Las pruebas de corrección por petición no detectarán estos fallos.
• Imponer el aislamiento de inquilinos en la caché. Particione o clavije la caché KV y los pools de compartición de prefijos por inquilino para que la reutilización entre peticiones no cruce una frontera de confianza; desactive la compartición de prefijos entre inquilinos donde importe la confidencialidad.
• Hacer el planificador justo y acotado. Sustituya el FCFS ingenuo por planificación de cuota justa o por prioridad, limite la ocupación de la caché KV y los tokens en vuelo por inquilino, y aplique control de admisión para que ningún cliente pueda monopolizar la memoria de GPU. Los trabajos recientes de planificación (p. ej. mitigación del bloqueo de cabeza de cola) apuntan directamente al patrón «Fill and Squeeze».
• Cuotas y límites de tasa como suelo financiero. Los límites de tasa (de tokens y de peticiones) por inquilino son la primera defensa contra los efectos de «vecino ruidoso» y de denegación de cartera.
• Observar las señales correctas. Una monitorización «solo caídas» es ciega aquí. Siga las distribuciones de TTFT/TPOT por inquilino, la telemetría de aciertos/desalojos de la caché KV y el número de preempciones; trate una divergencia de latencia entre inquilinos sostenida como un evento de seguridad.
• Parchear con prontitud. Las dos CVE de GRIEF fueron confirmadas por los mantenedores de vLLM/SGLang: mantenga los motores actualizados y vigile sus avisos.

Estado

GRIEF se publicó en mayo de 2026 (arXiv 2605.11202); reporta 15 hallazgos, 10 confirmados por desarrolladores y 2 con CVE asignadas, con más solicitudes de CVE pendientes, sobre vLLM y SGLang probados con Qwen-2.5-0.5B-Instruct. El análisis complementario de denegación de servicio por latencia (arXiv 2602.07878) es de febrero de 2026. Los autores de GRIEF siguieron una divulgación responsable y retienen deliberadamente un inventario completo de exploits; este artículo describe igualmente las clases de fallo y sus defensas, no los pasos de reproducción. La lección de fondo es duradera al margen de cualquier parche: para LLM autoalojados, la lógica de concurrencia, caché y planificación del motor de inferencia es una frontera de seguridad de primer orden que necesita sus propias pruebas.