O gateway aceitou qualquer token

Em 2 de setembro, a CISA adicionou sete vulnerabilidades ao catálogo de Known Exploited Vulnerabilities. Dois bugs do SonicWall SMA1000, uma injeção de SQL no Sangoma Switchvox, um desvio de autenticação no JFrog Artifactory, uma injeção de comando de sistema no Kestra, uma falha de HTTP smuggling no Starlette e uma falha de autenticação imprópria no LiteLLM da BerriAI.

Três dessas sete são infraestrutura de IA e ML. A Forkast chamou isso de o primeiro lote KEV em que componentes de IA respondem por quase metade das adições, o tipo de marco que rende uma manchete e depois vai para o arquivo. Olhe qual infraestrutura de IA é essa e o lote merece mais do que arquivo. As três ficam no meio: são os componentes que você implanta para que seus agentes e os recursos que eles tocam parem de falar diretamente entre si. Comece pela entrada do LiteLLM.

O ramo de fallback

O LiteLLM é um gateway de IA: um proxy que fica entre seus agentes e os provedores de modelo, guarda as chaves dos provedores para que mais ninguém precise guardá-las, aplica orçamentos e limites de taxa, escreve os registros e agora se ramifica para servidores Model Context Protocol, de modo que os agentes de uma equipe compartilhem um único endpoint MCP em vez de cada desenvolvedor ligar o seu.

A CVE-2026-59822, publicada em 8 de julho e com CVSS 8.8 no aviso do GitHub, vive nesse endpoint MCP. Uma frase do aviso carrega a história inteira:

o caminho de fallback podia substituir uma validação de chave LiteLLM que falhou por um objeto UserAPIKeyAuth() vazio.

O endpoint MCP Streamable HTTP suportava passthrough OAuth2, para que um token destinado a um servidor MCP upstream pudesse atravessar o gateway em vez de ser validado contra o próprio repositório de chaves do LiteLLM. É um recurso razoável, e ele exige um ramo: tentar primeiro a chave LiteLLM e seguir o caminho de passthrough quando não é uma chave que chegou.

Chega-se a esse ramo falhando. Envie um cabeçalho Authorization contendo qualquer string, a validação de chave a rejeita porque a string não é uma chave, e o handler constrói um UserAPIKeyAuth() vazio e segue com ele. Sua requisição agora detém uma sessão MCP autenticada que não pertence a ninguém. Dali você enumera todas as ferramentas MCP com que o gateway foi configurado e as chama: aplicações internas, bancos de dados, consoles de nuvem, sistemas de desenvolvimento, o que quer que a equipe tenha conectado. A falha afeta todas as versões anteriores à 1.84.0. O prazo de remediação da CISA para as agências federais é 16 de setembro, e o conselho do LiteLLM para quem não pode atualizar hoje é bloquear /mcp/ no reverse proxy à frente dele.

Os outros três quebraram na mesma função

Leia o resto do lote e você obtém algo mais útil do que a manchete de IA contra não-IA.

Starlette, CVE-2026-48710, apelidada de BadHost. O Starlette é o toolkit ASGI sob o FastAPI, sobre o qual boa parte dos serviços de IA em Python, o LiteLLM incluído, é construída. Um cabeçalho Host forjado injeta um caminho na parte de host da requisição, o que desloca a forma como a URL é reconstruída, o que significa que um middleware de autenticação baseado em caminho avalia uma rota enquanto a aplicação serve outra. A entrada da CISA declara o resultado: desvio de autenticação, quando a autenticação depende do caminho da URL reconstruída. Ela leva um CVSS de 6.5, a nota mais baixa do lote e a que menos diz sobre a consequência. O LiteLLM lançou sua própria correção companheira para o mesmo formato na 1.84.0, descrevendo-a como “um cabeçalho Host forjado podia fazer o portão de autenticação do proxy avaliar uma rota diferente da que servia”, e disse aos operadores cujo proxy esteve exposto que rotacionassem as chaves e auditassem os registros de administração.

JFrog Artifactory, CVE-2026-82329, CVSS 9.8. Autenticação imprópria na configuração padrão: uma chave de junção “fantasma” que permite a um atacante não autenticado forjar tokens de administrador. A watchTowr documentou exploração em ambiente real em 1º de setembro, quatro dias após a divulgação, com atacantes cunhando credenciais de admin e enumerando usuários. Este é o repositório de artefatos, o host que responde a npm install e pip install para a organização inteira.

Kestra, CVE-2026-49869. Injeção de comando de sistema alcançável por um atacante remoto não autenticado, que pode criar e executar workflows arbitrários sem credencial alguma. O orquestrador faz o que um orquestrador faz, em nome de alguém que nunca fez login.

Quatro produtos, quatro bases de código diferentes e a mesma função quebrada em cada uma: aquela que decide se esta requisição tem o direito de estar aqui. Um objeto de autenticação vazio. Um caminho reconstruído. Uma chave de junção padrão. No caso do Kestra, verificação nenhuma na rota que executa as coisas.

O que os atacantes fizeram em seguida foi entediante, e o tédio é a marca do trabalho em volume. O The Hacker News reuniu o comportamento observado: reverse shells, mineradores XMRig, enumeração de credenciais e roubo de chaves de API e de credenciais de provedores de LLM. A Microsoft resumiu:

Os objetivos observados foram consistentes. Nos casos analisados, a telemetria mostrou coleta de credenciais, mecanismos de acesso duradouro e monetização de recursos, ainda que o caminho de execução variasse conforme o produto.

O gateway era a ideia certa, e esta é a conta

O gateway de IA é uma das melhores ideias dos últimos dois anos, e a maioria das equipes chegou a ele por razões sólidas.

Antes do gateway, o agente de código de cada desenvolvedor guardava uma chave de provedor numa variável de ambiente, cada desenvolvedor ligava seus próprios servidores MCP com seus próprios tokens, e ninguém sabia dizer quanto tudo aquilo havia gasto ou tocado. Colocar um gateway no meio resolve tudo isso de uma vez. Um único lugar guarda as chaves dos provedores e a configuração MCP, e escreve o registro. Rotacionar uma chave vira uma operação só, e cortar o acesso de um funcionário que sai também. A indústria convergiu para isso por um bom motivo.

A conta é que você construiu um serviço de rede cujo propósito inteiro é guardar a autoridade de todo mundo, e que decide quem você é com uma função. Funções têm ramos, e um deles trata o caso em que a primeira coisa que você tentou não deu certo.

O LiteLLM não inventou esse formato. Todo gateway tem uma porta da frente, toda porta da frente tem uma função de autenticação, e uma função de autenticação que suporta dois esquemas de credencial tem um caminho que ela toma quando o primeiro falha. O alcance que fica atrás dessa porta é deliberado: concentrá-lo é o produto. Então, quando um gateway se mete em apuros, tudo o que ele guarda já está na sala.

A conclusão que costuma se tirar de um incidente assim é “voltar às chaves por desenvolvedor”, o que é pior em qualquer métrica que se queira usar. Continue centralizando. A pergunta que vale discutir é onde a coisa centralizada fica, e se ela precisa atender requisições de estranhos para fazer seu trabalho.

Onde o Bromure coloca o mesmo trabalho

O Bromure Agentic Coding roda cada agente de código numa VM Linux virtualizada por hardware no seu próprio Mac, e todo controle de segurança fica do lado do host dessa fronteira. Os controles são a mesma lista que um gateway oferece: guardar as credenciais, mediar os servidores MCP, classificar o que o agente faz com a sua infraestrutura, manter o registro. Nada em rede alguma consegue alcançar o componente que os aplica.

Não existe porta da frente. O HTTPS do convidado nunca sai pela rede. Ele tunela por um socket virtio, a porta vsock 8443, até o proxy do host, e o manual é direto sobre a topologia: a VM não tem nenhuma outra rota para a rede. O proxy não mantém porta em escuta alguma que sua LAN, sua rede corporativa ou a internet possam endereçar. Ele nunca pergunta quem está chamando, porque uma única coisa está na outra ponta desse socket e o hipervisor decide o que essa coisa é. Sem cabeçalho Authorization, sem repositório de chaves, sem negociação de esquema e, portanto, sem ramo a tomar quando o primeiro esquema falha.

O token bearer do MCP é falso antes mesmo de chegar ao agente. Para servidores MCP com transporte HTTP configurados num workspace, o token bearer real permanece criptografado no Mac. A configuração do agente recebe um substituto brm-mcp_…. O painel de ajustes rotula esse campo como Nunca enviado à VM — trocado pelo proxy, e o proxy do host substitui o valor real no fio, limitado a correspondência exata ou de subdomínio ao host daquele servidor e a nenhum outro. O proxy também responde 404 aos caminhos de descoberta OAuth e OIDC do servidor, de modo que o Claude Code trate o servidor como pré-autenticado em vez de tentar um fluxo de navegador que a VM jamais conseguiria concluir. O fallback do LiteLLM se apoiava nessa mesma superfície de passthrough. Aqui o workspace não guarda credencial alguma para deixar cair.

Cada operação recebe a própria decisão. Um gateway resolve a questão na porta: passou por ela, e tudo o que está atrás é seu. Os Guardrails do Bromure classificam as chamadas do agente dentro do proxy, através de Kubernetes, AWS, forjas git, registries de contêineres e bancos de dados, e aplicam uma política de escrita por serviço. Workspaces novos vêm com Perguntar antes de escrever, de modo que as leituras fluem e cada mutação pausa num diálogo do lado do host mostrando a operação literal: o SQL exato, ou MÉTODO /caminho. Somente leitura bloqueia toda mutação. Perguntar antes de usar controla a própria credencial, com concessões medidas em minutos. Uma sessão forjada ainda não consegue abrir caminho com um kubectl delete por nada, porque a segunda decisão acontece no seu Mac e não deve nada ao modo como a primeira correu.

Negar por padrão responde à alcançabilidade, nos dois sentidos. O firewall de saída do workspace é uma tabela ordenada de regras com um padrão para o tráfego não correspondido. Ponha-o em Negar e a VM alcança os hosts que você listou e mais nada, em qualquer protocolo. Dois componentes fora do convidado aplicam isso: o switch virtual casa cada fluxo por IP de destino e nome de host capturado do DNS, e o proxy casa de novo pelo nome de servidor TLS. As edições chegam às sessões em andamento sem reinício. No outro sentido, o modo NAT mantém as VMs fora da sua LAN física, e nada de fora abre conexão até elas a menos que você publique um serviço de propósito. Os scanners que varreram aqueles gateways expostos não recebem resposta alguma de um Mac.

Tudo o que um gateway comprometido devolve é entrada não confiável. Esta parte sobrevive à CVE. Uma vez que um gateway pertence a outra pessoa, saída de modelo, resultados de ferramentas e strings de erro chegam todos de um atacante, no fio de maior privilégio da pilha: aquele sobre o qual o agente foi construído para agir. O detector de código-fonte do Bromure pontua os trechos tool_result no tráfego de IA de saída do agente com um modelo PromptGuard local, no dispositivo, antes que o modelo aja sobre eles, e pode registrar, perguntar ou bloquear; um bloqueio devolve HTTP 451 e o modelo nunca vê o conteúdo.

A perna de exfiltração falha fechada. Toda credencial de um workspace é uma falsificação determinística com um único destino legítimo. O proxy varre cada requisição de saída em busca de uma falsificação indo para onde não foi cunhada; quando encontra uma, recusa a requisição sem encaminhar um byte, pausa a VM e levanta um alerta, registrado como uma linha vermelha de Corretagem de credenciais na Security Timeline. Como só a falsificação esteve ao alcance, a credencial real não precisa ser rotacionada.

Guarde o segredo, não o verifique

Uma linha das próprias notas de arquitetura do Bromure merece releitura depois de uma semana como esta:

Contornar a fronteira não rende nada a um atacante, porque a fronteira não é onde os segredos são verificados — é o único lugar onde os segredos existem.

Um gateway é um lugar onde credenciais são verificadas: uma requisição chega, uma função a inspeciona, e o veredito dessa função é a única coisa entre o chamador e as chaves. Verificações têm casos de borda e caminhos de fallback. Verificações rendem uma CVE, uma entrada KEV e um prazo federal, e depois rendem outra dois meses adiante num ramo diferente da mesma função.

Uma fronteira de fio é um lugar onde as credenciais estão. Nada chega para ser inspecionado, então nenhum veredito pode dar errado. O token real fica criptografado num Mac, o workspace guarda um substituto brm- que não vale nada em lugar nenhum, e a substituição acontece num socket em que só um hipervisor pode escrever.

Já escrevemos variações disto três vezes em seis semanas: um proxy de saída que confiou num hostname que o agente podia escrever, um guardião de comandos que lia bash de outro jeito que o bash e três agentes de código cujos desvios terminavam todos numa credencial real dentro de um processo. Toda vez, o componente que falhou estava fazendo um trabalho honesto de avaliar alguma coisa, e essa é a constante. Avaliação é uma primitiva mais fraca que ausência, e continuamos entregando à avaliação o trabalho que a ausência faz de graça.

Centralizar a autoridade dos seus agentes foi a decisão certa. Ponha a coisa centralizada onde ninguém possa lhe mandar uma requisição. Instale o Bromure Agentic Coding e dê a cada agente uma fronteira sem porta da frente.