10 vulnerabilidades CVE no Node.js, uma vulnerabilidade de execução remota de código (RCE) no Brotli e o que fazer se a sua versão estiver no fim do ciclo de vida (EOL)

A versão resumida

Ir para a versão completa ↓

O que aconteceu: Em 21 de outubro de 2026, o Node.js lançou atualizações de segurança para suas três versões suportadas, 22.x, 24.x e 26.x, uma semana após um pré-alerta. Dez CVEs, quatro deles classificados como “Alto”. Ir para esta seção →

O que a vulnerabilidade mais grave causa: a CVE-2026-111497 é uma gravação fora dos limites no decodificador Brotli integrado ao Node.js, e o comunicado indica que ela permite a execução remota de código. Qualquer processo em uma versão sem patch que descompacte dados Brotli controlados por um invasor fica exposto, e não é necessário que seu código chame o Brotli diretamente para que isso aconteça. Ir para esta seção →

Qual é realmente a gravidade da situação: A primeira demonstração pública de conceito só conseguiu executar o código em uma versão deliberadamente enfraquecida, o que fez com que a situação parecesse menos urgente do que o tom do comunicado. Em seguida, a equipe de testes de penetração da Imperva publicou Node2Shell, demonstrando a execução de código na imagem oficial do Node.js 24.22.0 por meio de fetch() e a análise de solicitações do Express 5. Até o dia 22 de outubro, não havia relatos de exploração dessa vulnerabilidade em ambiente real. Ir para esta seção →

Quem é afetado: Qualquer versão 22.x, 24.x ou 26.x mais antiga do que a versão corrigida para sua linha, além das linhas em fim de vida útil para as quais o Node.js não oferece mais correções. A tabela de CVEs mais adiante mostra quais CVEs afetam cada linha. O comunicado reitera seu aviso constante de que as versões em fim de vida útil são sempre afetadas, e que o Node.js 20, 18, 16, 14 e 12 não recebem atualizações do desenvolvedor original. Ir para esta seção →

Situação atual: já foram lançadas correções no upstream para as versões 22, 24 e 26. O WAF da Vercel bloqueia a rota de ataque de entrada para projetos em sua plataforma, mas não abrange as respostas que seu código obtém de outras fontes. Espera-se que as compilações do ELS para Runtimes destinadas às linhas afetadas que chegaram ao fim da vida útil sejam disponibilizadas nas próximas 24 a 48 horas.

O que fazer hoje: aplique as correções nas linhas compatíveis, transfira as que estão no fim do ciclo de vida para uma versão fixa do ELS assim que a versão correspondente à sua linha for lançada e reinicie tudo, pois um processo em execução mantém o decodificador antigo na memória. Para ver o que está em execução no momento:

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

Ir para esta seção →

A maior parte do trabalho de segurança do Node.js ocorre em uma camada acima. O Dependabot abre uma solicitação de pull, npm audit Tudo fica em silêncio, e ninguém dedica nem um segundo a pensar no código binário no qual tudo funciona. O ambiente de execução, porém, tem suas próprias vulnerabilidades (CVEs) e, em 21 de outubro, a pior delas acabou sendo uma corrupção de memória em um decodificador que seu aplicativo pode estar alimentando diretamente da internet.

Nos dias 22, 24 ou 26, a correção é sem graça. Aumentem a versão do patch, atualizem a frota e sigam em frente.

A situação fica bem menos entediante quando parte da infraestrutura ainda está no Node.js 18 ou 20 — seja porque um complemento nativo não compila em versões mais recentes, seja porque a migração de uma estrutura de trabalho fica sendo adiada a cada trimestre. Essas linhas de código incluem um decodificador Brotli anterior à correção e não recebem nenhum dos patches. A maior parte deste post trata dessa lacuna.

O projeto deu seu aviso prévio habitual de uma semana. Em 14 de outubro, Antoine du Hamel publicou um pré-alerta na lista oss-security informando que as novas versões 22, 24 e 26 seriam lançadas em 21 de outubro ou logo depois, com a gravidade mais alta classificada como “Alta”. Não foram divulgados nomes de componentes nem números CVE, o que é normal para o Node.js. Os lançamentos ocorreram dentro do prazo previsto.

CVE-2026-111497 é o título. O comunicado atribui a autoria do relatório a Khai Tran e Sylvie Mayer, da OpenAI Codex Security, e a correção a Matteo Collina e Antoine du Hamel. Algumas matérias iniciais afirmavam que Collina havia descoberto a vulnerabilidade, mas o comunicado o coloca entre os responsáveis pela correção. O patch em si é uma seleção específica do commit 0ed4268a do Brotli upstream, que traz a mensagem bastante discreta: “Detectar e relatar fluxos inválidos mais cedo”.

O momento dessa atualização é estranho. De acordo com o The Hacker News, a alteração foi incorporada ao código-fonte do Brotli pela primeira vez em fevereiro de 2026, mas só foi incluída em uma versão de segurança em 21 de outubro, quando foram lançadas as versões 1.2.1, 1.1.1 e 1.0.10 do Brotli. Portanto, uma correção para um bug de segurança de memória ficou em um repositório público por meses, e o crédito pela descoberta foi atribuído a uma ferramenta de segurança baseada em IA. É de se esperar que essa combinação se torne cada vez mais comum, e que o tempo entre um commit não anunciado no upstream e uma exploração funcional continue diminuindo.

As outras três vulnerabilidades de alta gravidade estão todas relacionadas ao tratamento de nomes. A CVE-2026-106069 permite que um certificado TLS seja aprovado na verificação do nome do host quando o host é resolvido de forma imprecisa para um endereço IP. A CVE-2026-105483 é uma vulnerabilidade separada que funciona quando o IP é escrito com dígitos de largura total. Essa vulnerabilidade afeta apenas as versões 24.x e 26.x, e o site The Hacker News destaca que o commit que a corrige descreve o bug como de gravidade baixa e difícil de explorar, embora o comunicado de segurança o classifique como de gravidade alta. A CVE-2026-105482 está em dns.resolve(), onde um nome que contivesse um byte NUL poderia ser truncado, de modo que o nome validado pelo seu código e o nome efetivamente consultado não fossem os mesmos. As versões corrigidas rejeitam imediatamente os bytes NUL na entrada do resolvedor.

Os itens das categorias “Médio” e “Baixo” são mais restritos, mas não por isso menos relevantes. Um que vale a pena destacar para quem distribui CLIs ou ferramentas como aplicativos executáveis únicos é o CVE-2026-106074. Os caches de entropia por trás de crypto.randomUUID() e crypto.randomInt() estavam sendo salvos em instantâneos de inicialização e SEAs, de modo que cada processo iniciado a partir do mesmo binário produzia os mesmos valores “aleatórios”. Qualquer coisa que utilize esses UUIDs como tokens ou nonces merece uma análise.

As versões também atualizam o c-ares, o undici e os certificados CA incluídos nas três linhas, o OpenSSL nas versões 22.x e 24.x, e o SQLite na versão 22.x. A alteração nos certificados é o ponto mais importante. O Node.js usa a lista raiz da Mozilla, mas não realiza verificação de revogação por padrão; assim, as cadeias construídas com base nos oito certificados intermediários da eMudhra que foram relatados como comprometidos neste mês continuaram sendo validadas até esta versão. As compilações corrigidas incluem uma lista de bloqueio compilada com essas chaves, os mesmos hashes que a Go forneceu em sua própria correção. Há duas ressalvas. As sessões TLS retomadas antes da atualização não são verificadas novamente até que atinjam o tempo limite, e as linhas em fim de vida útil não recebem o bloqueio de forma alguma.

O Node.js não decodifica o Brotli por conta própria. Alguma parte do seu processo precisa solicitar essa decodificação, e muitas coisas fazem isso sem que você perceba.

O tráfego de saída é o mais importante. O recurso integrado fetch() descompacta as respostas que contêm Content-Encoding: br automaticamente, e não há nenhuma opção disponível para o usuário desativar isso. As versões atuais do axios, node-fetch e got fazem o mesmo por padrão. Portanto, qualquer serviço que solicite URLs que não controla está sujeito a isso — um remetente de webhooks, um worker de visualização de links, um scraper, um agente de IA que extrai páginas da web para um prompt. O Vercel’s boletim acrescenta outra possibilidade que é fácil deixar passar despercebida. O Next.js auto-hospedado não bloqueia as respostas Brotli na otimização de imagens; portanto, a solução nesse caso é atualizar o Node.js, sem alterar a configuração do Next.js.

O Inbound é a segunda opção. Os analisadores de corpo do Express 5, por meio do body-parser 2.x, descompactam os corpos de solicitação Brotli por padrão; portanto, uma API que utilize express.json() descompactará um corpo Brotli que nunca solicitou. O analisador de corpo 1.x do Express 4 não suporta corpos Brotli e os rejeita com um código de erro 415. Um simples http O servidor não decodifica os corpos das solicitações simplesmente ao recebê-los. Depois, há a rota direta, na qual o código chama zlib.brotliDecompress() ou createBrotliDecompress() em uploads, arquivos ou artefatos armazenados em cache.

Uma maneira rápida de classificar a urgência. Qualquer coisa exposta à Internet no Express 5, ou qualquer coisa que acesse URLs arbitrárias, deve receber a correção ainda hoje. Um serviço do Express 4 que se comunique apenas com back-ends de sua propriedade, sem middleware de descompressão personalizado e sem acesso direto zlib O Brotli utiliza dados externos, por isso pode ficar um pouco mais abaixo na lista. Ele ainda precisa da atualização desta semana, pois as outras nove vulnerabilidades (CVEs) não dependem da versão do Express que você estiver executando. O comunicado não oferece nenhuma solução alternativa. Configuração inflate: false sobre analisadores de corpo de mensagem, desativar a descompressão no Axios ou Got, ou rejeitar Content-Encoding: br no proxy pode reduzir a exposição por algumas horas, mas fetch() não tem botão de desligar e nenhuma dessas medidas resolve o problema.

A história sobre a gravidade do problema se espalhou rapidamente. Uma prova de conceito pública foi divulgada em 22 de outubro e, segundo o The Hacker News, ela resultou em execução de código apenas em uma versão de teste deliberadamente enfraquecida. Em uma versão padrão, o autor relatou uma falha no sistema e uma leitura limitada de memória. Teria sido fácil ler isso e adiar o ticket para o próximo sprint.

No mesmo dia, a equipe de testes de invasão da Imperva publicou Node2Shell. Em ambientes novos executando a imagem oficial do Node.js 24.22.0 para Linux arm64, sem depurador e sem binário instrumentado, os dados Brotli enviados como resposta recebida ou como corpo da solicitação faziam com que o aplicativo executasse o código fornecido junto com esses dados. Eles reproduziram a falha por meio de fetch() e nas versões do Express de 5.0.0 a 5.3.0 com o raw() e json() analisadores sintáticos. As mesmas entradas foram rejeitadas pelo endereço 24.22.1. Foram necessárias várias tentativas na configuração deles, e eles testaram apenas a arquitetura arm64; portanto, não é algo que se faça com o simples toque de um botão — mas está muito longe de ser algo que “só funciona em laboratório”.

Se a triagem tiver arquivado este caso com base na primeira prova de conceito, reabra-o. A Imperva também observa que encerramentos inesperados de processos durante a descompressão podem ajudar a priorizar a investigação, embora nem as falhas de sistema nem os erros do decodificador sejam, por si só, um indício confiável de exploração. Até 22 de outubro, nenhuma exploração em ambiente real havia sido relatada, e o CVE-2026-111497 não consta no catálogo de Vulnerabilidades Exploradas Conhecidas da CISA.

As linhas a montante não se tocam

Os alertas de segurança do Node.js trazem um aviso constante, e este aqui o repete. As versões em fim de vida útil são sempre afetadas quando ocorre uma atualização de segurança. Trata-se de uma declaração de política, não de um resultado de teste específico por CVE. O que é certo é que a correção do Brotli só foi incorporada ao Node.js em 21 de outubro; portanto, nenhuma versão upstream em fim de vida útil a inclui. O Node.js 20 atingiu o fim de vida útil em 30 de abril de 2026, o 18 em 30 de abril de 2025, o 16 em 11 de setembro de 2023, o 14 em 30 de abril de 2023 e o 12 em 30 de abril de 2022. Nenhuma dessas versões receberá uma versão para corrigir isso. A Vercel também foi direta quanto a isso. Os projetos em sua plataforma que ainda estão fixados no Node.js 20 precisam mudar para a versão 22 ou 24 e ser reimplantados, pois a versão 20 não receberá a correção.

Desde quando existe essa falha no Brotli? O Brotli já vem integrado ao Node.js desde as versões 10.x e 11.x, e o projeto Brotli aplicou essa correção retroativamente até o ramo 1.0. Isso é um forte indício de que a lógica do decodificador vulnerável é antiga, e não algo introduzido na primavera passada. O Node.js 16 e versões anteriores não possuem uma variável global fetch(), mas o Axios e o Got ainda enviam respostas Brotli para o mesmo decodificador zlib, e diretamente zlib As chamadas funcionam da mesma forma em todas as linhas.

As instalações que causam problemas raramente são aquelas que as pessoas imaginam como servidores Node.js. Um contêiner de compilação fixado no Node 16 porque um complemento de processamento de imagens parou de compilar na versão 18. Uma ferramenta interna de administração que alguém distribuiu como um único binário em 2022. Um dispositivo de um fornecedor com o Node 14 em seu console web. Imagine uma equipe de pagamentos com 40 serviços no Node 18, presos nessa versão por causa de uma dependência cujo mantenedor já não está mais no projeto, lendo um aviso de RCE sem nenhum patch disponível. Ninguém vai migrar 40 serviços até sexta-feira.

É essa lacuna que o ELS para Runtimes preenche. A TuxCare fornece correções de segurança para versões do Node.js que chegaram ao fim da vida útil; assim, assim que a compilação da linha for lançada, um serviço fixado na versão 18 recebe as correções deste mês como uma atualização de pacote, em vez de uma migração de emergência. A migração ainda precisa ocorrer, e as datas de fim de vida útil do Node.js não mudam. Com o ELS, ela ocorre de acordo com um cronograma escolhido pela sua equipe, e não com um cronograma imposto por um comunicado de segurança.

A documentação do ELS para Runtimes lista as versões do Node.js de 12 a 26 por sistema operacional, com outras versões e arquiteturas disponíveis mediante solicitação. Para uma análise mais aprofundada sobre como continuar utilizando o Node.js após o fim do ciclo de vida ( EOL), consulte este guia sobre o suporte estendido ao Node.js após o EOL.

Veja a seguir o que a documentação indica, no momento, como estando sob suporte ativo:

As compilações estão disponíveis para x86_64 em todos os sistemas operacionais compatíveis e para aarch64 (arm64) no Debian 12, Debian 13 e Alpine 3.23 e versões posteriores. As compilações para arm64 são importantes nesta semana, já que a demonstração de execução de código da Imperva foi executada em arm64.

Os pacotes de distribuição funcionam de maneira um pouco diferente. Algumas compilações, incluindo os pacotes do Debian e do Ubuntu e o Homebrew, vinculam uma biblioteca Brotli compartilhada em vez da cópia incluída no Node.js. Nesse caso, acompanhe as atualizações de segurança da biblioteca Brotli fornecida pelo seu gerenciador de pacotes. Para verificar, basta uma linha:

ldd "$(command -v node)" | grep -i brotli

A presença de “libbrotli” na saída indica que o binário está vinculado a uma biblioteca Brotli compartilhada. A ausência dessa correspondência sugere uma cópia integrada ou vinculada estaticamente, que é como as compilações oficiais do nodejs.org são distribuídas; no entanto, o comando por si só não pode comprovar isso, portanto, verifique as informações do pacote ou a configuração da compilação, caso seja relevante. ldd é exclusivo para Linux. No macOS, onde o Homebrew está instalado, otool -L "$(command -v node)" | grep -i brotli faz a mesma coisa.

Adquira hoje mesmo o ELS para Runtimes →

Comece pelo inventário, pois a lista é sempre mais longa do que o esperado. Gerenciadores de versões como o nvm e o Volta armazenam os binários nos diretórios pessoais, enquanto os pacotes de distribuição os colocam em /usr/bin, e as compilações do ELS são feitas em /opt/alt/ com um script de ativação para cada versão. Esses dois loops do Bash exibem cada node no seu PATH atual, então todas as compilações do ELS localizadas em /opt/alt/, com a versão informada por cada um:

type -ap node | while read -r n; do echo "$n $("$n" -v)"; done
for e in /opt/alt/alt-nodejs*/enable; do [ -f "$e" ] && ( . "$e" && echo "$e $(node -v)" ); done

Isso fornece um inventário inicial, que não é o mesmo que o executado por cada serviço. As unidades do systemd, as configurações do PM2, os executores de CI e as imagens base de contêineres podem apontar, cada um, para um binário diferente; portanto, verifique-os também. Em sistemas baseados em RPM, as compilações do ELS são atualizadas com yum update 'alt-nodejs*', e as instruções sobre DEB e APK estão na mesma página de documentação.

Não confie nas sequências de versão para a correção do Brotli nas compilações do upstream. O Node.js selecionou o patch sem aumentar a versão do Brotli, portanto, process.versions.brotli parece idêntico antes e depois. A versão revelou uma nova constante do zlib que os binários corrigidos do upstream possuem e os não corrigidos não:

node -p "'BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH' in require('zlib').constants"

true significa que o decodificador fixo está presente. Essa verificação é confiável apenas para compilações oficiais do upstream; portanto, para compilações de distribuição ou do ELS, siga as orientações do fornecedor. O próprio projeto npx is-my-node-vulnerable também é útil para instalações do upstream, mas funciona com base nos números de versão; por isso, uma compilação adaptada para versões anteriores pode parecer vulnerável quando, na verdade, não é.

Em seguida, reinicie, que é a etapa que acaba sendo pulada. Um processo do Node.js em execução mantém o decodificador antigo até ser encerrado, e um contêiner o mantém até ser reimplantado a partir de uma imagem recompilada com base em uma versão corrigida. Os SEAs e os snapshots de inicialização precisam ser recompilados com o ambiente de execução corrigido e, no caso do CVE-2026-106074, essa recompilação constitui a correção. Execute novamente o ps Execute o comando indicado no início desta postagem e confirme todos os processos do Node.js iniciados após a atualização ter sido aplicada. Aplicativos executáveis únicos e binários renomeados não aparecerão nesse padrão; portanto, verifique-os pelo nome do serviço.

Por fim, não encerre o ticket com base na comparação de versões feita por um scanner. Uma compilação retroportada ainda pode indicar sua versão original do upstream. Quando suas ferramentas permitirem, forneça a elas os dados de segurança legíveis por máquina da TuxCare para o Node.js — que incluem alertas CSAF — e mantenha um registro do pacote instalado, do alerta ao qual ele se refere e do processo que está efetivamente atendendo ao tráfego. É isso que um auditor irá solicitar.

Por que uma falha de tempo de execução tem um impacto diferente

Um runtime também é uma dependência e, quando ninguém mais lança correções para ele, toda nova vulnerabilidade no núcleo permanece sem correção enquanto esse runtime continuar em produção. Equipes que jamais lançariam uma versão do lodash com dois anos de idade executam alegremente seu código em uma versão do Node.js que deixou de receber correções de segurança em 2025.

Esta semana também mostrou quão pouco tempo há para planejar. Sete dias desde o pré-alerta até o lançamento, uma demonstração pública do conceito no dia seguinte, uma vulnerabilidade funcional contra a imagem padrão ainda naquele mesmo dia e correções que abrangem exatamente três versões de lançamento. “Atualizar no próximo trimestre” é um plano perfeitamente válido para o próximo trimestre. Mas não é plano algum para esta semana.

Portanto, aplique as correções nas linhas compatíveis agora e reinicie o que precisar ser reiniciado. Quanto às linhas do Node.js que o upstream deixou para trás, transfira-as para uma compilação ELS corrigida assim que a versão correspondente à sua linha for lançada; enquanto isso, reduza a exposição delas a dados Brotli não confiáveis e, em seguida, programe a migração no calendário.

Adquira hoje mesmo o ELS para Runtimes →

Como esses eventos se desenrolaram

Fontes

As fontes desta publicação incluem o aviso de lançamento de segurança do Node.js de 21 de outubro de 2026, as notas de lançamento das versões 22.23.4 e 24.22.1, o pré-alerta no oss-security, o cronograma de lançamentos do Node.js, o commit de correção do google/brotli, a solicitação de pull da lista de bloqueio do eMudhra, o boletim de segurança da Vercel, a pesquisa Node2Shell da Imperva, a cobertura do The Hacker News, o catálogo KEV da CISA, o is-my-node-vulnerable e a documentação do ELS for Runtimes da TuxCare para o Node.js, além de dados de segurança legíveis por máquina.