Node.js corrige 10 falhas de segurança: o que fazer

Em resumo

Em 21 de outubro de 2026, o Node.js lançou correções de segurança para 10 falhas nas linhas 22, 24 e 26. A mais grave, a CVE-2026-111497, está no decodificador Brotli embutido e pode levar à execução de código a partir de dados comprimidos enviados por um atacante. As outras incluem falhas na checagem de certificados TLS e na resolução de DNS. A correção é atualizar para o Node.js 22.23.4, 24.22.1 ou 26.12.1, inclusive dentro das imagens de container.

O que aconteceu

Na quarta-feira, 21 de outubro, o Node.js publicou as versões 22.23.4, 24.22.1 e 26.12.1. Elas fecham 10 falhas: quatro de gravidade alta, três média e três baixa. Versões fora do suporte, como a 20 e anteriores, também têm as falhas e não recebem correção.

A mesma rodada atualiza componentes que vêm dentro do Node.js, como o c-ares, o OpenSSL, o SQLite e o Undici, e retira a confiança nos certificados intermediários da eMudhra, cujas chaves privadas eram fracas o bastante para serem calculadas. É o mesmo incidente que levou às versões de emergência do Python.

A falha do Brotli

O Brotli é um formato de compressão criado pelo Google e usado na web com o cabeçalho Content-Encoding: br. O Node.js traz o decodificador do Brotli dentro do módulo node:zlib. Com um fluxo comprimido montado de propósito, o decodificador grava além de um espaço interno de oito bytes. O resultado, segundo o aviso do Node.js, pode ser o processo travar, vazar memória ou executar código do atacante. A falha foi relatada por pesquisadores do Codex Security, da OpenAI, e está na biblioteca do Google, que também foi corrigida.

Nesta quinta-feira, 22, a Imperva batizou a falha de Node2Shell, um apelido no estilo do PHP2Shell. Ela mostrou a execução de código na imagem oficial do Node.js 24.22.0, em Linux arm64, sem depurador nem binário modificado. O ataque não deu certo em toda tentativa, e o Node.js 24.22.1 recusou os mesmos dados. Até 22 de outubro, não havia relato de ataques fora de laboratório.

Quem fica exposto

A falha está no Node.js, mas só aparece quando dados Brotli vindos de fora chegam ao decodificador. A Imperva confirmou estes caminhos:

O fetch() nativo do Node.js. Ele descomprime a resposta em Brotli. Uma aplicação que chama um servidor sob controle do atacante fica exposta: webhooks, prévia de links, integração com APIs de terceiros, qualquer URL que o usuário possa informar.
Express 5 com body-parser 2. O express.json() e o express.raw() descomprimem o corpo da requisição em Brotli. Nos testes, com Express 5.0.0 a 5.3.0 e body-parser 2.0.0 a 2.3.0, bastou um POST com Content-Encoding: br.

O servidor HTTP do Node.js, sem nada por cima, não descomprime o corpo das requisições sozinho. O Express 4 usa o body-parser 1, que descomprime só gzip e deflate. Fastify, Koa e NestJS não entraram nos testes: se a sua aplicação usa um deles, confira se algum middleware descomprime Brotli. E todo código que chama zlib.brotliDecompress() ou zlib.createBrotliDecompress() com dados de fora está exposto.

As outras falhas

Checagem de certificado TLS (duas altas e uma média). Endereços IP escritos de formas incomuns, como 0127.0.0.1, 127.1 ou com dígitos de largura total, faziam o Node.js aceitar um certificado que não valia para o endereço conectado. Importa para quem conecta por IP a serviços internos com TLS.
DNS (alta). Um nome com o caractere nulo era cortado no meio pelo dns.resolve(). Uma aplicação que valida o nome e depois o resolve podia agir sobre o domínio errado, o que fura listas de domínios permitidos.
Conexões reaproveitadas (média). Com o processo ocupado, uma resposta enviada antes da requisição podia ser entregue a uma requisição nova.
Números aleatórios repetidos (média). O crypto.randomUUID() e o crypto.randomInt() repetiam valores em aplicações empacotadas num executável único (SEA) ou iniciadas a partir de snapshot, quando já tinham sido chamados antes de o pacote ser gerado.
Três de gravidade baixa, no modelo de permissões e na leitura de arquivos ZIP.

Como verificar

Confira a versão em cada servidor e dentro de cada imagem de container:

node --version
docker run --rm sua-imagem node --version

Para saber se a aplicação usa Express 5 e body-parser 2, rode npm ls express body-parser na pasta do projeto.

O que fazer

Atualize o Node.js para 22.23.4, 24.22.1 ou 26.12.1, pelo gerenciador que você usa (nvm, NodeSource, pacote oficial). No Docker, troque a tag da imagem base pela versão corrigida, por exemplo node:24.22.1-slim, reconstrua e suba os containers de novo.
Procure os Node.js escondidos. Imagens de container, executáveis únicos (SEA) e ferramentas que embutem o próprio Node.js não mudam quando você atualiza o servidor. Cada um precisa ser reconstruído.
Saia das versões sem suporte. Quem está no Node.js 20 ou anterior não tem correção. A saída é migrar para uma das linhas com suporte.
Se não dá para atualizar hoje, recuse no proxy as requisições com corpo em Brotli. No Nginx, dentro do bloco server:

if ($http_content_encoding ~* "br") {
    return 415;
}

Isso protege o lado servidor. Para o fetch() não há contorno simples: um servidor malicioso pode responder em Brotli mesmo que a aplicação não peça. Nesse caso, atualizar é a saída.

Próximos passos

Se você mantém aplicações em Node.js e quer ajuda para atualizar sem susto, fale com a gente sobre desenvolvimento web sob medida. Para manter servidores e imagens em dia, veja a nossa gestão de servidores.