Se o aplicativo, o site, a loja virtual ou a API da sua empresa foi desenvolvido com Node.js, incluindo sites feitos com Next.js e backends com Express ou NestJS, peça hoje ao seu desenvolvedor para atualizar o Node.js para a versão 22.23.4, 24.22.1 ou 26.12.1 e depois reconstruir e reiniciar o servidor. O projeto Node.js lançou essas versões em 21 de outubro de 2026 para corrigir uma falha conhecida como Node2Shell (CVE-2026-111497), com nota 9.2 de 10, que permite a um invasor sem nenhuma senha executar código no seu servidor enviando dados comprimidos especialmente manipulados. A Autoridade Nacional de Cibersegurança da Arábia Saudita (NCA) emitiu um alerta de nível “muito alto”, e em 27 de outubro a agência americana de cibersegurança CISA confirmou que a falha está sendo explorada em ataques reais.

O que aconteceu exatamente?

A falha está no Brotli, um formato de compressão que servidores web e navegadores usam para reduzir os dados que trocam entre si, e o Node.js traz sua própria cópia do decodificador Brotli do Google. Segundo o comunicado de segurança do Node.js, dados comprimidos malformados fazem o decodificador escrever além do fim de um buffer interno, o que pode derrubar a aplicação, vazar o conteúdo da sua memória ou permitir que um invasor execute código. O comunicado credita à equipe Codex Security da OpenAI o relato da falha, e a mesma versão corrigiu 10 vulnerabilidades no total, 4 delas de gravidade alta.

Depois, tudo andou rápido. Em 22 de outubro, um dia após a correção, o Red Team da Imperva executou código na imagem oficial do Node.js 24.22.0 por dois caminhos do dia a dia: a função fetch() nativa e os corpos de requisição tratados pelo Express 5. Em 26 de outubro, a ELLIO registrou tráfego real de exploração carregando código de ataque público. Em 27 de outubro, a CISA incluiu a falha em seu catálogo de vulnerabilidades exploradas ativamente.

O defeito em si é antigo. Segundo o registro CVE, ele afeta as versões 1.0.3 a 1.2.0 do Brotli, e a OpenAI diz que a causa raiz havia sido corrigida no código-fonte do Brotli em fevereiro de 2026, sem que ninguém soubesse que era uma falha de segurança e sem uma nova versão, até o lançamento do Brotli 1.2.1 em 21 de outubro. Se isso soa familiar, é porque é: na semana passada falamos do PHP2Shell, a falha que abriu servidores PHP e WordPress. O Node2Shell é o mesmo tipo de risco para aplicações feitas em JavaScript.

Meu aplicativo foi afetado?

O Node.js roda a parte de servidor de boa parte dos sites modernos, dos backends de aplicativos móveis, dos painéis e das APIs. Se o seu sistema foi desenvolvido nos últimos anos por uma agência ou por um desenvolvedor freelancer, há boas chances de ele rodar em Node.js sem que você saiba. As linhas afetadas são 22.x, 24.x e 26.x anteriores às versões corrigidas, além das linhas sem suporte 20.x, 23.x e 25.x, que, segundo o projeto Node.js, são sempre afetadas e não receberão correção.

Rodar Node.js, por si só, não significa estar exposto: algo precisa entregar os dados do invasor ao decodificador. Os pesquisadores apontam três caminhos comuns:

  • Requisições comprimidas chegando. Os leitores de corpo de requisição do Express 5, do body-parser 2 e do Koa descomprimem automaticamente corpos em formato Brotli, antes mesmo de o seu próprio código rodar.
  • Conteúdo que o seu servidor busca. Se o seu aplicativo abre links externos, como pré-visualizações de links, webhooks, crawlers ou agentes de IA que leem páginas da web, um site hostil pode responder com dados comprimidos envenenados. A função fetch() nativa do Node, o axios e as requisições do lado do servidor em frameworks como o Next.js os descomprimem automaticamente.
  • Arquivos enviados pelos usuários. Qualquer código que descomprima dados Brotli fornecidos por um cliente ou visitante.

O risco vai além do Node.js. O alerta da NCA cita também Python, Bun e Envoy, e a Microsoft lançou em 25 de outubro correções para o .NET 8, 9, 10 e 11, o Visual Studio 2019, 2022 e 2026 e o PowerShell 7.4 a 7.6, classificando a falha como crítica para o .NET com a avaliação “Exploitation More Likely”. A Microsoft observa que a descompressão Brotli não vem ativada por padrão no .NET, então só ficam expostos os aplicativos que a ativaram.

Se o seu site está hospedado na Vercel, a empresa diz em seu comunicado que implantou regras de firewall bloqueando o caminho de ataque de entrada para todos os projetos no mesmo dia em que o Node.js publicou a correção, e que todas as novas implantações usam um Node.js corrigido desde 28 de outubro. Projetos existentes precisam de uma nova implantação, e os que ainda estão no Node.js 20 devem migrar para o 22 ou o 24.

O que fazer hoje: cinco passos

  1. Faça uma pergunta por escrito. Qual versão do Node.js roda nos nossos servidores e dentro das nossas imagens Docker? Peça ao seu desenvolvedor para conferir o número da versão do Node.js com o comando node -v. Não confie no número de versão do Brotli: a ELLIO constatou que ele mostra 1.2.0 tanto nas versões corrigidas quanto nas vulneráveis.
  2. Atualize para uma versão corrigida. 22.23.4, 24.22.1 ou 26.12.1. Se você está na 20.x, 23.x ou 25.x, migre para uma linha com suporte, como a 22 ou a 24, e teste antes de colocar no ar.
  3. Reconstrua e reinicie. Um processo em execução mantém o código antigo. Reconstrua as imagens de contêiner sobre uma imagem base corrigida, porque um Dockerfile fixado na 24.22.0 continuará entregando a versão vulnerável até alguém alterar essa linha. Verifique também servidores de homologação, pipelines de build e funções serverless.
  4. Atualize as outras cópias. Os pacotes Python Brotli e brotlicffi (versões 1.2.1 e 1.2.1.0), o Bun, o Envoy, a biblioteca Brotli da sua distribuição Linux e o .NET, pela atualização da Microsoft de 25 de outubro.
  5. Verifique logs e arquivos de despejo. Procure requisições comprimidas em Brotli anormalmente grandes e quedas repetidas de processos. A ELLIO alerta que a maioria dos ataques fracassados derruba o processo e que um arquivo de despejo pode guardar cookies de sessão e chaves dos visitantes, então limite quem pode ler esses arquivos (core dumps) e por quanto tempo você os guarda.

Se você não puder atualizar hoje

Como medida temporária, bloqueie no seu servidor de entrada ou firewall as requisições que trazem o cabeçalho Content-Encoding: br, se o seu aplicativo não precisar delas. A Vercel e a Imperva adicionaram regras de firewall para essa falha, mas a própria Vercel ressalta que um firewall não cobre as respostas que o seu servidor busca em outros sites: só a atualização do Node.js fecha esse caminho. Trate qualquer camada de proteção como tempo extra, não como substituta da atualização.

A visão da Origami

Duas falhas críticas nos alicerces da web em um único mês, PHP2Shell e depois Node2Shell, contam uma história clara: o código que a sua equipe escreveu pode estar correto enquanto o ambiente de execução por baixo dele está aberto. A correção do Node2Shell ficou cerca de oito meses no código-fonte do Brotli antes que alguém entendesse que era um problema de segurança, e, depois que os detalhes vieram a público, os pesquisadores precisaram de um dia para executar código em uma versão oficial. O que vemos em muitas empresas é um aplicativo entregue anos atrás, sem ninguém responsável pelas atualizações e sem uma lista de onde o Node.js realmente roda. Se esse é o seu caso, comece essa lista hoje. Na Origami, desenvolvemos aplicativos web e sistemas, muitos deles em Node.js e Next.js, e acompanhamos as atualizações do ambiente deles desde o primeiro dia. Se quiser que revisemos o seu aplicativo ou atualizemos o Node.js sem interrupção, fale conosco.

Fontes