Node.js corrige falha crítica de execução remota no Brotli e mais nove vulnerabilidades

O anúncio

O projeto Node.js↳Node.js45 conteúdosComo criar aplicações console em Node.jsDev (Back & Front) · fev 2025Entendendo o ciclo de publicação do Node.jsDev (Back & Front) · fev 2020Nodejs por baixo dos panosDev (Back & Front) · jul 2019Ver tudo em Dev (Back & Front) → lançou nesta quarta-feira (11/11) atualizações de segurança para as três linhas ativas do runtime (22.x, 24.x e 26.x), corrigindo dez vulnerabilidades. Uma delas é classificada como crítica: uma falha no decodificador de compactação Brotli que permite execução remota de código. As demais são de alta severidade e afetam áreas distintas do runtime, de resolução de DNS a verificação de certificados TLS.

Segundo o material da PaqSec sobre o lançamento, o aviso foi feito com antecedência justamente para dar tempo às equipes de planejarem a aplicação dos patches antes da entrega dos binários corrigidos. Um vídeo do compilado semanal Código Fonte TV, que cobre programação, tecnologia e cibersegurança↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps →, resume o motivo da antecipação:

O aviso foi antecipado justamente para buscar dar tempo, para que as equipes planejem a aplicação de patches contra falhas de alta severidade nas três branches das versões.

Compilado Código Fonte TV, episódio sobre segurança no Node.js

A falha crítica: CVE-2026-111497 no Brotli

O ponto mais grave do pacote é a CVE-2026-111497: um problema de escrita fora dos limites (out-of-bounds write) no decodificador Brotli, biblioteca de compactação usada internamente pelo Node.js. Esse tipo de falha de corrupção de memória pode travar o processo ou, no pior caso, abrir caminho para um invasor executar código arbitrário no servidor ou na máquina afetada.

O cenário não é inédito: em outubro, o projeto já havia corrigido uma falha semelhante no mesmo componente, apelidada informalmente de "Node to Shell" pelo vídeo do Código Fonte TV. Aquela vulnerabilidade também estava no decodificador Brotli, integrado ao módulo nativo zlib do Node.js, e também provocava corrupção de memória com potencial de execução remota de código. Na prática, isso significa que o Brotli virou, nos últimos dois meses, o componente mais visado das rodadas de segurança do runtime.

As outras nove vulnerabilidades

Além da falha no Brotli, o lote de correções cobre um conjunto variado de pontos do runtime, segundo o material da PaqSec:

• Bypass de domínios via truncamento em consultas DNS;
• Falhas na verificação de certificados TLS;
• Problemas no tratamento de conexões HTTP;
• Erros no processamento de arquivos ZIP;
• Falhas na checagem de permissões do sistema de arquivos.

O projeto não divulgou a contagem exata de falhas por componente, identificadores individuais (além da CVE da falha crítica) nem detalhes sobre métodos de ataque ou indícios de exploração ativa. A prática é comum em avisos de segurança: reter detalhes técnicos até que os binários corrigidos estejam disponíveis reduz a chance de alguém usar a informação para montar um exploit antes que o ecossistema tenha tempo de atualizar.

Versões corrigidas

As correções chegaram em uma versão por linha ativa, cada uma recebendo pelo menos a correção da vulnerabilidade grave relatada para sua branch:

Na estrutura de suporte atual do projeto, a linha 26.x opera como Active LTS, enquanto 24.x e 22.x seguem em modo de manutenção, recebendo apenas correções críticas como esta. Versões mais antigas, que já atingiram o fim de vida útil, não são contempladas: o projeto não faz backport de patches de segurança para branches fora de suporte.

Node não tem a complacência do PHP

O vídeo do Código Fonte TV traz uma comparação que vale o registro: ao discutir um incidente de gravidade parecida no ecossistema PHP, o apresentador lembra que a comunidade PHP optou por aplicar patches de segurança mesmo em versões antigas, dado o tamanho do problema. O Node.js, segundo o vídeo, não adota essa política: quem está em versão fora do ciclo de suporte simplesmente não recebe a correção, por mais crítica que ela seja.

Na prática, isso empurra o ônus da atualização para quem mantém a aplicação. Ficar numa versão EOL do Node.js não é só perder acesso a recursos novos: é rodar em produção sem rede de proteção contra falhas como a do Brotli, mesmo que ela seja de execução remota de código.

O que muda na prática para quem desenvolve

A recomendação direta é atualizar os ambientes de desenvolvimento e produção para 22.23.4, 24.22.1 ou 26.12.1, conforme a linha em uso, o quanto antes. Vale um lembrete sobre um detalhe que costuma passar batido: quem roda a aplicação em contêiner precisa atualizar a imagem base, não apenas redistribuir o mesmo artefato. Dar um novo deploy sem trocar a imagem do Node.js dentro do Dockerfile não resolve nada.

Vale também lembrar de quem usa Node.js sem saber: muita ferramenta de build, CLI ou ambiente de desenvolvimento roda sobre o runtime por baixo dos panos, mesmo quando o projeto principal está em outra stack. Checar a versão do node instalada localmente e nos pipelines de CI é parte do processo, não só nos servidores de produção.

O que ainda está em aberto

O projeto não divulgou a lista completa de CVEs além da falha crítica no Brotli, nem indicou se há exploração ativa das demais falhas de alta severidade. Isso significa que a avaliação de risco de cada equipe, por ora, precisa assumir o cenário mais conservador: tratar as nove vulnerabilidades restantes como potencialmente graves até que mais detalhes técnicos sejam publicados. O ideal é não esperar esse detalhamento para aplicar o patch.