O Node.js 20 não receberá nenhuma atualização em 11 de novembro de 2026. Os lançamentos de segurança cobrem apenas as versões 26.x, 24.x e 22.x, pois o Node.js 20 atingiu o fim da vida útil (End-of-Life) em 30 de abril de 2026. O último patch foi o 20.20.2, compilado em 24 de março. Desde então, foram lançadas 33 CVEs sem nenhuma build para a linha 20.x. Migre para o Node.js 24 ou 26 esta semana.
Essas CVEs vieram em três lançamentos de segurança que deixaram o Node.js 20 de fora. O quarto lançamento está a poucos dias de distância, e o pré-anúncio classifica a falha mais crítica como ALTA em todas as linhas com suporte ativo.
O que acontece em 11 de novembro e por que o Node.js 20 ficou de fora
O projeto Node.js lançará novas builds para as versões 26.x, 24.x e 22.x na quarta-feira, 11 de novembro de 2026, ou logo após essa data. Nenhum detalhe das CVEs é público até o momento, permanecendo em sigilo até que as builds sejam disponibilizadas. Nosso guia de contagem regressiva para o lançamento de novembro cobre o inventário de runtimes e os comandos para o dia da atualização, portanto este post não entrará nesses detalhes.
O Node.js 20 não está na lista porque o projeto encerrou sua manutenção. A página de End-of-Life é categórica: quando novos lançamentos de segurança revelam vulnerabilidades, “mesmo que a mesma vulnerabilidade afete linhas de lançamento em EOL, não haverá nenhum novo lançamento para elas”.
O comunicado traz mais uma frase essencial para você: “Versões que atingiram o fim da vida útil são sempre afetadas quando um lançamento de segurança acontece”.
O que o Node.js 20 já perdeu
Três lançamentos de segurança foram disponibilizados desde que o Node.js 20 atingiu o fim da vida útil. Nenhum deles contou com uma build para a linha 20.x.
| Comunicado | CVEs | Alta | Média | Baixa | Corrigido em |
|---|---|---|---|---|---|
| June 18, 2026 | 12 | 2 | 6 | 4 | 26.3.1, 24.17.0, 22.23.0 |
| July 29, 2026 | 11 | 3 | 5 | 3 | 26.5.1, 24.18.1, 22.23.2 |
| October 21, 2026 | 10 | 4 | 3 | 3 | 26.12.1, 24.22.1, 22.23.4 |
| Total | 33 | 9 | 14 | 10 | Nenhuma build 20.x |
O código afetado por essas correções é exatamente o que um servidor de API executa o dia inteiro:
- Validações de hostname no TLS. As versões de junho e outubro corrigiram brechas que permitiam a aceitação de certificados para o host incorreto.
- HTTP/2. As correções de alta gravidade de julho incluem uma falha de use-after-free no heap e um bug de esgotamento remoto de memória.
- DNS. Em outubro, corrigiu-se o truncamento de hostnames por
dns.resolve*()diante de um byte NUL, o que podia burlar listas de permissões (allowlists). - Compressão. Outubro corrigiu uma gravação fora dos limites (out-of-bounds write) no decodificador Brotli que podia levar à execução remota de código. Detalhamos o caso na análise de RCE no Brotli.
Leia essa lista com atenção. Como o projeto não avalia linhas que já atingiram o fim da vida útil, seus comunicados citam apenas as versões com suporte ativo. Alguns desses bugs estão em trechos de código que o Node.js 20 pode nem conter: uma CVE de outubro, por exemplo, é uma regressão que o projeto limitou exclusivamente às versões 26.x e 24.x. Portanto, o status real de cada CVE no Node.js 20 é não corrigido e não avaliado. Ninguém garantiu que seu ambiente está seguro, e ninguém vai verificar isso por você.
O encadeamento de falhas torna o cenário ainda mais crítico. A correção de DNS de outubro complementa um ajuste feito em junho, e uma correção de julho conclui outra de junho. Cada patch subsequente depende de uma correção que você simplesmente não tem.
“Mas ainda funciona”
Funciona. Esse é o problema.
Um runtime em fim de vida útil não para de funcionar de repente. O comando node -v exibe a mesma versão, seus testes passam e seus dashboards continuam verdes. O risco surge em locais que você não costuma monitorar:
- O próprio patch serve como mapa. Correções, comunicados e commits tornam-se públicos ao mesmo tempo; assim, qualquer pessoa pode ver exatamente o que mudou em uma linha com suporte e verificar se o mesmo trecho de código existe no Node.js 20.
- Sua plataforma pode continuar fazendo deploys normalmente. O AWS Lambda marcou o
nodejs20.xcomo descontinuado em 30 de abril de 2026, mas só bloqueará a criação de funções em 29 de julho de 2027 e atualizações em 31 de agosto de 2027. - Pacotes e auditorias deixam versões antigas para trás. O projeto Node.js adverte que pacotes populares removem o suporte a versões em End-of-Life com o passar do tempo, e diversas auditorias do setor proíbem o uso de runtimes sem manutenção.
Escolha seu alvo: Node.js 24 ou 26, não o 22
Migre para o 24 esta semana se você precisa do caminho mais curto. Escolha o 26 se puder absorver mais descontinuações agora e quiser o maior prazo de suporte. Pule o 22: embora ele receba a correção de novembro, seu suporte acaba em 30 de abril de 2027 — a menos de seis meses de distância —, o que obrigaria você a repetir todo esse projeto já na próxima primavera.
| Linha | Status | Mais recente em 5 de nov. | Fim do suporte | Recomendado para |
|---|---|---|---|---|
| 26.x “Lithium” | LTS ativo desde 28 de out. de 2026 | 26.13.0 | 30 de abr. de 2029 | Serviços que você pode testar integralmente agora |
| 24.x “Krypton” | LTS de manutenção desde 20 de out. de 2026 | 24.22.2 | 30 de abr. de 2028 | A saída segura mais rápida do Node.js 20 |
| 22.x “Jod” | LTS de manutenção | 22.23.4 | 30 de abr. de 2027 | Não compensa o esforço de migração hoje |
As datas são provenientes do cronograma de lançamentos do Node.js. Verifique sua plataforma antes de decidir. No Lambda, por exemplo, o runtime do Node.js 26 está em prévia pública e não é coberto pelo SLA do Lambda; logo, o Node.js 24 é o alvo mais seguro para produção nesse ambiente hoje.
Etapas da migração e o que pode quebrar
Tudo nesta tabela foi extraído das notas de lançamento oficiais das versões 22.0.0, 24.0.0, 25.0.0 e 26.0.0, além do guia de migração da v22 para a v24. Trata-se de um resumo focado em serviços de API, não do changelog completo.
| Introduzido na | Mudança | Quem é afetado |
|---|---|---|
| 22 | import ... assert { type: 'json' } removido; use with |
Código ESM importando JSON |
| 22 | crypto.createCipher() e createDecipher() removidos |
Código legado de criptografia |
| 23 and 24 | Sem binários pré-compilados para Windows 32-bit ou Linux armv7 32-bit; macOS 13.5 como requisito mínimo | Servidores antigos e dispositivos de borda |
| 24 | OpenSSL 3.5 no nível de segurança 2: chaves RSA, DSA e DH abaixo de 2048 bits, chaves ECC abaixo de 224 bits e RC4 são proibidos | mTLS e servidores upstream antigos |
| 24 | tls.createSecurePair removido; url.parse() descontinuado em tempo de execução |
Código legado de rede |
| 24 | Conformidade mais rigorosa do fetch(), validação de AbortSignal, erros em streams e pipes agora lançam exceções |
Clientes HTTP, proxies |
| 24 | V8 13.6; addons podem exigir C++20 | Módulos nativos |
| 25 (if targeting 26) | SlowBuffer e fs.F_OK, R_OK, W_OK, X_OK removidos; Corepack não vem mais incluso |
Utilitários antigos, Yarn ou pnpm via Corepack |
| 25 (if targeting 26) | Endereço IP como TLS servername descontinuado em definitivo |
Clientes conectando via IP |
| 26 | Módulos _stream_* e writeHeader() removidos; module.register() descontinuado em tempo de execução; Undici 8 |
Código legado de streams, loaders customizados |
A linha do OpenSSL é a que costuma causar problemas silenciosos: seu código não muda nada, mas o handshake com o sistema legado de algum parceiro falha em tempo de execução.
Em uma branch separada, atualize o .nvmrc, o campo engines, seu Dockerfile e o CI para a versão de destino (para configurar uma máquina limpa, consulte o guia de instalação do Node.js). Em seguida, reinstale as dependências para que os módulos nativos sejam recompilados, busque por APIs removidas, execute os codemods oficiais e inicie o serviço com o rastreamento de descontinuações ativado:
nvm install 24 && nvm use 24
rm -rf node_modules && npm ci
grep -rnE "assert \{ *type|createCipher\(|createDecipher\(|url\.parse\(|fs\.[FRWX]_OK|SlowBuffer|createSecurePair|_stream_[a-z]+|module\.register\(" \
--include="*.js" --include="*.mjs" --include="*.ts" --exclude-dir=node_modules .
npx codemod run @nodejs/import-assertions-to-attributes
npx codemod run @nodejs/crypto-createcipheriv-migration
npx codemod run @nodejs/tls-create-secure-pair-to-tls-socket
npx codemod run @nodejs/fs-access-mode-constants
NODE_OPTIONS="--trace-deprecation" npm start
Revise a saída dos codemods manualmente. O do createCipher traz um aviso explícito: o código gerado por ele não consegue descriptografar dados que foram criptografados com a API antiga; portanto, planeje uma migração de dados caso você possua registros criptografados.
O site do Node.js ainda não disponibilizou um guia de migração da versão 24 para a 26, portanto utilize as notas das versões 25.0.0 e 26.0.0 para esse salto.
Comprove que a API se comporta da mesma forma na nova versão
Testes unitários não mostram como a nova pilha TLS e o novo cliente HTTP reagem ao tráfego real. Para um salto de duas ou três versões principais, você precisa de uma comparação de "antes e depois" do serviço em execução — e essa é uma excelente tarefa para o seu assistente de código.
O Apidog CLI permite que Claude Code, Codex ou Cursor executem suas suítes de testes do Apidog diretamente pelo terminal. Basta configurá-lo uma única vez:
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
Depois, envie um único prompt para o seu agente:
My service runs on Node.js 20 in staging. Run Apidog test suite <suiteId> in project
<projectId> against environment <envId> and save reports to reports/node20. When I
redeploy on Node.js 24, run the same suite into reports/node24. List every request
whose status, body, or TLS behavior changed. Then read the service logs for deprecation
warnings and check each failure against the 22, 24, and 25 release notes: removed APIs,
changed defaults, stricter fetch and AbortSignal handling, OpenSSL key size rejections.
O agente executará a mesma suíte nos dois lados da migração:
apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
-r cli,junit --out-dir reports/node20
# redeploy the service on the target line, restart it
apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
-r cli,junit --out-dir reports/node24
Dois pontos garantem uma validação confiável:
- Nunca passe o parâmetro
-k. Essa flag desativa a validação de SSL, ocultando justamente as falhas de TLS que você precisa detectar. - Inclua as chamadas que seu serviço faz para sistemas upstream. Uma rejeição do OpenSSL se manifesta como erro de API em um endpoint que depende do sistema legado de um parceiro; portanto, teste essas rotas e não apenas o
/health.
Assim que a migração for validada, mantenha a verificação no seu pipeline. O guia de CI/CD com o Apidog CLI traz o fluxo de trabalho detalhado, e o tutorial do Claude Code explica a configuração com o agente.
Se você não puder migrar esta semana
Adquira builds com correções retroativas. A página de End-of-Life do Node.js cita três parceiros do Programa de Sustentabilidade do Ecossistema OpenJS. A HeroDevs oferece o Never-Ending Support com patches de segurança. O Endless Lifecycle Support da TuxCare faz o backport de correções para versões em fim de vida útil. A NodeSource oferece suporte e avaliações de upgrade. O projeto classifica isso como uma solução temporária — e de fato é.
Reduza o que pode alcançar o processo. Estas etapas diminuem a exposição às classes de bugs mencionadas acima, embora não corrijam as falhas em si:
- Faça o encerramento de TLS e HTTP/2 em um proxy ou balanceador de carga atualizado, comunicando-se com o Node.js via HTTP/1.1 convencional em uma rede privada.
- Interrompa a descompressão Brotli de fontes não confiáveis, tanto em requisições de entrada quanto em conteúdos obtidos externamente.
- Rejeite hostnames com bytes NUL ou formatos de IP não canônicos antes de qualquer validação de lista de permissões ou chamada de saída.
- Isole o serviço: adote credenciais com privilégios mínimos, restrinja o tráfego de saída (egress) e não compartilhe segredos com serviços que já estão atualizados.
Documente o risco formalmente. Defina um responsável, uma data-limite para a migração e as medidas compensatórias de segurança, garantindo que o “temporário” tenha um fim estabelecido.
Perguntas frequentes (FAQ)
O Node.js 20 ainda tem suporte? Não. Ele atingiu o fim da vida útil (End-of-Life) em 30 de abril de 2026. A última build lançada foi a 20.20.2, em 24 de março de 2026, e o projeto não lançará novas versões para essa linha.
O Node.js 20 está vulnerável às falhas do lançamento de 11 de novembro? Nenhum detalhe das CVEs é público até o momento, portanto não é possível afirmar com certeza quais delas se aplicam. O comunicado oficial destaca que versões em fim de vida útil são sempre afetadas quando um lançamento de segurança acontece, e o projeto não realiza avaliações individuais para essas linhas.
Devo atualizar para o Node.js 22 em vez disso? Não. Embora seja o menor salto, o suporte a essa versão termina em 30 de abril de 2027. Migrar para o 24 garante mais um ano de suporte, e o 26 garante dois anos a mais.
Node.js 24 ou 26? Opte pelo 24 se você precisa concluir a migração esta semana ou se a sua plataforma ainda não oferece suporte completo ao 26. Escolha o 26 se puder retestar tudo agora, já que ele terá suporte até 30 de abril de 2029.
Estou usando o Node.js 25. Isso se aplica a mim? Sim. O Node.js 25 atingiu o fim da vida útil em 1º de junho de 2026, tendo a 25.9.0 como última build. Essa versão também não receberá nenhuma correção em novembro, e a migração para a 26 exige apenas um salto de versão principal.