Em 3 de novembro de 2026, o projeto Node.js avisou que vai publicar novas versões das linhas 26.x, 24.x e 22.x "em ou logo após" quarta-feira, 11 de novembro. O aviso classifica como alta a falha mais grave corrigida em cada uma das três linhas. Os detalhes técnicos só saem junto com as versões, como é praxe no projeto.
O próprio comunicado lembra que versões fora de suporte são sempre afetadas quando há uma release de segurança. Elas não recebem a correção.
Quais versões recebem a correção
Pelo calendário oficial, consolidado no endoflife.date, a situação das linhas mais usadas hoje é esta:
Linha | Situação em novembro de 2026 | Fim das correções |
|---|---|---|
Node 26 | LTS ativo desde 28 de outubro | 30 de abril de 2029 |
Node 24 | LTS em manutenção desde 20 de outubro | 30 de abril de 2028 |
Node 22 | LTS em manutenção | 30 de abril de 2027 |
Node 25 | fora de suporte desde 1º de junho de 2026 | sem correção |
Node 20 | fora de suporte desde 30 de abril de 2026 | sem correção |
Quem está em 22, 24 ou 26 recebe uma versão de correção dentro da mesma linha, o que costuma ser uma atualização pequena. Quem ainda roda Node 20, ou ficou na 25 depois do fim dela em junho, não recebe nada em 11 de novembro: a falha continua aberta até a aplicação mudar de linha.
Esta é a segunda release de segurança em três semanas. A de 21 de outubro corrigiu, entre outras, uma falha alta em que dns.resolve*() truncava nomes com caractere NUL (CVE-2026-105482) e duas falhas altas na verificação de nome do certificado TLS para endereços IP escritos de forma não canônica (CVE-2026-105483 e CVE-2026-106069). O aviso de novembro não diz se as novas falhas têm relação com essas.
Quem precisa se mexer
Qualquer aplicação que execute Node.js em produção: APIs, workers de fila, renderização no servidor de frameworks como Next.js e Astro, e também o pipeline de build, que roda Node mesmo quando o site final é estático. O risco real depende de qual módulo foi afetado, o que ainda não foi divulgado.
Em plataforma gerenciada, quem atualiza o runtime é o provedor. Vale confirmar na documentação dele quando a versão corrigida fica disponível e se a troca é automática ou exige novo deploy. Em imagem Docker própria, a correção só chega quando a imagem é reconstruída a partir de uma tag atualizada; uma imagem antiga em execução continua com o binário antigo.
O que fazer antes de 11 de novembro
Até a próxima quarta, a tarefa é saber onde está cada versão e garantir que uma atualização de patch consiga ir para produção em um ou dois dias:
- levantar a versão de Node em cada serviço, olhando
.nvmrc, campoenginesdopackage.json,FROMdos Dockerfiles, configuração do CI e do provedor; - confirmar que o pipeline reconstrói imagens e roda os testes sem intervenção manual;
- reservar uma janela em 11 ou 12 de novembro para aplicar as versões novas, depois de ler o comunicado completo.
Para quem está em Node 20 ou 25, a decisão é outra: atualizar o patch não resolve, e a migração para 24 ou 26 passa a ter prazo. Escrevi sobre por que uma versão suportada ainda exige uma decisão de migração. Nas linhas 20 e 25 o adiamento já tem custo, porque cada release de segurança torna pública mais uma falha que não será corrigida nelas.
O que ainda não se sabe
O aviso não informa quantas falhas são, quais módulos atingem, se há CVE atribuído nem se alguma está sendo explorada. Também não diz se a release inclui atualização de dependências embutidas, como OpenSSL ou Undici, o que aconteceu em outubro. A data pode escorregar, porque o texto diz "em ou logo após" 11 de novembro. Em outubro, o próprio comunicado foi atualizado com a lista de falhas quando as versões saíram, então é ali que os detalhes devem aparecer.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
