Node2Shell: a falha crítica do Brotli que atingiu Node.js, .NET e Python (2026)

Se a sua aplicação roda em Node.js, .NET ou qualquer serviço que descomprime dados Brotli vindos de fora, atualize o runtime. Em 21 de outubro de 2026 — no mesmo pacote de correções que trouxe a php2shell ao PHP — veio à tona a Node2Shell (CVE-2026-111497): uma falha crítica no descompressor Brotli do Google, a biblioteca que o Node.js e muitos outros softwares embutem. O detalhe que a torna interessante não é um produto só: uma única biblioteca compartilhada obrigou a corrigir Node.js, .NET, PowerShell, Python, Bun e mais, tudo na mesma semana. Este post explica o que é a falha, quem realmente está exposto, como ela funciona e o passo a passo para corrigir.

O que é a Node2Shell

É uma falha no descompressor Brotli — tecnicamente, uma escrita fora dos limites (out-of-bounds write) causada por um retorno de erro que não era checado. O Brotli é o algoritmo de compressão criado pelo Google e usado em toda a web (é o Content-Encoding: br que o seu navegador negocia com os servidores). O problema não está no HTTP nem no Node.js em si: está no código C do descompressor, que o Node e dezenas de outros projetos compilam junto. A CISA, aliás, catalogou a falha pelo nome “Google Brotli Unchecked Return Value Vulnerability”.

A gravidade é 9,2 de 10 na escala CVSS 4.0 (classificação do Google). O impacto possível: dados Brotli cuidadosamente montados corrompem a memória do descompressor e, a partir daí, podem travar o processo, vazar pedaços de memória ou — no pior caso — levar à execução remota de código. As versões afetadas da biblioteca vão da 1.0.3 à 1.2.0; a correção está nas 1.0.10, 1.1.1 e 1.2.1. A falha foi descoberta pela equipe de segurança da OpenAI.

Por que isso não é só Node.js

Aqui está o ângulo que vale guardar: quando a falha mora numa dependência compartilhada, ela não respeita a fronteira de uma linguagem. O mesmo descompressor Brotli está embutido em muita coisa, e por isso a semana virou uma corrida de patches em paralelo:

• Node.js — corrigido nas versões 22.23.4, 24.22.1 e 26.12.1;
• Microsoft — atualização fora de ciclo em 25/10: .NET 8.0.33, 9.0.22 e 10.0.14 (mais o .NET 11 RC3), Visual Studio 2019/2022/2026 e PowerShell 7.4/7.5/7.6;
• Python — os pacotes Brotli (1.2.1) e brotlicffi (1.2.1.0) no PyPI;
• Bun, Envoy e Istio também publicaram versões corrigidas.

E ainda há projetos que, segundo os rastreadores públicos (eles mesmos se declaram incompletos), seguiam sem correção quando a notícia saiu — DuckDB, Apache Arrow, variações do 7-Zip e o EDK II (firmware). Nem toda configuração desses projetos expõe o código vulnerável, mas o recado é o mesmo: procure o Brotli no seu stack, não só o Node.

Quem está exposto (e quem não está)

A boa notícia: a exposição não é automática. Para a falha ser alcançada, dados Brotli controlados por um atacante precisam chegar ao descompressor nativo. Nos testes da Imperva, dois caminhos típicos em Node.js levam até lá:

• Resposta consumida pela aplicação: o seu serviço faz uma chamada de saída e descomprime uma resposta Brotli de outro servidor usando o fetch() embutido do Node. Se esse “outro servidor” for hostil (ou um SSRF levar a aplicação a falar com ele), os dados chegam ao decoder.
• Corpo da requisição: aplicações em Express 5.0.0–5.3.0 ou body-parser 2.0.0–2.3.0, com o tratamento de Brotli configurado, descomprimem o corpo que o cliente enviou (Content-Encoding: br).

E a parte que evita pânico: um servidor HTTP puro do Node não decodifica um corpo Brotli só por recebê-lo. Ou seja, nem toda aplicação Node está exposta — mas basta um dos padrões acima (e eles são comuns em APIs e integrações) para estar. A dúvida certa não é “eu uso Node?”, e sim “a minha aplicação descomprime Brotli de alguma fonte que eu não controlo?”.

Como a falha funciona

Em linguagem de gente: o descompressor Brotli continua trabalhando depois de uma condição que deveria ter parado. Uma transição interna que a estrutura do fluxo torna impossível acaba sendo interpretada como “preciso de mais dados”, e a decodificação segue a partir de um estado inválido — momento em que pode escrever além do espaço reservado na memória. É essa corrupção de memória que, encadeada, abre caminho para o resto. A correção upstream é justamente fazer o decoder retornar um erro de formato e repassá-lo a quem chamou, em vez de seguir em frente. (Não vamos publicar detalhes de exploração aqui.)

Está sendo explorada?

Vale ser honesto sobre o estágio, sem exagero nem minimização. A Imperva demonstrou execução remota de código numa prova de conceito contra a imagem oficial do Node.js 24.22.0 (o mesmo payload foi rejeitado no 24.22.1 já corrigido) — então não é só teoria, embora o exploit não funcione em toda tentativa e não tenha sido publicado. Em paralelo, parte dos pesquisadores argumenta que, em muitos cenários, o efeito prático fica em negação de serviço. O ponto decisivo para quem toma decisão: em 27 de outubro de 2026 a CISA incluiu a CVE-2026-111497 no catálogo KEV (vulnerabilidades comprovadamente exploradas), com prazo de 10 de novembro para as agências federais dos EUA corrigirem. Quando algo entra no KEV, a conversa deixa de ser “se” e passa a ser “quando” — a hora de atualizar é agora.

Como corrigir agora

1. Descubra onde o Brotli está. Não olhe só o Node: mapeie serviços em .NET, scripts em PowerShell, dependências Python (Brotli/brotlicffi) e proxies como Envoy/Istio. A pergunta é por runtime e por biblioteca, não por app.
2. Atualize o runtime. No Node.js, para uma versão corrigida (lançadas em 21/10/2026):

   Node.js 22.x  →  22.23.4
   Node.js 24.x  →  24.22.1
   Node.js 26.x  →  26.12.1

   Em .NET, aplique a atualização fora de ciclo da Microsoft (25/10); em Python, suba os pacotes Brotli para 1.2.1 / 1.2.1.0.
3. Reinicie o processo e reconstrua as imagens. Este passo é fácil de esquecer: um processo já em execução continua usando o código Brotli antigo (vulnerável) carregado na memória. Atualizar o pacote não basta sem reiniciar o serviço — e, em contêineres, sem reconstruir a imagem sobre a base já corrigida.
4. Linha fora de suporte? O Node.js 20.x chegou ao fim de vida em abril de 2026 e não recebeu correção oficial — se você ainda roda nele, migre para uma linha suportada, não espere um patch.
5. WAF como camada temporária. Regras de WAF para o vetor conhecido ajudam a ganhar tempo (a própria Imperva publicou proteções), mas não fecham a falha — o patch é a única correção definitiva.

A lição que fica: a sua superfície inclui as dependências

A Node2Shell é um lembrete de uma verdade incômoda: você não roda só o código que escreveu. Roda uma pilha de bibliotecas de terceiros compiladas junto, e a falha de uma delas vira a sua falha — às vezes em lugares que você nem associava àquela dependência (quem imaginaria que uma falha de compressão apareceria no PowerShell e no .NET ao mesmo tempo?). É o mesmo tipo de risco de cadeia de suprimento que vimos no ataque via ConnectWise, só que agora pela via da dependência embutida, não do fornecedor SaaS.

Por isso um inventário honesto de dependências (SBOM) e um pentest que teste a aplicação do jeito que um adversário real testaria — incluindo os pontos onde ela processa dados de fora — valem mais do que confiar que “está tudo atualizado”. Se você quer mapear onde a sua plataforma processa entrada não confiável e onde isso vira risco, fale com um pesquisador. E, de forma mais ampla, um pentest periódico encontra essas portas antes que elas virem manchete.

Fontes e análises: NVD CVE-2026-111497, CISA KEV, Imperva, SecurityWeek e Akamai. Os números de versão e o status de exploração podem ser revisados conforme a investigação avança — confirme sempre no aviso oficial do seu runtime e da sua distribuição.