Node2Shell: corrigir o servidor não basta se o cliente também descomprime Brotli

A Imperva demonstrou execução de código com dados Brotli maliciosos no Node.js 24.22.0 oficial para Linux arm64, explorando a CVE-2026-111497.[3] A versão corrigida 24.22.1 rejeitou os mesmos dados sem executar código, segundo a reportagem.[3] Para quem opera aplicações JavaScript, o ponto importante é localizar o runtime efetivo e todas as entradas que chegam ao descompressor.

O que muda para quem desenvolve

O caminho vulnerável pode receber respostas HTTP pelo fetch() nativo ou corpos de requisição processados por middleware de descompressão.[3] Isso coloca a aplicação nos dois lados da fronteira: ela recebe tráfego como servidor e busca conteúdo como cliente.

Minha análise é que uma revisão limitada ao endpoint público fica incompleta. Inclua integrações, tarefas agendadas e componentes de renderização que consultam serviços externos. A pergunta não é apenas quem consegue chamar a aplicação, mas também de quem ela aceita respostas.

A demonstração exigiu várias tentativas, não foi determinística e se concentrou naquela combinação de versão, arquitetura e aplicação.[3] As linhas 22.x, 24.x e 26.x aparecem no escopo da vulnerabilidade, mas a demonstração não testou todas essas combinações.[3] Não confunda alcance do defeito com alcance comprovado de um exploit específico.

Como aplicar

Faça o inventário do binário embarcado em cada imagem, não apenas das dependências npm declaradas. Registre versão, arquitetura, imagem-base e destino do deployment. Depois, associe cada serviço aos caminhos de entrada Brotli que utiliza.

A recomendação da reportagem é atualizar o runtime e reconstruir imagens e produtos que incluem seu próprio Node.[3] No processo de entrega, confira que a imagem nova substituiu todas as instâncias, inclusive workers menos visíveis.

Um teste de regressão seguro pode usar um servidor controlado retornando respostas Brotli benignas e respostas deliberadamente inválidas, sem reproduzir o exploit. Verifique sucesso no caso válido e tratamento explícito de erro no inválido. O objetivo é testar a integração após o upgrade, não declarar que a ausência de crash comprova imunidade.

Mantenha a política de saída no desenho da mitigação: bloquear requisições recebidas não deve encerrar a análise de chamadas externas.

Cuidados e limites

Até 22 de outubro, não havia relato de exploração real na matéria.[3] Ela também não apresenta solução alternativa dentro do runtime e observa que proteção de WAF para requisições não cobre automaticamente respostas buscadas em outros servidores.[3]

Filtros temporários podem reduzir exposição, mas precisam ser documentados por direção de tráfego e serviço protegido. Atualizar somente pacotes npm, sem substituir o runtime vulnerável, deixa a correção essencial fora da entrega.

Fonte

[3] Fonte: The Hacker News