CVE-2025-62164 PoC: bug no plano de dados de conclusões do vLLM que transforma os embeddings em uma superfície de ataque

Resumo executivo

À medida que a infraestrutura do Modelo de Linguagem Grande (LLM) amadurece, a superfície de ataque está mudando das interfaces de gerenciamento tradicionais ("Plano de Controle") para o fluxo real de dados de inferência ("Plano de Dados").

CVE-2025-62164 representa uma vulnerabilidade de mudança de paradigma em vLLMo mecanismo padrão do setor para o fornecimento de LLM de alto rendimento. Essa falha permite que os invasores utilizem como arma o /v1/completions injetando um incorporação imediata. Ao explorar mecanismos de desserialização inseguros dentro da lógica de carregamento do PyTorch, um invasor pode acionar a corrupção de memória, levando à negação de serviço (DoS) e à possível execução remota de código (RCE), tudo sem precisar de chaves de API válidas (dependendo da configuração da implantação).

Essa análise detalha a causa raiz técnica, fornece uma Prova de Conceito (PoC) conceitual e descreve as etapas imediatas de correção para os engenheiros da plataforma de IA.

O vetor de ataque: Por que os Embeddings são perigosos

Nas interações padrão do LLM, os usuários enviam texto. No entanto, mecanismos de inferência avançados, como o vLLM, suportam entradas de incorporação (dados de tensor) diretamente por meio da API. Isso foi projetado para otimização de desempenho e fluxos de trabalho multimodais, mas abre uma porta perigosa: Desserialização direta de objetos.

A vulnerabilidade reside na forma como o vLLM processa esses tensores de entrada. Especificamente, o mecanismo confia implicitamente na estrutura dos dados serializados fornecidos pelo usuário, assumindo que se trata de uma representação matemática inofensiva.

O caminho do código vulnerável

A falha crítica existe em vllm/entrypoints/renderer.py dentro do _load_and_validate_embed função.

Python

# Representação simplificada da lógica vulnerável
importar torch
importar io
importar pybase64

def _load_and_validate_embed(embed: bytes):
    # PERIGO: desserialização de fluxos binários não confiáveis
    tensor = torch.load(
        io.BytesIO(pybase64.b64decode(embed, validate=True)),
        weights_only=True, # A falsa sensação de segurança
        map_location=torch.device("cpu"),
    )
    retornar tensor

Enquanto weights_only=True tem como objetivo impedir a execução de código Python arbitrário (uma vulnerabilidade comum do Pickle), ele é insuficiente para evitar corrupção de memória ao lidar com tipos específicos de tensores do PyTorch.

Mergulho técnico profundo: Explorando tensores esparsos

O núcleo do CVE-2025-62164 aproveita uma desconexão entre os sinalizadores de segurança do PyTorch e sua manipulação de Tensores esparsos.

1. O PyTorch 2.8+ Shift: As versões mais recentes do PyTorch ignoram por padrão as verificações de integridade caras para tensores esparsos para melhorar o desempenho.
2. O Bypass: Um invasor pode construir um tensor "Sparse COO" (formato de coordenadas) malformado. Mesmo com weights_only=True, torch.load deserializará essa estrutura.
3. Corrupção de memória: Como os índices do tensor esparso não são validados em relação ao tamanho declarado durante o carregamento, as operações subsequentes (como converter o tensor em formato denso ou movê-lo para a memória da GPU) resultam em um erro de Gravação fora dos limites (OOB).

Essa gravação OOB bloqueia o interpretador Python imediatamente (DoS). Com a sofisticada pulverização do heap e a manipulação do layout da memória, essa primitiva pode ser escalada para obter o controle do ponteiro de instruções, alcançando o RCE.

Análise de prova de conceito (PoC)

Isenção de responsabilidade: este PoC é apenas para fins educacionais e defensivos.

1. Construção da carga útil

O invasor cria um tensor PyTorch serializado que viola as restrições de consistência interna.

Python

importar torch
importar io
importar base64

def generate_exploit_payload():
    buffer = io.BytesIO()
    
    # Criar um tensor esparso projetado para acionar a gravação OOB no acesso
    # Os índices específicos seriam criados para apontar para fora da memória alocada
    # malformed_tensor = torch.sparse_coo_tensor(indices=..., values=..., size=...)
    
    # Para demonstração, simulamos a serialização
    # Em um ataque real, esse buffer contém o fluxo de pickle binário
    torch.save(malformed_tensor, buffer)
    
    # Codificar para transporte JSON
    return base64.b64encode(buffer.getvalue()).decode('utf-8')

2. A solicitação de exploração

O invasor envia esse payload para o endpoint de conclusão padrão.

POST http://target-vllm-instance:8000/v1/completions

JSON

{
  "model": "meta-llama/Llama-2-7b-hf",
  "prompt": {
    "embedding": ""
  },
  "max_tokens": 10
}

3. O resultado

• Melhor caso: O processo de trabalho do vLLM encontra uma falha de segmentação e falha. Se o orquestrador (por exemplo, Kubernetes) o reiniciar, o invasor poderá simplesmente reenviar a solicitação, criando uma negação de serviço persistente.
• Pior caso: A corrupção da memória sobrescreve os ponteiros de função, permitindo que o invasor execute o shellcode no contexto do contêiner.

Avaliação de impacto

• Disponibilidade (alta): Esse é um DoS trivial de executar. Uma única solicitação pode derrubar um nó de inferência. Em ambientes de cluster, um invasor pode iterar pelos nós para degradar todo o cluster.
• Confidencialidade e integridade (crítico): Se o RCE for obtido, o invasor obtém acesso às variáveis de ambiente (geralmente contendo tokens Hugging Face, chaves S3 ou chaves WandB) e os pesos do modelo proprietário carregados na memória.

Remediação e mitigação

1. Faça o upgrade imediatamente

A vulnerabilidade é corrigida em vLLM v0.11.1.

• Ação: Atualize suas imagens do Docker ou pacotes do PyPI para a versão mais recente imediatamente.
• Fixar a lógica: O patch implementa uma lógica de validação rigorosa que rejeita formatos de tensor inseguros antes que eles interajam com o alocador de memória.

2. Sanitização de entrada (nível WAF/Gateway)

Se não for possível fazer o upgrade imediatamente, você deverá bloquear o vetor de ataque no gateway.

• Ação: Configure seu API Gateway (Nginx, Kong, Traefik) para inspecionar os corpos JSON de entrada.
• Regra: Bloquear qualquer solicitação para /v1/completions onde o imediato contém um objeto com um incorporação chave.

3. Segmentação de rede

Certifique-se de que seu servidor de inferência não esteja exposto diretamente à Internet pública. O acesso deve ser mediado por um serviço de back-end que higienize as entradas e lide com a autenticação.

Conclusão

O CVE-2025-62164 serve como um alerta para a segurança de IA. Não podemos mais tratar "Modelos" e "Embeddings" como dados inertes. Na era da IA, dados são códigose desserializá-lo requer o mesmo nível de análise que a execução de um executável binário.

Para equipes que executam testes de penetração na infraestrutura de IA (como Penligent.ai), a verificação dos pontos de extremidade de serialização expostos nos mecanismos de inferência agora deve ser uma parte padrão do escopo do compromisso.

Nota do autor: mantenha sua infraestrutura de IA segura. Sempre valide as entradas, nunca confie em dados serializados e mantenha suas versões do vLLM fixadas na última versão estável.