O gateway de IA entrou no catálogo de exploração ativa

O fio desta semana é curto de enunciar e chato de resolver: o gateway de IA que você subiu para "testar" é infraestrutura de produção, e agora está no catálogo de exploração ativa. Na terça a CISA acrescentou de uma vez uma falha do Starlette, que é a base do FastAPI, do vLLM e do próprio LiteLLM, e uma falha do LiteLLM que entrega sessão MCP autenticada com token inventado. As duas com prazo federal para 16 de setembro. Nenhuma das duas é nova. As duas passaram meses disponíveis para quem quisesse usar.

O contraponto veio no dia seguinte, e é o mesmo assunto pelo outro lado: a OpenAI lançou o GPT-6 Astra, o modelo mais caro que ela já pôs em API, com uso de computador e um milhão de tokens de contexto. Quem opera software ganhou, na mesma semana, um brinquedo novo e a confirmação de que a camada que serve esse brinquedo é alvo. Vale reparar em qual das duas notícias exige trabalho hoje.

Fora isso, o Go 1.27 ganhou um perfil que encontra goroutine vazada em produção, a Nvidia confirmou a compra da Hugging Face e uma chave PGP expirada quebrou instalação de gh em imagem de CI. Oito itens. Três desenvolvidos.

Destaques

Starlette e LiteLLM no catálogo de exploração ativa, e o alvo é o seu gateway

Em 2 de setembro a CISA acrescentou sete CVEs ao catálogo de exploração ativa. Duas delas ficam na mesma pilha e se combinam.

A primeira é a CVE-2026-48710, batizada de BadHost, no Starlette. O problema é de uma linha: o framework remonta request.url concatenando o cabeçalho Host cru com o caminho, sem validar o Host antes. Se o cabeçalho traz /, ? ou #, a fronteira entre caminho e query se desloca na hora de reparsear. O resultado é o pior tipo de divergência: o roteador executa o endpoint certo, e o middleware que consulta request.url.path lê outro valor. Quem decide autorização olhando o caminho decide errado. A nota é 6,5, média, e essa nota engana. Afeta todas as versões até a 1.0.0 e corrige na 1.0.1, que valida o Host e cai para scope["server"] quando o valor é inválido.

A segunda é a CVE-2026-59822, no LiteLLM, 8,8. O endpoint MCP sobre HTTP aceitava passthrough de OAuth2 para servidor MCP upstream, e o caminho de fallback trocava a validação de chave que falhou por um objeto de autenticação vazio. Na prática: mandou um Authorization fabricado, entrou. Dá para listar e chamar as ferramentas MCP configuradas e alcançar o que estiver conectado atrás delas. Anteriores à 1.84.0 são afetadas.

O encadeamento é o que faz isso valer o seu dia. A Horizon3.ai mostrou em junho que a BadHost engata na CVE-2026-42271, a injeção de comando nos endpoints de teste de MCP do LiteLLM, que já estava no catálogo desde 8 de junho. A 42271 sozinha exige uma chave de proxy válida. Com a BadHost por cima, o requisito de autenticação some, e o que sobra é execução remota de código sem credencial nenhuma no host que guarda as chaves de todos os seus provedores de modelo.

Não é teoria. A Wiz rodou honeypot de LiteLLM, Flowise, LangChain, Langflow, ChromaDB e Ollama e publicou noventa dias de telemetria em 27 de agosto. Achou minerador entregue como configuração de servidor MCP, injeção de prompt cega confirmada por callback de DNS, e ferramenta de pós-exploração escrita especificamente para ler a master key do LiteLLM da memória do processo Python. Teve payload se escondendo em diretório /.claude/ para parecer configuração legítima de ferramenta de IA. O dado que fecha o argumento é o de base: 90% dos ambientes de nuvem que a Wiz mede rodam algum software de IA self-hosted.

O que muda na prática. Se você tem LiteLLM, vá para 1.84.0 ou acima, que cobre as duas falhas do gateway, e para Starlette 1.0.1 ou acima. Só que a superfície não termina aí, e essa é a parte que eu vejo passar batido: Starlette é dependência transitiva de qualquer coisa em FastAPI. Painel interno, webhook, serviço de embedding, a API que alguém subiu para um piloto de RAG no ano passado. pip list | grep -i starlette em cada imagem que está no ar responde mais rápido que discussão. E se a autorização do seu serviço é feita em middleware que lê request.url.path, essa falha é sua mesmo com o LiteLLM fora da conta. O contorno enquanto não dá para atualizar é bloquear /mcp/ no proxy reverso, e vale só para o gateway.

GPT-6 Astra saiu, e a mudança que mexe no seu código é a de código de erro

A OpenAI lançou o GPT-6 Astra em 3 de setembro, como gpt-6-astra. A ficha é grande: 1.050.000 tokens de contexto, 128 mil de saída, entrada de texto e imagem, corte de conhecimento em 30 de abril de 2026, e uso de computador como capacidade de primeira classe. Roda em Chat Completions, Responses e Batch. Não roda em Realtime nem em fine-tuning.

O preço merece leitura atenta porque tem uma dobra. A tabela oficial marca 10 dólares por milhão de tokens de entrada e 50 de saída, com entrada em cache a 1 dólar. Acima do limiar de contexto longo, os dois números sobem para 20 e 75. Ou seja: a conta de uma requisição que enche o contexto não é a mesma requisição multiplicada, é uma faixa de preço diferente. Quem for jogar documento inteiro na janela porque agora cabe precisa medir isso antes, não depois da fatura. Para comparação na mesma tabela, o GPT-5.6 Sol está em 4 e 20, em preço promocional que a própria página diz valer pelo menos até 21 de novembro de 2026. A diferença entre os dois é de duas vezes e meia na entrada.

Junto vieram controles novos na Responses API: chamada de ferramenta assíncrona, direcionamento no meio do turno e esforço de raciocínio ajustável. Isso é interessante para quem escreve agente.

Mas a mudança que eu abriria o editor para tratar hoje é de um dia antes, e é das pequenas. Em 2 de setembro a OpenAI separou os códigos de erro: limitação de tráfego agora devolve 429 com slow_down, e sobrecarga do servidor devolve 503 com server_is_overloaded. Antes vinha tudo no mesmo balaio. A diferença importa porque a resposta certa para cada um é oposta. Para 429 você recua e espalha as requisições no tempo. Para 503 você tenta de novo, e recuar demais só faz o seu serviço ficar parado enquanto o outro lado já voltou. Quem tem um except RateLimitError genérico com backoff exponencial em cima de tudo está tratando metade dos casos errado desde sempre, e agora tem como saber qual é qual. É uma tarde de trabalho e melhora a latência de cauda de qualquer coisa que chame a API em volume.

Go 1.27: um perfil que acha goroutine vazada em produção

O Go 1.27 saiu em 19 de agosto, e em 2 de setembro o time publicou o texto que explica o recurso mais prático da leva: perfil de goroutine vazada, de Vlad Saioc.

Vazamento de goroutine é a fuga de memória do Go, e até agora achar um era trabalho manual e ingrato: você tirava o dump de goroutines, olhava dez mil linhas e tentava adivinhar qual pilha não deveria estar ali. O perfil novo faz a classificação por conta própria. Ele marca como viva a goroutine que não está bloqueada por primitiva de concorrência, ou que está bloqueada por alguma primitiva ainda referenciada por outra goroutine viva. O que sobra está permanentemente bloqueado em canal, Mutex, RWMutex, WaitGroup ou Cond, e é vazamento de verdade, não suspeita.

Usar é barato. É mais um tipo de perfil no runtime/pprof, chamado goroutineleak, e quem já tem o net/http/pprof montado não precisa fazer nada: o endpoint aparece sozinho em /debug/pprof/goroutineleak. Pega com curl, abre no go tool pprof, e a pilha que aparece é o ponto onde a goroutine ficou presa.

Os limites estão declarados no próprio texto, e são honestos. Ele não vê goroutine bloqueada em I/O de arquivo ou de rede, nem em sincronização que você escreveu à mão. Ele não detecta vazamento cuja primitiva continua acessível por uma variável global, porque nesse caso não dá para provar que ninguém vai destravar. E a fase de marcação pode ser mais lenta que uma coleta comum, com pior caso quadrático no número de goroutines, então o conselho é perfilar periodicamente, não em laço apertado. Nada disso tira o valor: para serviço de longa duração que incha devagar ao longo de dias, essa é a primeira ferramenta do ecossistema que responde a pergunta em vez de dar material para você adivinhar.

Em nota

• A Nvidia confirmou a compra da Hugging Face. Semana passada eu registrei a história com ressalva, porque só existia imprensa e nenhuma confirmação. Ela veio em 3 de setembro, pela sala de imprensa da própria Nvidia: 12,93 bilhões de dólares, com fechamento esperado para o primeiro semestre do ano que vem. O texto promete plataforma aberta, suporte a modelos de todo o ecossistema e diz com todas as letras que computação Nvidia não será exigida para publicar nem para servir modelo pelo Hub. Anotado, e a promessa é o que vale ser cobrado daqui para frente. A recomendação prática não mudou: se o seu build baixa peso de hf.co em tempo de deploy, isso é ponto único de falha que não é seu, com ou sem dono novo.
• Sexto zero-day do Chrome no ano. A CVE-2026-85046 é confusão de tipo na V8 e entrou no catálogo da CISA em 4 de setembro. O Google diz saber que existe exploit em circulação e não deu detalhe de campanha enquanto a atualização rola. Corrigido na 152.0.7977.82 para Linux e .82/.83 para Windows e macOS. Reportado por Salvatore Gulizia. Não é servidor, mas é o navegador da máquina onde você tem as credenciais de tudo: feche e reabra o Chrome hoje, e cheque as máquinas da equipe que ficam ligadas há semanas sem reiniciar.
• A chave PGP do repositório Linux do gh expirou em 5 de setembro. O aviso saiu em 3 de setembro: metadados de APT e RPM e pacotes RPM novos passam a ser assinados só com a chave substituta. Quem instalou o gh pelo repositório oficial antes de 8 de abril de 2026 e não mexeu mais nisso vai ver a instalação falhar na verificação. Windows, macOS, Homebrew, binário solto e .deb baixado à mão não são afetados. É o tipo de coisa que quebra o Dockerfile do CI numa terça-feira sem ninguém ter mudado nada, então vale procurar por gh nas imagens de build antes que ela apareça sozinha.
• npm passou a aceitar mais de uma configuração de publicação confiável. O changelog de 3 de setembro removeu o limite de uma configuração OIDC por pacote: agora dá para ter workflows separados para estável, prerelease e staging sem manter token de vida longa para cobrir o que o OIDC não alcançava. As configurações são independentes e aditivas. A recomendação junto do anúncio é a parte boa: apontar as configurações para publicação em estágio, que exige aprovação humana antes de liberar, para que workflow comprometido não publique direto. Depois do ano que o npm teve, isso é higiene, não zelo.
• Kestra e JFrog Artifactory também entraram no catálogo, e as duas são ferramenta de quem constrói. Na mesma leva de 2 de setembro, a CVE-2026-49869 no Kestra OSS é injeção de comando, e a Microsoft observou exploração desde o fim de junho terminando em reverse shell, reconhecimento do ambiente Docker e minerador. A CVE-2026-82329 no Artifactory é falha de autenticação que na configuração padrão dá escalada para administrador sem credencial, segundo a watchTowr, com token de admin emitido para continuar a enumeração. É a segunda semana seguida com Artifactory no catálogo, por CVE diferente. Servidor de artefato comprometido não é um servidor a menos, é toda a sua cadeia de build.

O que eu faria com isso esta semana

1. Levantar a versão de Starlette em tudo que é Python, não só no gateway. O critério não é "a gente usa LiteLLM", é quais serviços têm FastAPI na árvore. Sobe para 1.0.1 ou acima. Onde tiver LiteLLM, 1.84.0 ou acima resolve as duas falhas dele de uma vez. Se a autorização de algum serviço seu é decidida em middleware que lê request.url.path, trate como prioridade e não como manutenção.
2. Se o gateway ficou exposto, não parar na atualização. A pesquisa da Wiz descreve pós-exploração que lê a master key da memória do processo. Correção fecha a porta e não gira as chaves por você. Rotacione as chaves dos provedores de modelo e olhe processo estranho antes de dar o caso por encerrado.
3. Separar 429 de 503 no cliente da OpenAI. É meia tarde de trabalho e as duas respostas certas são opostas: recuar e espalhar para 429, tentar de novo para 503. Quem trata tudo como limite de taxa fica parado quando não precisa.
4. Procurar gh nas imagens de CI antes da próxima build. A chave expirou sábado. Corrigir agora, com a documentação na frente, custa quinze minutos. Descobrir no meio de um deploy urgente custa o deploy.

Radar é a newsletter semanal deste blog: o que aconteceu na semana em tecnologia, com comentário sobre o que muda para quem constrói e opera software.