Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O Node.js 20 chegou ao fim de vida útil em 30 de abril de 2026, passando a fazer parte do grupo que inclui o Node.js 18 e todas as versões anteriores, que não recebem mais correções de segurança do projeto.
- Uma versão do Node.js em fim de vida útil (EOL) significa que as vulnerabilidades (CVEs) já divulgadas ao público não receberão correções, e que também não haverá correções para quaisquer vulnerabilidades descobertas posteriormente.
- Cada binário oficial do Node.js inclui cerca de 25 componentes. Alguns, como o OpenSSL, o zlib e o ICU, também existem como bibliotecas do sistema que seu sistema operacional atualiza em outros locais, mas nunca dentro do Node.js; outros, como o V8 e o undici, não possuem nenhum pacote do sistema, de modo que as correções do desenvolvedor original só chegam até você em uma nova compilação do Node.js. Todas as cópias incluídas no pacote ficam obsoleitas no fim da vida útil (EOL).
- Suas opções são: atualizar para uma versão LTS compatível, migrar do Node.js ou utilizar o suporte estendido para continuar recebendo correções enquanto planeja a migração de acordo com seu próprio cronograma.
Se parte da sua pilha ainda roda o Node.js 18 ou 20, você não está sozinho. As versões LTS com números pares são amplamente utilizadas em produção e não deixam de funcionar no dia em que o suporte termina. Elas simplesmente deixam de receber correções. O Node.js 20 ultrapassou esse limite em 30 de abril de 2026, e todas as versões anteriores a ele já haviam ultrapassado esse limite.
Esta publicação aborda quais versões do Node.js já atingiram o fim do ciclo de vida, o que isso significa para a segurança e a conformidade das aplicações desenvolvidas com elas, e os três caminhos viáveis a seguir: atualizar, migrar ou utilizar o suporte estendido do Node.js para continuar recebendo correções enquanto você decide.
Quais versões do Node.js chegaram ao fim do ciclo de vida?
A partir de julho de 2026, apenas três linhas de versão ainda receberão atualizações do projeto Node.js: 26.x (Atual), 24.x (LTS ativa) e 22.x (LTS de manutenção). O Node.js 20 e todas as versões anteriores chegaram ao fim da vida útil, assim como as linhas com números ímpares que nunca entraram no LTS.
| Versão (nome de código) | Status | O suporte é encerrado |
| 26.x | Atual; entra no LTS em outubro de 2026 | 30 de abril de 2029 |
| 24.x (Krypton) | LTS ativo | 30 de abril de 2028 |
| 22.x (Jod) | Manutenção LTS | 30 de abril de 2027 |
| 25.x, 23.x, 21.x, 19.x | Fim do ciclo de vida; nunca entrou na versão LTS | Junho de 2026 e antes |
| 20.x (Ferro) | Fim da vida | 30 de abril de 2026 |
| 18.x (Hidrogênio) | Fim da vida | 30 de abril de 2025 |
| 17.x e versões anteriores | Fim da vida | 2023 ou antes |
Historicamente, o Node.js lança duas versões principais por ano, sendo que as versões pares são promovidas ao Suporte de Longo Prazo (LTS): cerca de seis meses como “Atual”, doze meses como “LTS Ativo” com correções de bugs e de segurança e, em seguida, uma fase de manutenção com apenas correções críticas – cerca de 30 meses de LTS, ou aproximadamente 36 meses desde o primeiro lançamento até o fim da vida útil.
Esse modelo está mudando. A partir do Node.js 27, o projeto passa a ter um lançamento principal por ano, cada versão passa a ser LTS, e os números das versões se alinham ao ano civil: 27.0.0 em 2027, 28.0.0 em 2028. Um novo canal Alpha será inaugurado em outubro de 2026 para assumir o papel de testes iniciais que as versões ímpares costumavam desempenhar, e o Node.js 26 é a última versão sob o modelo antigo. O suporte total permanece como está, em aproximadamente 36 meses desde o primeiro lançamento “Current” até o fim da vida útil. Um cronograma mais previsível, mas o prazo final é o mesmo: cada linha ainda tem uma data após a qual os patches são interrompidos.
Você também pode conferir nossa análise detalhada do cronograma e do impacto do fim da vida útil (EOL) do Node.js 18 em nosso guia específico.
O que o fim da vida útil (EOL) do Node.js significa para suas aplicações
O projeto Node.js é excepcionalmente direto quanto a isso. Sua própria página de Fim de Vida alerta para quatro consequências: fim das correções de vulnerabilidades, incompatibilidade com a cadeia de ferramentas, deslocamento do ecossistema à medida que pacotes populares deixam de oferecer suporte a ambientes de execução antigos e problemas de conformidade, pois “muitas auditorias do setor proíbem o uso de ambientes de execução sem manutenção”.
As vulnerabilidades CVE sem correção que você já conhece
O Node.js lança atualizações de segurança em um ciclo regular, e cada uma delas ignora completamente as linhas de EOL. Em 30 de julho de 2026, a página de EOL do projeto listava 27 vulnerabilidades de alta gravidade no Node.js 20 e 15 no Node.js 18, e esses números só tendem a aumentar.
É esse padrão que torna isso perigoso. A atualização de segurança de 29 de julho de 2026 foi direcionada apenas às linhas 26.x, 24.x e 22.x. Ela corrigiu onze vulnerabilidades, três delas de alta gravidade, incluindo um bug de reentrância no HTTP/2 no nghttp2 integrado, que deixa o processo com um uso indevido de memória após liberação (use-after-free) na pilha. O Node.js 20 e o 18 não receberam nenhuma correção, e o comunicado indicou aos invasores exatamente onde procurar em todas as versões que não receberam a correção. Aviso público, patch público, comparação pública. A maior parte do trabalho de descoberta já está concluída.
Para ter uma ideia de como é uma vulnerabilidade grave, veja o caso do HTTP/2 Rapid Reset (CVE-2023-44487). Ela foi explorada como uma vulnerabilidade zero-day para lançar os maiores ataques DDoS já registrados até então e afetou todos os servidores Node.js com HTTP/2 habilitado. As versões 18 e 20 do Node.js receberam correções em poucos dias. Se a mesma falha surgisse hoje, nenhuma dessas versões receberia uma correção do projeto Node.js.
As vulnerabilidades CVE que nunca receberão correção
A equipe de segurança do Node.js não avalia nem corrige vulnerabilidades em versões em fim de vida (EOL). Em janeiro de 2025, o projeto tentou deixar isso claro para os scanners de vulnerabilidades ao emitir CVE-2025-23087, um CVE abrangente que cobre o Node.js 17 e todas as versões anteriores, com CVEs complementares para as versões 19 e 21. O Programa CVE rejeitou todos os três. A política de substituição é mais ampla: todo novo CVE do Node.js agora abrange as linhas de versão em fim de vida (EOL) por padrão, a menos que o projeto tenha informações específicas de que isso não se aplica a uma delas.
Portanto, as versões 18 e 20 do Node.js não são mencionadas em um aviso geral de fim de vida útil (EOL) — presume-se que sejam afetadas por todos os avisos subsequentes. O motivo declarado pelo projeto é a falta de recursos: com mais de vinte versões em fim de vida útil, cada uma com diferentes dependências e processos de compilação, além de vulnerabilidades que se manifestam de maneiras distintas dependendo de componentes como o OpenSSL, não é viável realizar uma avaliação abrangente. Qualquer problema encontrado nessas versões permanece sem avaliação e sem correção.
Sinais de alerta em matéria de conformidade
Os auditores chegam à mesma conclusão por um caminho diferente. PCI DSS 4.x O requisito 6.3.3 exige que os patches para vulnerabilidades críticas, identificadas por meio de seu próprio processo de classificação de riscos, sejam instalados no prazo de um mês após o lançamento, o que nenhum processo pode cumprir quando não há patch disponível. Os critérios de segurança do SOC 2 pressupõem um processo de gerenciamento de vulnerabilidades, e softwares sem fonte de patch tornam isso difícil de demonstrar. Para cargas de trabalho federais e regulamentadas, um ambiente de execução sem manutenção pode ser uma constatação por si só, antes mesmo que alguém pergunte sobre CVEs específicos.
O risco oculto: a árvore de dependências incluídas no Node.js
Eis o que surpreende até mesmo equipes experientes: o Node.js não é apenas o Node.js. A documentação de dependências lista 30 componentes em sua árvore de código-fonte, e cerca de 25 deles vêm incluídos em cada binário oficial do Node.js. Isso inclui o mecanismo JavaScript V8, o loop de eventos libuv, o analisador HTTP llhttp, o cliente HTTP undici, nghttp2, nghttp3 e ngtcp2 para HTTP/2 e HTTP/3, o resolvedor de DNS c-ares, zlib, brotli e zstd para compactação, ICU, SQLite, o próprio npm e a cópia do OpenSSL do Node. (O conjunto exato varia de acordo com a versão principal — o Node.js 18 e 20, por exemplo, são anteriores à inclusão do SQLite e do zstd.)
Esses componentes se dividem em dois grupos, e ambos representam um problema após o fim da vida útil (EOL). Aproximadamente metade deles também existe como bibliotecas do sistema: OpenSSL, zlib, SQLite, ICU, nghttp2, c-ares, libuv. Seu sistema operacional aplica patches a esses componentes em outras partes do sistema, mas os binários oficiais do Node.js — aqueles do nodejs.org, de gerenciadores de versão como o nvm e das imagens padrão do Docker — são compilados em suas próprias cópias, e as atualizações do sistema operacional nunca chegam até eles. (Alguns pacotes de distribuições Linux fazem ligação com algumas bibliotecas do sistema, mas isso é a exceção.) A outra metade, incluindo V8, llhttp, undici e npm, é mantida no projeto original, mas não possui nenhum pacote do sistema em nenhum lugar da sua máquina; portanto, uma correção no projeto original só chega até você quando uma nova compilação do Node.js a inclui. De qualquer forma, a conclusão é a mesma: as correções chegam até você por meio de uma nova compilação do Node.js ou não chegam de forma alguma, e quando uma linha de lançamento chega ao fim da vida útil (EOL), toda a árvore de código fica congelada.
Não se trata de uma vulnerabilidade teórica. O Rapid Reset era uma falha no nível do protocolo HTTP/2 que o Node.js corrigiu por meio do nghttp2 integrado, e não no código escrito pela equipe do Node.js. A atualização de segurança de julho de 2026 incluiu atualizações do undici e do llhttp, além das próprias correções do Node. Essas atualizações são instaladas automaticamente em versões com suporte. Em uma versão no fim da vida útil (EOL), cada um desses componentes acumula silenciosamente quaisquer CVEs de origem que se apliquem a ele, sem nenhum canal de distribuição para as correções.
Qualquer opção séria de suporte prolongado precisa abranger toda essa área; é por isso que o Endless Lifecycle Support (ELS) da TuxCare aplica correções à árvore de dependências incluída no pacote, e não apenas ao núcleo do Node.js.
Suas opções após o fim do suporte ao Node.js
Três caminhos reais, e o caminho certo depende do nível de risco de migração que você consegue suportar neste momento:
- Não é possível fazer a atualização neste trimestre, mas precisa manter o sistema atualizado? Suporte estendido.
- Você dispõe de tempo de engenharia e de uma cadeia de dependências compatível? Faça a atualização para uma versão LTS com suporte.
- O Node.js é uma parte pequena ou cada vez menor da sua pilha de tecnologias? Considere migrar para fora do Node.js já que está nisso.
Utilize o suporte contínuo ao ciclo de vida do Node.js
A maneira mais rápida de eliminar o risco imediato sem mexer no seu código-fonte é a aplicação de patches com suporte do fornecedor. O ELS da TuxCare para Node.js oferece correções de segurança contínuas para o Node.js 12, 14, 16, 18 e 20: os patches são adaptados do código-fonte original, testados quanto à integridade e regressões, assinados, respaldados por SLA e distribuídos por meio dos gerenciadores de pacotes que você já utiliza. A TuxCare oferece esse serviço como parceira do Programa de Sustentabilidade do Ecossistema da OpenJS Foundatione está listado como provedor de suporte comercial na própria página de EOL do projeto Node.js.
A cobertura inclui a árvore de dependências agrupadas descrita acima, do OpenSSL ao undici, sem custo adicional. Você pode verificar vulnerabilidades e correções em tempo real para o Node.js no TuxCare CVE Tracker para ver exatamente o que está sendo corrigido.
Para deixar claro o papel que isso desempenha: trata-se de uma ponte, não de um destino. A ELS recupera o que o EOL tira de você: tempo para planejar uma atualização nos seus próprios termos, em vez de sob pressão de violação de segurança ou auditoria.
Atualize para uma versão LTS com suporte
A solução ideal a longo prazo. O Node.js 24 traz anos de trabalho em desempenho, os recursos atuais do V8 e suporte até 30 de abril de 2028. O Node.js 22 também ainda tem suporte, mas apenas até 30 de abril de 2027, o que o torna mais uma etapa intermediária do que um destino final. Se sua árvore de dependências estiver em boas condições e sua cobertura de testes for satisfatória, um salto de uma versão principal costuma ser viável.
No entanto, o esforço varia de acordo com a distância e a complexidade da base de código. Cada versão principal traz alterações que quebram a compatibilidade, os complementos nativos precisam ser recompilados de acordo com a nova ABI, e pacotes fixados há anos podem não ter uma versão compatível. Saltar da versão 18 para a 24 não é uma única migração; são três migrações empilhadas umas sobre as outras.
Migrar para outra tecnologia
Se um serviço já precisa ser reescrito de qualquer maneira, o EOL pode ser o gatilho para a consolidação naquilo que sua organização considera estratégico no momento, seja outro ambiente de execução, como Deno ou Bun, ou uma linguagem de programação totalmente diferente. Essa flexibilidade é real, mas o custo também é: uma migração pode significar reescrever grande parte do que o serviço faz, com toda a carga de testes que isso acarreta. Raramente faz sentido como resposta apenas ao EOL.
Os riscos de apressar uma atualização
Uma atualização de versão principal do Node.js é um projeto, não apenas uma atualização de dependências. Isso significa adaptar o código a mudanças significativas na API, verificar a compatibilidade em todo o seu arquivo de bloqueio, recompilar módulos nativos, atualizar imagens de CI, Dockerfiles e cadeias de ferramentas de compilação, além de realizar testes de regressão em tudo o que afeta o ambiente de execução.
As equipes que comprimem esse trabalho em uma situação de emergência — geralmente porque uma auditoria ou uma vulnerabilidade CVE divulgada as obriga a agir — tendem a pagar o preço mais adiante: instabilidade na produção devido a caminhos mal testados, um pico na carga de suporte, soluções provisórias que se tornam dívida técnica e custos não planejados exatamente onde o orçamento não os previa. Esse padrão se repete com tanta frequência que evitar o cenário de atualização forçada já é, por si só, uma estratégia de segurança. A pressão dos prazos e a engenharia cuidadosa não combinam.
Proteja o Node.js após o fim da vida útil (EOL) com a TuxCare
A TuxCare vem dedicando mais de uma década ao desenvolvimento da metodologia por trás da aplicação de correções de vulnerabilidades em nível corporativo e, atualmente, fornece correções retroativas a mais de 2.300 clientes corporativos nos setores de serviços financeiros, telecomunicações, saúde e governo. O processo de correção combina monitoramento automatizado de vulnerabilidades, avaliação de correções e retroportabilidade com validação especializada, e cada versão é construída a partir de fontes verificadas e assinadas, com atestados que abrangem suas dependências.
Para o Node.js, isso se traduz em atualizações contínuas de segurança, estabilidade e evidências de auditoria para as versões nas quais suas aplicações realmente são executadas: cobertura de dependências integradas, correções fornecidas por meio de seus gerenciadores de pacotes existentes e um preço que representa uma fração do custo de uma migração não planejada. Explore o ELS para Node.jsou comece com o CVE Tracker para verificar vulnerabilidades e correções em tempo real para o Node.js.
