CVE-2026-111497: Um bug no Brotli, nove runtimes e o agente Codex que o encontrou

O incômodo em relação ao CVE-2026-111497 é que não se trata de uma única vulnerabilidade em um único produto. Trata-se de um único out-of-bounds write — uma gravação fora dos limites — no descompressor Brotli do Google, e o mesmo bug é acessível por pelo menos oito runtimes e proxies distintos que incorporam a biblioteca — Node.js, .NET e ASP.NET Core, o Brotli e o brotlicffi do Python, Bun, Envoy, Istio e a implementação pure-Go. A medição da Wiz coloca 91% dos ambientes de nuvem em risco e observa que 82% deles expõem o Node.js publicamente. A CISA a incluiu no catálogo Known Exploited Vulnerabilities, e a Microsoft lançou um patch emergencial para .NET e Visual Studio.

A segunda metade da história é quem a encontrou: Khai Tran e Sylvie Mayer, da OpenAI Codex Security, de acordo com o relato da Wiz e os créditos upstream. Trata-se de uma equipe de agentes de segurança de IA, e a falha que ela encontrou está na biblioteca de descompressão mais amplamente incorporada da web.

O que o bug faz

O Brotli é o que quase todo stack HTTP descomprime quando um servidor envia code>Content-Encoding: br/code>. Um stream comprimido malformado causa uma gravação fora dos limites durante a descompressão, e a pontuação CVSS v4 é 9,2. O intervalo afetado é Brotli 1.0.3 até 1.2.0, corrigido em 1.0.10, 1.1.1 e 1.2.1.

O que faz disso um programa em vez de um ticket é que a biblioteca é incorporada ao código (vendored), ligada estaticamente ou reimplementada em cada runtime, de modo que a correção chega por um trem de lançamento diferente em cada caso — e às vezes não chega de jeito nenhum, porque a distribuição padrão de uma linguagem tem sua própria cópia.

A lista de patches, que é a parte útil

Todos os números abaixo vêm do resumo de advisories da Wiz e das releases dos respectivos projetos, consultados em 30 de outubro de 2026.

• Google Brotli / libbrotli — afetado: 1.0.3–1.2.0, excluindo backports corrigidos; corrigido em 1.0.10, 1.1.1, 1.2.1.

• Python Brotli — afetado em 1.0.3–1.2.0; corrigido em 1.2.1. brotlicffi — afetado em 1.0.3–1.2.0.x; corrigido em 1.2.1.0.

• Node.js — versões afetadas: 22.x, 24.x e 26.x; corrigido nas versões 22.23.4, 24.22.1 e 26.12.1.

• Bun — afetado 1.0.21–1.4.3; corrigido em 1.4.4.

• Envoy Proxy — afetado 1.36.11, 1.37.7, 1.38.5, 1.39.2; corrigido em 1.36.12, 1.37.8, 1.38.6, 1.39.3 e 1.40.0.

• Istio — afetadas as versões 1.29.0–1.29.8, 1.30.0–1.30.5 e 1.31.0–1.31.1; corrigido em 1.29.9, 1.30.6 e 1.31.2.

• andybalholm/brotli (Go) — afetado antes da v1.2.7; corrigido na v1.2.7.

A linha do Node.js é a que decide a semana da maioria das pessoas. Um serviço em 22.22.x fica exposto por meio de sua pilha HTTP mesmo que seu código de aplicação nunca mencione Brotli, porque a descompressão ocorre antes de seu handler ser chamado. Isso também explica os três nomes que a indústria atribuiu a ele: Node2Shell para o caminho Node, HTTP2Shell para o caminho do proxy documentado pela Check Point, e Brotli2Shell da JFrog para o quadro mais amplo.

Por que “91%” é o número com o qual se deve argumentar

Os números da Wiz descrevem os ambientes de nuvem dos clientes da Wiz, não a internet. Uma contagem de ambientes com uma biblioteca vulnerável em algum lugar neles não é uma contagem de serviços exploráveis, e a diferença é grande: um Brotli empacotado dentro de um aplicativo de desktop que nunca descompacta entrada não confiável é um achado, não uma vulnerabilidade. A versão útil da estatística é mais restrita — serviços que aceitam entrada comprimida de fontes não confiáveis, o que é essencialmente todo endpoint HTTP público que termina em code>br/code>.

Duas coisas tornam a exploração plausível, e não teórica: a inclusão pela CISA no catálogo KEV implica exploração observada, e operadores de honeypot registraram tentativas. Quando uma falha passa para a coluna de explorada em ambiente real, o prazo para aplicação do patch deixa de ser o seu calendário de controle de mudanças e passa a ser o de outra pessoa.

A descoberta é a parte com uma meia-vida mais longa.

A equipe de segurança de um modelo de fronteira encontrou uma falha de segurança de memória em uma biblioteca de descompressão que foi lida por milhares de pessoas ao longo de uma década. Isso não é uma história sobre um fornecedor sendo astuto; é uma afirmação sobre cobertura. A análise estática vem sendo aplicada ao Brotli há anos, harnesses de fuzzing já existem, e a falha sobreviveu a ambos — enquanto um agente projetado para ler código com intenção a encontrou e produziu uma correção que o upstream aceitou.

A assimetria corta nos dois sentidos. A mesma capacidade que encontra esse tipo de bug vai encontrá-lo no código que você entrega. A questão para qualquer pessoa que trabalha com codificação agêntica não é se o agente consegue detectar uma escrita fora dos limites; é se a descoberta chega até você antes de chegar a outra pessoa.

O que fazer, na ordem que importa.

Aplique patches nos runtimes que você realmente executa. A lista de bibliotecas acima é a fonte; comece pelas que terminam o tráfego público.

• Depois, procure cópias vendorizadas. Imagens base de contêiner, binários estáticos, builds WASM e wheels de linguagem carregam cada um seu próprio Brotli, e nenhum deles aparecerá em uma auditoria de gerenciador de pacotes da aplicação. Um scanner de inventário em nível de repositório publicado esta semana percorre um sistema de arquivos e avalia cada cópia de Node, Bun e Brotli que encontra, o que é um começo mais rápido do que inventar um.

• Reconstrua em vez de aplicar patches, sempre que possível. Substituir uma biblioteca ligada estaticamente dentro de um artefacto já compilado é onde as pessoas acabam por enviar acidentalmente um binário parcialmente corrigido.

• Se você executa o Envoy ou o Istio como uma camada de borda, trate as correções do proxy como a prioridade mais alta do conjunto: o proxy descompacta em nome de tudo o que está atrás dele.

• Verifique separadamente o seu ambiente .NET. O patch da Microsoft abrange .NET e Visual Studio, e a versão correta é uma atualização de runtime, e não uma alteração de referência de pacote.

Onde isto se situa para os nossos leitores

A maior parte do que este blog aborda é capacidade do modelo, preço e roteamento. Isso tem lugar aqui por causa de uma linha: o defeito foi encontrado por um agente de IA, e a classe de sistema que encontra esses bugs é a classe de sistema que nossos leitores estão integrando aos seus pipelines. Um agente de varredura de repositório que roda em CI contra suas dependências agora é um controle de segurança, e é o mesmo runtime de agente que escreve seu código.

O Agent Firewall do OrcaRouter avalia chamadas de ferramentas e MCP antes que sejam executadas, que é o controle que limita o raio de impacto de um agente; ele não torna corretas as constatações de um agente, e nada sobre esta CVE é uma alegação de que rotear um modelo reduz o risco da cadeia de suprimentos. O que vale a pena tirar da semana é mais restrito e verificável: se você deu a um agente acesso de leitura ao repositório para encontrar bugs, verifique se os patches propostos por ele estão fixados e verifique se o runtime por baixo da sua própria stack ultrapassou 1.0.3–1.2.0.

O padrão que vale a pena lembrar é que a vulnerabilidade estava em código que ninguém escolheu. O Brotli chegou como dependência transitiva de um recurso de runtime, foi corrigido em oito lugares em cronogramas separados e continuará chegando dentro de imagens base que foram construídas antes desta semana. A resposta à cadeia de suprimentos é, em grande parte, a disciplina de encontrar as cópias que você não instalou.

Nota de fontes: a matriz de versões afetadas e corrigidas, a lista de runtimes e os números de exposição de 91%/82% vêm do resumo do comunicado da Wiz lido em 30 de outubro de 2026, e as versões corrigidas são os próprias lançamentos dos projetos. A pontuação de 9,2 no CVSS v4 vem do registro da CVE. O crédito pela descoberta a Khai Tran e Sylvie Mayer, da OpenAI Codex Security, vem do relatório da Wiz e dos créditos do upstream. A inclusão no KEV da CISA e o patch do .NET da Microsoft são os anúncios das respetivas organizações; nenhum deles foi lido como documento primário aqui além do resumo do comunicado. A descrição do scanner de inventário é a descrição do próprio projeto de terceiros no GitHub.