Resumen Técnico: Descubrimiento Continuo de Vulnerabilidades en Sistemas de Servicio de LLM Mediante Fuzzing

Declaración del Problema

Los sistemas de inferencia y servicio de Modelos de Lenguaje Grande (LLM) (por ejemplo, vLLM, SGLang) se han convertido en infraestructura crítica para las aplicaciones de IA modernas. Estos sistemas emplean optimizaciones agresivas como el almacenamiento en caché de KV, el agrupamiento dinámico, el intercambio de prefijos, la decodificación especulativa y la programación multiinquilino para gestionar las demandas de computación y memoria de los modelos grandes. Sin embargo, esta complejidad crea una superficie de vulnerabilidad distinta y poco probada dentro de la capa de servicio.

Las pruebas de seguridad actuales se centran principalmente en el comportamiento del modelo (por ejemplo, escapes de la jaula, alucinaciones) o en el cumplimiento individual de la API. Estos enfoques no logran capturar fallos que surgen de la lógica de ejecución del software de solicitudes de inferencia válidas cuando se procesan bajo cargas de trabajo concurrentes realistas. Un análisis empírico reciente indica que más del 35% de los errores en estos sistemas se manifiestan como anomalías sin caída del sistema en lugar de fallos catastróficos. Específicamente, los fallos en la pila de servicio pueden dar lugar a:

• Corrupción silenciosa del estado: Contaminación cruzada de solicitudes donde la salida de una solicitud se corrompe por el estado en caché de otra.
• Patologías de rendimiento: Denegación de servicio por "vecino ruidoso" donde solicitudes válidas causan una amplificación severa de la latencia o un colapso del rendimiento para inquilinos no relacionados sin que el servidor se caiga.
• Fallos de disponibilidad diferidos: Caídas desencadenadas únicamente por la composición concurrente específica de solicitudes válidas, violando invariantes del planificador.

Los métodos de prueba existentes (evaluaciones a nivel de modelo, pruebas de API estándar y fuzers convencionales) no ejercitan sistemáticamente la temporización, la superposición y las interacciones de estado compartido que determinan si un sistema de servicio preserva el aislamiento.

Metodología: GRIEF

Para abordar esta brecha, los autores presentan GRIEF (Fuzzer de Motor de Inferencia de Caja Gris), un fuzzer de caja gris diseñado específicamente para sistemas de inferencia y servicio de LLM.

Abstracción Central: Rastros de Solicitudes Temporizadas

A diferencia de los fuzers tradicionales que mutan cadenas de bytes o indicaciones aisladas, GRIEF trata los rastros de múltiples solicitudes temporizadas como entradas de primera clase. Un rastro es una secuencia de eventos del lado del cliente con marca de tiempo que captura:

• Contenido de la solicitud: El prompt y los parámetros.
• Estructura de programación: Cuándo se superponen las solicitudes, cómo compiten por el estado compartido y sus eventos de ciclo de vida (ENVIAR, CANCELAR, DESCONECTAR, ESPERAR).
• Identidad semántica: Las solicitudes se agrupan por prompt_family_id para permitir que GRIEF varíe la temporización y la concurrencia manteniendo fijo el contenido del prompt, aislando la divergencia de la capa de servicio de la deriva del prompt.

Bucle de Fuzzing y Mutaciones

GRIEF opera un bucle de caja gris que genera, muta y ejecuta rastros contra servidores en vivo, utilizando retroalimentación en tiempo de ejecución (latencia, uso de recursos, eventos de caché de KV) para guiar la exploración. Emplea tres clases de mutaciones a nivel de rastro:

1. Mutaciones de temporización: Perturbar los desplazamientos de eventos para cambiar el agrupamiento conjunto, la superposición de prellenado o la temporización de la expulsión de la caché.
2. Mutaciones de eventos: Insertar, eliminar o modificar eventos de ciclo de vida para ejercitar rutas de limpieza, reintento y desmontaje.
3. Mutaciones de empalme: Combinar segmentos de rastros padres, incluido el empalme dirigido que alinea las fases de calentamiento de la caché con ventanas de alta presión para exponer condiciones de carrera.

Oráculo y Pipeline de Confirmación

Dado que el servicio de LLM es ruidoso y parcialmente no determinista, GRIEF utiliza un pipeline por etapas para distinguir errores del ruido de infraestructura:

1. Oráculos de comportamiento: Detectan anomalías externas (por ejemplo, regresión severa de latencia, salidas corruptas, violaciones de ciclo de vida).
2. Confirmación relacional asistida por logprob: Los rastros sospechosos se reproducen con decodificación determinista. GRIEF compara las salidas originales y reproducidas. Si divergen, verifica la probabilidad logarítmica del primer token divergente. Si el token original no es un candidato casi empatado bajo la distribución de reproducción, confirma una divergencia de la capa de servicio (por ejemplo, estado KV obsoleto) en lugar de una ambigüedad de decodificación benigna.
3. Forense estructural de KV: Para una atribución de alta confianza, GRIEF observa eventos de ciclo de vida de bloques de caché de KV fuera de banda para detectar anomalías estructurales como reutilización de bloques entre adaptadores o conflictos de contenido-hash.

Contribuciones Clave

1. Identificación de una nueva superficie de ataque: El artículo identifica el servicio de inferencia concurrente de LLM como un límite relevante para la seguridad donde las solicitudes válidas pueden desencadenar fallos de aislamiento, rendimiento y disponibilidad.
2. Sistema GRIEF: El diseño e implementación de un fuzzer de caja gris que trata los rastros de múltiples solicitudes temporizadas como entradas, mutando la temporización de las solicitudes, los eventos de ciclo de vida y los parámetros del modo de servicio.
3. Evaluación empírica: La evaluación de GRIEF en vLLM y SGLang, descubriendo 15 vulnerabilidades potenciales, 10 de las cuales fueron confirmadas por desarrolladores del motor. Esto incluye 2 CVE asignados (por ejemplo, CVE-2026-7141) y solicitudes adicionales pendientes.

Resultados y Hallazgos

El estudio clasifica los fallos descubiertos en tres clases de impacto:

1. Corrupción de Estado y Fallos de Aislamiento

GRIEF descubrió errores donde el aislamiento de la caché de KV se rompe, permitiendo la contaminación cruzada de salidas entre solicitudes.

• Síntomas: "Contaminación de valores confiables" (emitir un valor incorrecto copiado de otra solicitud), "perturbación de la cadena de razonamiento" (bucles infinitos o Cadenas de Pensamiento extendidas) y "confusión de razonamiento con respuesta primero" (generar una respuesta antes de razonar).
• Mecanismo: Estos fallos ocurren sin entradas malformadas. La solicitud desencadenante perturba el estado de servicio, haciendo que la salida de la víctima esté determinada por la posición vulnerable del planificador en lugar de solo por el prompt de la víctima.
• Verificación: La reproducción controlada confirmó que las salidas corruptas eran idénticas a nivel de bit a través de diferentes prompts desencadenantes, descartando la inyección de prompts y confirmando problemas de reutilización de estado.

2. Patologías de Rendimiento (DoS por Vecino Ruidoso)

GRIEF identificó un error en vLLM donde una sola forma de solicitud válida de API causa una interferencia severa entre solicitudes.

• Impacto: El tiempo hasta el primer token (TTFT) de la víctima aumentó en 1.361 veces (de ~12 ms a ~18 s), y el rendimiento útil colapsó a casi cero.
• Mecanismo: A diferencia del bloqueo estándar de cabeza de línea, los rastros eBPF revelaron que el coroutine compartido EngineCore fue desprogramado repetidamente por el sistema operativo. Esto detuvo la ruta de conducción del motor para todas las solicitudes programadas conjuntamente, dejando efectivamente sin recursos a inquilinos no relacionados mientras el servidor permanecía vivo y libre de errores.

3. Fallos de Caída y Disponibilidad

GRIEF encontró cargas de trabajo que violan invariantes del planificador solo cuando las solicitudes válidas se componen concurrentemente.

• Estudio de caso: Un fallo en el servicio LoRA de SGLang desencadenado por una combinación específica de alta presión de caché de KV, formas de prompts mixtas y llegadas de adaptadores explosivas.
• Mecanismo: La visión del planificador de los adaptadores activos se desviaba del conjunto cargado, creando un lote inválido que desencadenó un error de aserción. El fallo fue diferido, ocurriendo después del prellenado normal y respuestas exitosas, lo que dificultó el diagnóstico sin el rastro completo.

Significado y Afirmaciones

El artículo argumenta que la concurrencia, el almacenamiento en caché y el comportamiento del planificador deben tratarse como límites de seguridad y fiabilidad de primera clase para la infraestructura de LLM. Los hallazgos demuestran que:

• Las pruebas de seguridad estándar de modelos y las verificaciones de cumplimiento de API son insuficientes para asegurar los sistemas de servicio de LLM.
• Las solicitudes válidas y documentadas de API pueden inducir corrupción silenciosa de salidas, interferencia entre solicitudes y pérdida de disponibilidad sin errores explícitos del servidor.
• La propia "capa de servicio" es una superficie de ataque crítica donde los errores pueden manifestarse como anomalías sutiles y sin caída del sistema que son invisibles para el monitoreo tradicional.

Los autores concluyen que la infraestructura futura de LLM debe integrar el fuzzing de la capa de servicio en los procesos rutinarios de prueba y endurecimiento para mitigar estos riesgos antes de que se encuentren en producción. El trabajo se presenta como una advertencia temprana y un cambio metodológico hacia tratar el motor de inferencia como un componente crítico para la seguridad, no meramente como un sustrato de rendimiento.