Resumo Técnico: Descoberta Contínua de Vulnerabilidades em Sistemas de Serviço de LLM com Fuzzing

Declaração do Problema

Os sistemas de inferência e serviço de Modelos de Linguagem de Grande Escala (LLM) (por exemplo, vLLM, SGLang) tornaram-se infraestrutura crítica para aplicações de IA modernas. Esses sistemas empregam otimizações agressivas, como cache de KV, agrupamento dinâmico, compartilhamento de prefixos, decodificação especulativa e agendamento multi-inquilino para gerenciar as demandas de computação e memória de modelos grandes. No entanto, essa complexidade cria uma superfície de vulnerabilidade distinta e pouco testada dentro da camada de serviço.

Os testes de segurança atuais focam principalmente no comportamento do modelo (por exemplo, jailbreaks, alucinações) ou na conformidade individual de APIs. Essas abordagens falham em capturar falhas decorrentes da lógica de execução de software de solicitações de inferência válidas quando processadas sob cargas de trabalho concorrentes realistas. Uma análise empírica recente indica que mais de 35% dos bugs nesses sistemas se manifestam como anomalias sem travamento, em vez de travamentos diretos. Especificamente, falhas na pilha de serviço podem levar a:

• Corrupção silenciosa de estado: Contaminação cruzada entre solicitações, onde a saída de uma solicitação é corrompida pelo estado em cache de outra.
• Patologias de desempenho: Negação de serviço por "vizinho barulhento" onde solicitações válidas causam amplificação severa de latência ou colapso de vazão para inquilinos não relacionados, sem derrubar o servidor.
• Falhas de vivência atrasadas: Travamentos acionados apenas pela composição concorrente específica de solicitações válidas, violando invariantes do agendador.

Os métodos de teste existentes (avaliações em nível de modelo, testes de API padrão e fuzzers convencionais) não exercitam sistematicamente o tempo, a sobreposição e as interações de estado compartilhado que determinam se um sistema de serviço preserva o isolamento.

Metodologia: GRIEF

Para abordar essa lacuna, os autores apresentam o GRIEF (GReybox Inference Engine Fuzzer), um fuzzer de caixa cinza projetado especificamente para sistemas de inferência e serviço de LLM.

Abstração Central: Rastros de Solicitações com Tempo

Ao contrário dos fuzzers tradicionais que mutam strings de bytes ou prompts isolados, o GRIEF trata rastros de múltiplas solicitações com tempo como entradas de primeira classe. Um rastro é uma sequência de eventos do lado do cliente carimbados com data e hora que capturam:

• Conteúdo da Solicitação: O prompt e os parâmetros.
• Estrutura de Agendamento: Quando as solicitações se sobrepõem, como elas competem por estado compartilhado e seus eventos de ciclo de vida (ENVIO, CANCELAMENTO, DESCONECTAR, ESPERAR).
• Identidade Semântica: As solicitações são agrupadas por prompt_family_id para permitir que o GRIEF varie o tempo e a concorrência enquanto mantém o conteúdo do prompt fixo, isolando a divergência da camada de serviço do desvio do prompt.

Loop de Fuzzing e Mutações

O GRIEF opera um loop de caixa cinza que gera, muta e executa rastros contra servidores ativos, usando feedback em tempo de execução (latência, uso de recursos, eventos de cache de KV) para guiar a exploração. Ele emprega três classes de mutações em nível de rastro:

1. Mutações de Tempo: Perturbação de deslocamentos de eventos para alterar o agrupamento conjunto, sobreposição de pré-preenchimento ou tempo de evicção de cache.
2. Mutações de Eventos: Inserção, exclusão ou modificação de eventos de ciclo de vida para exercitar caminhos de limpeza, retry e desmontagem.
3. Mutações de Juntar: Combinação de segmentos de rastros pais, incluindo juntar direcionado que alinha fases de aquecimento de cache com janelas de alta pressão para expor condições de corrida.

Oráculo e Pipeline de Confirmação

Como o serviço de LLM é ruidoso e parcialmente não determinístico, o GRIEF utiliza um pipeline em etapas para distinguir bugs de ruído de infraestrutura:

1. Oráculos Comportamentais: Detectam anomalias externas (por exemplo, regressão severa de latência, saídas corrompidas, violações de ciclo de vida).
2. Confirmação Relacional Assistida por Logprob: Rastros suspeitos são reexecutados com decodificação determinística. O GRIEF compara as saídas original e reexecutada. Se elas divergirem, verifica a probabilidade logarítmica do primeiro token divergente. Se o token original não for um candidato quase empatado sob a distribuição de reexecução, confirma uma divergência da camada de serviço (por exemplo, estado de KV desatualizado) em vez de ambiguidade benigna de decodificação.
3. Forense Estrutural de KV: Para atribuição de alta confiança, o GRIEF observa eventos de ciclo de vida de blocos de cache de KV fora de banda para detectar anomalias estruturais como reutilização de blocos entre adaptadores ou conflitos de hash-conteúdo.

Contribuições Principais

1. Identificação de uma Nova Superfície de Ataque: O artigo identifica a inferência concorrente de LLM como uma fronteira relevante para segurança onde solicitações válidas podem acionar falhas de isolamento, desempenho e vivência.
2. Sistema GRIEF: O design e implementação de um fuzzer de caixa cinza que trata rastros de múltiplas solicitações com tempo como entradas, mutando o tempo das solicitações, eventos de ciclo de vida e parâmetros de modo de serviço.
3. Avaliação Empírica: A avaliação do GRIEF em vLLM e SGLang, descobrindo 15 vulnerabilidades potenciais, das quais 10 foram confirmadas pelos desenvolvedores do motor. Isso inclui 2 CVEs atribuídos (por exemplo, CVE-2026-7141) e solicitações adicionais pendentes.

Resultados e Descobertas

O estudo categoriza as falhas descobertas em três classes de impacto:

1. Corrupção de Estado e Falhas de Isolamento

O GRIEF descobriu bugs onde o isolamento do cache de KV quebra, permitindo contaminação de saída cruzada entre solicitações.

• Sintomas: "Poluição de valor confiante" (saída de um valor errado copiado de outra solicitação), "perturbação da cadeia de raciocínio" (loops infinitos ou Cadeia de Pensamento estendida) e "confusão de raciocínio com resposta primeiro" (gerar uma resposta antes do raciocínio).
• Mecanismo: Essas falhas ocorrem sem entradas malformadas. A solicitação gatilho perturba o estado de serviço, fazendo com que a saída da vítima seja determinada pela posição vulnerável do agendamento em vez do prompt da vítima sozinho.
• Verificação: A reexecução controlada confirmou que as saídas corrompidas eram bit-íntegras entre diferentes prompts gatilho, descartando injeção de prompt e confirmando problemas de reutilização de estado.

2. Patologias de Desempenho (DoS por Vizinho Barulhento)

O GRIEF identificou um bug no vLLM onde um único formato de solicitação válido na API causa interferência severa entre solicitações.

• Impacto: O tempo até o primeiro token (TTFT) da vítima aumentou em 1.361× (de ~12ms para ~18s), e a vazão útil colapsou para quase zero.
• Mecanismo: Diferente do bloqueio padrão de cabeça de fila, rastros eBPF revelaram que a coroutine compartilhada EngineCore foi repetidamente desprogramada pelo sistema operacional. Isso parou o caminho de acionamento do motor para todas as solicitações agendadas conjuntamente, efetivamente famintando inquilinos não relacionados enquanto o servidor permanecia vivo e livre de erros.

3. Falhas de Travamento e Vivência

O GRIEF encontrou cargas de trabalho que violam invariantes do agendador apenas quando solicitações válidas são compostas concorrentemente.

• Estudo de Caso: Um travamento no serviço LoRA do SGLang acionado por uma combinação específica de alta pressão de cache de KV, formatos de prompt mistos e chegadas de adaptadores em rajada.
• Mecanismo: A visão do agendador dos adaptadores ativos divergiu do conjunto carregado, criando um lote inválido que acionou um erro de afirmação. O travamento foi atrasado, ocorrendo após o pré-preenchimento normal e respostas bem-sucedidas, tornando-o difícil de diagnosticar sem o rastro completo.

Significado e Alegações

O artigo argumenta que concorrência, cache e comportamento do agendador devem ser tratados como fronteiras de segurança e confiabilidade de primeira classe para infraestrutura de LLM. As descobertas demonstram que:

• Testes de segurança de modelo padrão e verificações de conformidade de API são insuficientes para garantir a segurança de sistemas de serviço de LLM.
• Solicitações de API válidas e documentadas podem induzir corrupção silenciosa de saída, interferência entre solicitações e perda de disponibilidade sem erros explícitos do servidor.
• A própria "camada de serviço" é uma superfície de ataque crítica onde bugs podem se manifestar como anomalias sutis e sem travamento que são invisíveis para monitoramento tradicional.

Os autores concluem que a infraestrutura futura de LLM deve integrar o fuzzing da camada de serviço em processos rotineiros de teste e endurecimento para mitigar esses riscos antes que sejam encontrados em produção. O trabalho é apresentado como um alerta precoce e uma mudança metodológica em direção a tratar o motor de inferência como um componente crítico de segurança, e não meramente como um substrato de desempenho.