2026/10/28

Node2Shell (CVE-2026-111497): quais sistemas estão em risco e o que fazer agora

Quais sistemas a CVE-2026-111497 no Brotli realmente expõe, a urgência de cada caso e como corrigir, reconstruir, reiniciar e mitigar já.

Atualizado em 27 de outubro de 2026

A CVE-2026-111497, apelidada de “Node2Shell” ou “HTTP2Shell”, é uma falha de corrupção de memória no descompressor Brotli. Brotli é a compressão br usada em toda a web. A falha está nas versões 1.0.3 a 1.2.0 da biblioteca Brotli do Google [1]. O Node.js inclui essa biblioteca, e o projeto Node.js classificou o problema como de severidade alta (High) para as linhas 22.x, 24.x e 26.x [2]. O mesmo decodificador é distribuído em pacotes Python, bibliotecas de sistema Linux, aplicativos desktop e ferramentas de desenvolvimento, portanto a exposição real é muito mais ampla do que “servidores Node.js”.

Este artigo é para equipes que precisam decidir rapidamente se estão expostas e o que fazer primeiro.

Conclusão: se algum dos seus sistemas descomprime dados Brotli vindos de alguém que você não controla (um cliente na internet, um site externo, um remetente de webhook, um arquivo enviado), trate isso como urgente. Aplique o patch, reconstrua, reinicie e, enquanto isso, bloqueie br.

O que a vulnerabilidade faz

O decodificador trata incorretamente um “block switch” malformado no fluxo comprimido. Ele interpreta o erro como “preciso de mais entrada” em vez de “estes dados são inválidos” e continua acrescentando bytes a um pequeno buffer interno de tamanho fixo até escrever além do seu fim [2]. Um atacante que consiga fazer sua aplicação descomprimir um fluxo Brotli manipulado pode corromper a memória do processo. Isso pode levar a:

Uma falha do processo (negação de serviço). Este é o resultado mais confiável.
Vazamento de memória do processo. Respostas ou logs podem expor fragmentos de segredos, tokens ou dados de outros usuários.
Possível execução remota de código. O Node.js lista RCE como impacto possível [2]. A primeira prova de conceito pública só alcançou execução de código contra um build deliberadamente enfraquecido, mas pesquisadores relataram depois execução de código, ainda que pouco confiável, contra um build oficial e não modificado do Node.js 24.22.0 [3].

Nenhuma autenticação é necessária: o atacante só precisa entregar bytes que cheguem ao decodificador. É por isso que a pontuação CVSS 4.0 é 9.2 (Critical) [1]. A pergunta-chave para cada sistema, portanto, não é “usamos Brotli?”, mas “uma parte não confiável consegue nos fazer descomprimir Brotli?”

Casos de uso típicos e seu risco

Caso 1: APIs expostas à internet que aceitam corpos de requisição comprimidos (prioridade máxima)

Alguns servidores de API Node.js, BFFs, gateways de API e endpoints de upload descomprimem corpos de requisição enviados com Content-Encoding: br. Outros fazem o mesmo por meio de middleware. Risco: qualquer cliente anônimo na internet pode enviar um corpo manipulado. Os efeitos vão desde derrubar o serviço repetidamente, um DoS barato, até vazar memória de um processo que guarda dados de sessão e chaves de API. Urgência: emergencial. Aplique o patch hoje e bloqueie corpos de requisição br na borda até concluir.

Caso 2: Serviços que buscam conteúdo externo (alta prioridade)

Consumidores de webhooks, crawlers e scrapers, serviços de pré-visualização de links e RSS, integrações de pagamento ou SaaS e agentes de IA que navegam na web fazem requisições HTTP de saída. Muitos clientes HTTP enviam Accept-Encoding: br e descomprimem a resposta automaticamente. Em Python, urllib3 e requests fazem isso sempre que o pacote Brotli ou brotlicffi está instalado, mesmo que seu código nunca o importe. aiohttp faz o mesmo, e httpx também, quando instalado com o extra brotli [4]. Risco: um servidor remoto malicioso, comprometido ou falsificado pode atacar seu backend por meio da resposta. O atacante nem precisa alcançar sua rede: é você quem o chama. Urgência: alta. Aplique o patch primeiro onde os destinos não forem totalmente confiáveis.

Caso 3: Aplicativos desktop, agentes de programação com IA e CLIs com runtime embutido

Aplicativos Electron, CLIs baseadas em Bun ou Node e ferramentas de desenvolvimento com IA carregam sua própria cópia do runtime. Atualizar o pacote node do sistema não os corrige. Atualizar o aplicativo em disco também não corrige cópias que já estão em execução: processos de longa duração mantêm o runtime antigo na memória até serem reiniciados. Risco: essas ferramentas costumam guardar credenciais e buscar conteúdo externo, o que combina o Caso 2 com um processo privilegiado. Urgência: alta para ferramentas que buscam conteúdo não confiável. Atualize-as e, em seguida, reinicie-as de fato. Abordamos em detalhe a armadilha do “atualizado, mas ainda executando o código antigo” em HTTP2Shell: por que atualizar um binário não corrige processos em execução.

Caso 4: Imagens de contêiner e artefatos de CI/CD

Imagens construídas FROM node:22, node:24 ou node:26 antes da correção ainda contêm o runtime vulnerável, mesmo que o host esteja corrigido. O mesmo vale para wheels Python empacotados e dependências vendorizadas. Risco: o código vulnerável volta a cada deploy e a cada evento de autoscaling até que a imagem seja reconstruída. Urgência: alta para imagens por trás dos Casos 1 e 2. Reconstrua em vez de apenas reiniciar.

Caso 5: Bibliotecas de sistema Linux, fontes e processamento de imagens

As distribuições fornecem o decodificador como biblioteca compartilhada, por exemplo libbrotli1 no Ubuntu/Debian. Ele é usado por curl e libcurl quando a compressão está habilitada, pelo FreeType para fontes web WOFF2 e, indiretamente, por ferramentas de imagem e documentos como o Pillow. Risco: sistemas que renderizam fontes ou documentos enviados por usuários, ou que obtêm conteúdo externo com curl --compressed, podem ser alcançados por dados Brotli não confiáveis. Um servidor que nunca alimenta essas bibliotecas com dados externos tem baixa exposição prática. Urgência: média na maioria dos casos, mas alta para serviços de renderização de documentos ou de processamento de uploads. O Ubuntu publicou pacotes brotli corrigidos para 22.04, 24.04, 26.04 e 26.10 [1]. Para RHEL, Oracle Linux e outras distribuições, consulte o boletim do seu fornecedor para o pacote brotli em vez de presumir um status.

Caso 6: Sistemas apenas internos com entradas confiáveis (prioridade menor)

Alguns serviços descomprimem Brotli apenas de dados que você mesmo produz, como caches internos ou seus próprios artefatos de build. O risco é menor, mas não nulo: um atacante que já tenha um ponto de apoio pode usar a falha para avançar ainda mais. Urgência: aplique o patch no próximo ciclo regular.

O que fazer: etapas de resposta

Etapa 1: Descubra onde o Brotli é decodificado (hoje)

Node.js: verifique node -v em cada host e em cada imagem de contêiner e runner de CI. Procure no código e nas configurações por brotliDecompress, createBrotliDecompress e middleware de parsing de corpo que descomprima br.
Runtimes embutidos: liste os aplicativos Electron, CLIs Bun/Node e agentes de IA em uso e registre a versão do runtime que cada um embute, não apenas a versão do aplicativo.
Python: pip show Brotli brotlicffi em cada ambiente e imagem. Procure por httpx[brotli] e dependências transitivas em lockfiles e SBOMs.
Pacotes do SO: dpkg -l | grep brotli ou rpm -qa | grep brotli e, em seguida, veja quais processos realmente carregam a biblioteca.
Priorize com base nos casos acima: tudo o que pode ser alcançado por entrada não confiável (Casos 1, 2, 3 e 5 com uploads) vem primeiro.

Etapa 2: Aplique patches nos componentes afetados

Node.js: atualize para 22.23.4, 24.22.1 ou 26.12.1 ou posterior [2].
Python: Brotli>=1.2.1 ou brotlicffi>=1.2.1.0. Regenere os lockfiles [4].
Brotli upstream / código C vendorizado: 1.0.10, 1.1.1 ou 1.2.1, dependendo do branch [1].
Pacotes do SO: aplique a atualização de segurança da sua distribuição para brotli / libbrotli.
Aplicativos desktop e agentes: atualize para versões do fornecedor que declarem incluir o runtime corrigido. Se o fornecedor não publicou nada, trate o aplicativo como não verificado, e não como seguro.

Etapa 3: Reconstrua, reimplante e reinicie

Reconstrua as imagens de contêiner a partir de imagens base corrigidas e reimplante. Reiniciar uma imagem antiga não resolve.
Reinicie todo processo de longa duração que tinha a biblioteca vulnerável carregada: serviços Node, workers, sessões de agentes e qualquer coisa vinculada à biblioteca do sistema. Para jobs com estado e agentes de IA, drene ou transfira o trabalho antes, para não perder eventos ou aprovações em fila.

Etapa 4: Mitigue enquanto aplica os patches

Entrada: rejeite corpos de requisição cujo Content-Encoding contenha br no proxy reverso, no balanceador de carga ou no WAF, antes que qualquer decodificador os veja.
Saída: remover br do Accept-Encoding não basta por si só, porque um servidor malicioso pode enviar br mesmo assim. Rejeite também, ou recuse-se a decodificar, respostas que cheguem com Content-Encoding: br [4].
Alternativa em Python: onde a atualização precisar esperar, desinstale Brotli e brotlicffi para que os clientes parem de decodificar br. Teste antes, pois alguns servidores continuarão enviando br.

Etapa 5: Verifique e fique atento a sinais de exploração

Confirme a versão do runtime de dentro do processo ou contêiner em execução, e não apenas pelo gerenciador de pacotes.
Escaneie novamente imagens e SBOMs para garantir que nenhuma cópia antiga continue sendo puxada de forma transitiva.
Revise os logs recentes em busca de falhas inexplicadas, segmentation faults ou loops de reinicialização em serviços que lidam com br. Um conjunto de falhas vindas de uma única origem merece ser investigado como tentativa de ataque.
Se um serviço de alta exposição falhou inesperadamente antes de receber o patch, considere rotacionar os segredos que esse processo mantinha, já que não é possível descartar vazamento de memória.

Resumo

Situação	Risco	Ação
API pública decodifica corpos de requisição `br`	Crítico	Aplique o patch agora; bloqueie `br` na borda
Backend busca URLs externas, webhooks ou páginas web	Alto	Aplique o patch agora; recuse respostas `br`
Aplicativos Electron, agentes de IA ou CLIs com runtime embutido	Alto	Atualize e reinicie cada instância em execução
Imagens de contêiner antigas e artefatos de CI	Alto	Reconstrua a partir de bases corrigidas e reimplante
Biblioteca do sistema usada para uploads, fontes ou `curl --compressed`	Médio–Alto	Aplique a atualização do SO; reinicie os serviços que a carregam
Apenas dados internos e confiáveis	Baixo–Médio	Aplique o patch no próximo ciclo

Aplicar o patch no pacote é só metade do trabalho. A exposição só desaparece quando nenhum processo em execução, imagem ou runtime embutido ainda consegue decodificar Brotli não confiável com o código antigo.