Infraestrutura de inferência AI é critical infrastructure. Quando 400.000 GPUs rodam software com três RCEs sem patch e o mantenedor ignora o CERT/CC, a responsabilidade recai sobre quem opera. Na Tech86, vimos essa dinâmica repetidas vezes: o fornecedor não corrige, o atacante não espera, e a conta chega para o dono do workload.
Quatro RCEs, três sem correção
O SGLang é o servidor de inferência por trás de workloads de xAI, NVIDIA, AMD, LinkedIn, Cursor, Oracle, Google Cloud, Azure e AWS. Em janeiro de 2026, o projeto spinou como RadixArk com backing da Accel e valuation de aproximadamente 400 milhões de dólares. O software que roda nessas 400.000 GPUs tem quatro vulnerabilidades de execução remota de código. Apenas uma foi corrigida.
A CVE-2026-5760 (CVSS 9.8) explora arquivos GGUF com payload Jinja2 no chat_template. A vítima carrega o modelo, faz um request para /v1/rerank, e o payload executa. Sem autenticação. Essa é a única corrigida — patch na versão 0.5.11.
A CVE-2026-7301 (CVSS 9.8) ataca o scheduler ZeroMQ. O runtime multimodal binda um socket ROUTER. O código default usa 127.0.0.1, mas a documentação oficial recomenda --host 0.0.0.0 em todos os exemplos. O Docker Compose oficial usa network_mode: host. Em toda deployment que seguiu o guia, o socket está exposto. O scheduler chama pickle.loads() em cada mensagem. Um pickle craftado equivale a RCE. O mesmo padrão foi corrigido em março no CVE-2026-3059, mas em outro code path. Este é diferente. Sem patch.
A CVE-2026-7302 (CVSS 9.1) permite escrita arbitrária de arquivos. Os endpoints /v1/images/edits e /v1/videos aceitam upload sem sanitizar ../ no filename. Um atacante consegue escrever em qualquer path do processo. Sem patch.
A CVE-2026-7304 (CVSS 9.8) usa o campo custom_logit_processor que aceita JSON com callable contendo payload dill hex-encoded. O servidor deserializa com dill.loads() sem validação. Dill é superset de pickle — mesma propriedade de execução arbitrária. Requer --enable-custom-logit-processor ativo. Sem patch.
A cronologia que deveria preocupar todo mundo
A Antiproof reportou as vulnerabilidades ao mantenedor em 10 de março. No dia 25 de março, um PR parcial foi aberto — cobre apenas a CVE-2026-5760. As outras três ficaram de fora. Em 15 de maio, o CERT/CC publicou o VU#777338 porque o mantenedor não respondeu. Em 26 de maio, o JPCERT/CC emitiu advisory independente.
Mais de dois meses desde o disclosure. Três CVEs com CVSS 9.8. Zero patch. Uma empresa avaliada em 400 milhões de dólares que não responde ao CERT/CC. Isso não é um esquecimento — é um padrão.
Na Tech86, aprendemos que o tempo entre disclosure e exploit efetivo encurtou drasticamente. Quando o CERT/CC publica, o adversário já sabe. Cada dia sem mitigação é um dia de janela aberta.
Desserialização é o buraco que não fecha
O padrão é recorrente e bem documentado: pickle.loads() em dados não confiáveis é RCE por definição. Não é uma vulnerabilidade zero-day — é uma propriedade do formato. O Python documenta isso explicitamente. A correção de março (CVE-2026-3059) deveria ter triggers de auditoria em todos os code paths com desserialização. Não teve.
O SGLang usa pickle.loads() no scheduler ZeroMQ e dill.loads() no custom logit processor. Dois code paths distintos, mesma classe de vulnerabilidade, mesma raiz: desserialização de dados não confiáveis sem validação. Um inference server sem autenticação está a um pickle craftado de distância de ter o host comprometido.
E o host de inferência não é um host qualquer. Tem acesso a modelos proprietários, dados de treinamento, credenciais cloud e GPU compute. O comprometimento de um inference server não é um incidente de segurança — é um incidente de infraestrutura crítica.
A documentação que expõe todo mundo
O problema não é só o código. É o guia. A documentação oficial do SGLang recomenda --host 0.0.0.0 em todos os exemplos de deployment. O Docker Compose oficial configura network_mode: host. Isso significa que toda equipe que seguiu o guia — e a maioria segue — expôs o socket ZeroMQ do scheduler na rede.
O código default é 127.0.0.1. Seguro. Mas o guia diz para mudar. E quando o guia oficial diz para abrir, a equipe abre. Não é negligência — é confiança na documentação do projeto. Confiar na documentação de um projeto open source não é imprudência. É o fluxo normal de operação. O problema é quando a documentação ensina a configurar inseguramente e o projeto não corrige as consequências.
Mitigações que você precisa aplicar hoje
O patch não vem. As mitigações são workarounds, não correções de raiz. Mas são o que existe. Para a CVE-2026-7301, restrinja --host a 127.0.0.1 e adicione firewall nos ports ZeroMQ. Para a CVE-2026-7302, bloqueie /v1/images/edits e /v1/videos no proxy reverso. Para a CVE-2026-7304, desabilite --enable-custom-logit-processor. Se não precisa de multimodal, desabilite. Se não usa rerank, bloqueie o endpoint.
Reduza a superfície. Cada endpoint ativo é um vetor. Cada flag habilitado é uma porta. O princípio é o mesmo que aplicamos em qualquer infraestrutura crítica: se não é necessário, não fica exposto.
A responsabilidade é sua
AI inference infrastructure é critical infrastructure. Não é um servidor de teste, não é um protótipo, não é um side project. É o software que processa dados sensíveis em hardware que custa centenas de milhares de dólares por cluster. E quando o mantenedor não responde ao CERT/CC por dois meses, a responsabilidade de proteger não desaparece — transfere.
Na Tech86, operamos infraestrutura cloud com a premissa de que a segurança não depende do fornecedor upstream. Se o patch não existe, a mitigação precisa existir. Se a documentação ensina errado, a configuração precisa corrigir. É por isso que nossos Cloud Servers são provisionados com isolamento de rede por padrão, firewall configurado antes do primeiro deploy, e superfície de ataque reduzida ao mínimo funcional. Quando o fornecedor falha, a infraestrutura precisa aguentar.