Falha crítica no SGLang permite execução remota de código por modelos `GGUF` maliciosos

CVE-2026-5760 afeta o endpoint /v1/rerank e pode executar código Python no contexto do serviço quando um modelo GGUF manipulado é carregado e processado.

Componente	SGLang, especificamente o processamento de tokenizer.chat_template em modelos GGUF durante requisições ao endpoint /v1/rerank.
Vetor	Carregamento de um arquivo de modelo GGUF especialmente criado, contendo um template Jinja2 malicioso e uma frase de gatilho associada ao caminho de reranking.
Impacto	Execução arbitrária de código Python no servidor de inferência, no contexto do processo do serviço SGLang.
Prioridade	Restringir a origem de modelos carregados, revisar o uso de templates Jinja2 e substituir jinja2.Environment() por ImmutableSandboxedEnvironment no caminho afetado.
Artefatos	CVE-2026-5760, CVSS 9.8, GGUF, tokenizer.chat_template, Jinja2, SSTI, /v1/rerank, entrypoints/openai/serving_rerank.py.
Mitigação	Aplicar sandboxing na renderização de templates, impedir carregamento automático de modelos não verificados e monitorar uso anômalo do endpoint de reranking.

Resumo técnico

A vulnerabilidade CVE-2026-5760 expõe servidores SGLang a execução remota de código quando um modelo GGUF malicioso é carregado e posteriormente usado em uma requisição ao endpoint /v1/rerank. O problema recebeu pontuação CVSS 9.8, refletindo um impacto crítico em ambientes nos quais o serviço de inferência aceita modelos obtidos de fontes externas, repositórios públicos ou fluxos internos sem validação suficiente. O ponto central não é apenas o arquivo de modelo em si, mas a forma como o SGLang interpreta o campo tokenizer.chat_template durante o caminho de reranking.

O SGLang é um framework aberto de alta performance para servir modelos de linguagem de grande porte e modelos multimodais. Em arquiteturas de IA, esse tipo de componente normalmente fica entre aplicações consumidoras, APIs compatíveis com OpenAI, pipelines de inferência e infraestrutura acelerada por GPU. Por isso, a execução de código dentro do processo do serviço não deve ser tratada como uma falha isolada de aplicação: ela pode afetar o host de inferência, credenciais disponíveis no ambiente, tokens de acesso a repositórios de modelos, configurações de cloud, diretórios montados e integrações internas usadas pelo runtime.

A falha está associada a uma classe conhecida de problemas em templates Jinja2 renderizados sem isolamento adequado. O contexto descreve o uso de jinja2.Environment() sem sandboxing, em vez de ImmutableSandboxedEnvironment, permitindo que um template controlado pelo arquivo do modelo alcance execução de código Python. A exploração depende de uma sequência específica: o operador do ambiente baixa ou carrega o modelo manipulado, o SGLang passa a ter acesso ao chat_template, e uma requisição ao endpoint vulnerável ativa o caminho que renderiza o template.

A gravidade prática aumenta em organizações que tratam modelos como artefatos confiáveis por padrão. Em projetos de IA, é comum que arquivos de modelo circulem por experimentação, avaliação de qualidade, fine-tuning, benchmarking e implantação rápida. Quando esse processo não impõe verificação de procedência e análise do conteúdo serializado ou dos metadados do modelo, um artefato aparentemente legítimo pode se tornar o ponto de entrada para execução no servidor que hospeda a inferência.

Fluxo técnico

O fluxo descrito começa com a criação de um arquivo GGUF manipulado. Dentro desse arquivo, o campo tokenizer.chat_template contém um template Jinja2 com carga de SSTI. O contexto também indica que o template inclui uma frase de gatilho relacionada ao reranker Qwen3, usada para alcançar o caminho vulnerável em entrypoints/openai/serving_rerank.py. Esse detalhe é importante porque a falha não se resume ao ato de armazenar um template perigoso no modelo; ela depende da renderização desse template no momento em que a funcionalidade de reranking é acionada.

Depois que a vítima baixa e carrega o modelo no SGLang, o servidor passa a processar seus metadados como parte do funcionamento normal do serviço. Quando uma requisição atinge /v1/rerank, o SGLang lê o chat_template e o renderiza com jinja2.Environment(). Sem uma sandbox imutável, a renderização deixa de ser apenas uma transformação de texto e passa a expor primitivas que podem ser encadeadas para executar código Python no processo do servidor. O impacto confirmado no contexto é execução arbitrária de código, não apenas negação de serviço ou alteração de resposta.

A pré-condição mais relevante é a aceitação de um modelo GGUF controlado por terceiro ou não verificado. O contexto menciona fontes como Hugging Face como exemplo de origem de onde um modelo poderia ser baixado, mas a superfície não se limita a um único repositório. Qualquer fluxo que importe modelos para SGLang, inclusive caches internos, espelhos corporativos, pipelines de avaliação e ambientes de laboratório, pode ficar exposto se o arquivo manipulado chegar ao serviço vulnerável e se o endpoint de reranking for acionado.

O problema se aproxima de vulnerabilidades anteriores observadas em bibliotecas e runtimes de modelos que renderizam chat_template com Jinja2 de maneira permissiva. O contexto relaciona a classe da falha a CVE-2024-34359, conhecida como Llama Drama, e também a uma superfície corrigida no vLLM identificada como CVE-2025-61620. Essa recorrência mostra que arquivos de modelo devem ser avaliados como artefatos executáveis em potencial quando contêm templates, metadados interpretáveis ou campos processados dinamicamente pelo runtime.

Superfície afetada

A superfície afetada envolve servidores SGLang que carregam modelos GGUF e expõem ou utilizam o endpoint /v1/rerank. A falha não exige, pelo material analisado, que o atacante tenha acesso direto ao sistema operacional do host; o caminho depende de influenciar o artefato de modelo que será consumido pelo serviço e de provocar ou aguardar uma requisição que acione o reranking. Em ambientes multiusuário, laboratórios de IA, plataformas internas de avaliação e serviços de inferência compartilhados, esse padrão cria risco quando usuários ou pipelines têm permissão para registrar novos modelos.

O ativo mais sensível é o processo do SGLang em execução. Se o serviço roda com permissões amplas, variáveis de ambiente ricas em credenciais, acesso a diretórios de trabalho persistentes ou conectividade para serviços internos, o raio de impacto aumenta. O contexto sustenta execução de código Python no servidor de inferência; portanto, a análise defensiva deve partir desse limite confirmado e avaliar quais permissões e segredos estavam disponíveis para o processo vulnerável no momento da exposição.

Também há risco operacional em caches de modelos. Um modelo malicioso carregado uma vez pode permanecer disponível para reutilização, replicação entre nós ou promoção para ambientes de teste e produção. Em pipelines de IA, a distinção entre artefato experimental e artefato produtivo nem sempre é rígida. Se a organização permite que modelos sejam baixados automaticamente, sincronizados de repositórios externos ou reaproveitados sem inspeção do tokenizer.chat_template, a exposição pode persistir mesmo após a origem externa deixar de ser consultada.

• Servidores SGLang que carregam arquivos GGUF obtidos de fontes externas, espelhos internos ou pipelines automatizados.
• Rotas que acionam o reranking por meio de /v1/rerank e alcançam o código em entrypoints/openai/serving_rerank.py.
• Ambientes em que o processo do SGLang possui variáveis de ambiente, tokens, diretórios montados ou permissões além do necessário para inferência.
• Fluxos de MLOps que promovem modelos entre laboratório, homologação e produção sem revisão dos metadados interpretáveis.

Hunting e telemetria

A investigação deve começar pelo inventário de instâncias SGLang e pelo histórico de modelos GGUF carregados antes e depois da data de publicação do alerta. Equipes de segurança devem correlacionar eventos de download, importação, cache e inicialização de modelos com chamadas ao endpoint /v1/rerank. Um modelo recém-introduzido seguido por comportamento anômalo do processo de inferência merece prioridade, especialmente se o arquivo contém tokenizer.chat_template incomum, referência a Jinja2 ou estrutura incompatível com modelos previamente aprovados.

Na camada de aplicação, os logs de acesso devem ser filtrados por requisições a /v1/rerank, códigos de erro inesperados, picos de latência e padrões de uso que não existiam antes do carregamento de um modelo novo. A exploração pode ocorrer dentro de uma requisição aparentemente funcional, então a ausência de falha HTTP não elimina risco. Se houver logs de exceção do Python, mensagens de renderização de template ou rastros associados a Jinja2 no mesmo intervalo, esses sinais devem ser preservados para análise.

No endpoint e no host, a telemetria deve focar no comportamento do processo do SGLang. Execução de subprocessos, criação de arquivos fora dos diretórios esperados, conexões de rede iniciadas pelo serviço de inferência, leitura de arquivos de configuração sensíveis e acesso a variáveis de ambiente são sinais mais úteis do que apenas o conteúdo da requisição HTTP. Como o contexto confirma execução de código no processo do servidor, a defesa deve tratar o runtime como potencialmente comprometido até que os artefatos carregados e a linha do tempo sejam revisados.

Em ambientes de cloud ou containers, a investigação deve incluir logs do orquestrador, eventos de montagem de volumes, reinicializações de pods, alterações em imagens, políticas de serviço e permissões associadas à identidade usada pelo workload. A falha não implica automaticamente movimentação lateral ou exfiltração, mas a execução de código em um serviço com credenciais de cloud pode criar condições para abuso de permissões. A conclusão deve depender de evidências nos logs e não de suposições genéricas.

• Chamadas a /v1/rerank após carregamento recente de modelos GGUF não aprovados ou de procedência incerta.
• Presença de tokenizer.chat_template com construções Jinja2 incomuns, referências a SSTI ou conteúdo incompatível com o padrão de modelos permitidos.
• Atividade de processo anômala originada pelo serviço SGLang, incluindo subprocessos, gravações inesperadas e conexões de saída não previstas.
• Exceções, rastros ou mensagens de renderização envolvendo jinja2.Environment() no intervalo de uso do endpoint vulnerável.
• Mudanças em caches de modelos, artefatos promovidos por pipelines de MLOps e sincronizações automáticas de repositórios externos.

Mitigação

A mitigação principal é alterar a renderização de templates para usar ImmutableSandboxedEnvironment no lugar de jinja2.Environment(). Essa mudança reduz a capacidade de um chat_template controlado pelo modelo acessar primitivas perigosas durante a renderização. Como o contexto informa que não houve resposta ou patch obtido durante o processo de coordenação, operadores não devem depender apenas de atualização automática do projeto sem confirmar a correção no código em uso. A revisão local do caminho de renderização é necessária em implantações críticas.

Até que a correção esteja validada, a resposta defensiva deve combinar redução de superfície e controle de artefatos. O endpoint /v1/rerank deve ser exposto apenas a clientes autorizados e redes necessárias. Modelos GGUF devem ser carregados somente a partir de origens aprovadas, com registro de hash interno, revisão de metadados e bloqueio de importação direta por usuários sem autorização. Em ambientes onde modelos públicos são avaliados com frequência, a avaliação deve ocorrer em sandbox isolado, sem credenciais sensíveis e sem conectividade ampla para redes internas.

Também é recomendável revisar o privilégio do processo SGLang. O serviço deve executar com usuário dedicado, permissões mínimas, diretórios de escrita restritos e variáveis de ambiente reduzidas ao indispensável. Tokens de repositórios, credenciais de cloud, chaves de API e segredos de pipelines não devem estar disponíveis para o runtime se não forem essenciais. Caso um modelo suspeito tenha sido carregado, a rotação de credenciais deve ser guiada pelo que o processo conseguia acessar, e não por uma lista genérica de segredos.

A validação pós-mitigação deve confirmar que templates malformados ou perigosos deixam de alcançar execução de código e passam a falhar de forma controlada. A equipe também deve manter um inventário de modelos aprovados, registrar quando cada artefato foi introduzido e preservar logs de requisições ao endpoint de reranking. Para organizações com MLOps maduro, a política de segurança deve tratar modelos, tokenizers e templates como componentes de cadeia de suprimentos, submetidos a revisão semelhante à aplicada a pacotes de software e imagens de container.

• Substituir jinja2.Environment() por ImmutableSandboxedEnvironment no caminho que renderiza tokenizer.chat_template.
• Bloquear carregamento de modelos GGUF não verificados e revisar artefatos já armazenados em caches internos.
• Restringir /v1/rerank por autenticação, autorização e segmentação de rede compatíveis com o uso real do serviço.
• Executar SGLang com privilégio mínimo, sem segredos desnecessários no ambiente do processo e com diretórios de escrita limitados.
• Auditar modelos introduzidos recentemente, correlacionar com chamadas ao endpoint vulnerável e investigar comportamento anômalo do processo de inferência.
• Validar a correção em ambiente isolado antes de reabrir fluxos de importação automática de modelos externos.