Fim do suporte ao Node.js 18 e opções de migração

Principais conclusões

• O Node.js 18 chegou ao fim de vida útil em 30 de abril de 2025 e não recebe mais atualizações de segurança nem correções de bugs do projeto Node.js.
• O projeto considera que todas as versões em fim de vida são afetadas sempre que ocorre uma atualização de segurança; portanto, o número de vulnerabilidades sem correção no Node.js 18 aumenta de acordo com o cronograma do projeto, e não com o seu.
• O Node.js 24 é a única linha LTS ativa atualmente. O Node.js 22 já está na fase de manutenção LTS e chegará ao fim de vida útil em 30 de abril de 2027, o que o torna uma opção pouco recomendável para migração.
• Suporte de ciclo de vida ilimitado da TuxCare mantém o Node.js 18 protegido contra vulnerabilidades conhecidas enquanto as equipes planejam e testam a migração em um ritmo realista.

Quase ninguém opta por usar uma versão em fim de vida útil. As equipes acabam nessa situação porque as solicitações de atualização ficam sempre em segundo plano em relação ao trabalho de lançamento de produtos e porque, aparentemente, não há nada de errado. O Node.js 18 chegou ao fim de vida útil em 30 de abril de 2025 — há mais de um ano — e, desde então, não recebeu nenhum patch de segurança, correção de bugs ou suporte oficial do projeto Node.js.

O que costuma pegar as equipes de surpresa é a questão da contabilização. A posição do próprio projeto Node.js é que as versões em fim de vida são afetadas sempre que ocorre uma atualização de segurança, independentemente de alguém realizá-las novamente ou não. Sua superfície vulnerável, portanto, aumenta toda vez que o projeto divulga um aviso, em um ritmo que você não controla.

Este guia aborda o cronograma de fim de vida útil (EOL) do Node.js 18, qual versão você realmente deve adotar em 2026 — provavelmente não é a mais óbvia — e como manter o sistema atualizado caso a migração não possa ser concluída neste trimestre.

Entendendo o fim da vida útil do Node.js 18

É útil saber como o Grupo de Trabalho de Lançamentos do Node.js realmente estrutura o suporte. Existem três fases de suporte, e o “fim da vida útil” é o status que uma linha de lançamentos atinge quando essas fases são concluídas.

Atual: Uma nova versão principal permanece na linha “Atual” por cerca de seis meses, o que dá tempo aos autores de bibliotecas para adicionarem suporte a ela. A orientação do projeto é que os aplicativos em produção devem rodar apenas versões Active LTS ou Maintenance LTS.

LTS Ativo: Após cerca de seis meses, as versões com números pares são promovidas para LTS Ativo por aproximadamente 12 meses. Essa fase abrange mais do que apenas correções de emergência: inclui novos recursos, correções de bugs e atualizações que a equipe de Lançamento auditou e considerou adequadas e estáveis para essa linha. As linhas com números ímpares nunca são promovidas, e é por isso que as versões 23 e 25 passaram de “Atual” para o fim da vida útil sem passar por nenhuma fase LTS.

Manutenção: Após o período ativo do LTS, há cerca de 18 meses de manutenção, limitada à correção de bugs críticos e atualizações de segurança. Novos recursos são introduzidos apenas raramente e, normalmente, somente quando ajudam na migração para uma versão posterior.

Isso totaliza cerca de 36 meses desde o lançamento inicial até o fim do ciclo de vida, dos quais aproximadamente 30 meses sob cobertura LTS.

Uma mudança que vale a pena levar em conta: esse modelo de versões ímpares/pares se aplica apenas até o Node.js 26. A partir do Node.js 27, o Node.js passa a ter uma única versão principal por ano, e cada versão principal será promovida a LTS após sua fase “Current”. Se você estiver escolhendo uma versão-alvo hoje, a fase é mais importante do que o número da versão – uma versão que já está na fase de “Maintenance” está prestes a ser descontinuada, por mais recente que pareça.

Fim do suporte ao Node.js 18: datas importantes

O Node.js 18 (codinome Hydrogen) foi lançado em 19 de abril de 2022. Ele entrou na fase de LTS ativo em 25 de outubro de 2022, passou para a fase de manutenção em 18 de outubro de 2023 e atingiu o fim da vida útil em 30 de abril de 2025.

 

Por onde começar: Confirme o que você está realmente executando antes de planejar qualquer coisa, pois na maioria dos ambientes não se trata de uma única versão. Execute o comando `node -v` em cada host e, em seguida, verifique seus Dockerfiles, imagens de CI e quaisquer configurações de tempo de execução gerenciadas no Lambda, no App Runner ou na plataforma de sua escolha.

Riscos do Node.js 18 após o fim do ciclo de vida

Manter o Node.js 18 em uso após o fim do ciclo de vida não causa interrupções logo no primeiro dia, e é exatamente por isso que os sistemas continuam assim. Tudo continua funcionando. As APIs continuam respondendo. Ninguém recebe nenhum aviso.

O que mudou foi que as correções deixaram de ser lançadas, enquanto novas vulnerabilidades continuavam sendo identificadas. Os riscos abaixo se acumulam, e cada um deles é mais barato de ser resolvido durante uma janela de atualização planejada do que durante um incidente. Enquanto o Node.js 18 estava em suporte, ele recebia patches de segurança junto com todas as outras versões mantidas. Esses lançamentos foram interrompidos em abril de 2025, e o projeto Node.js não emitirá mais correções para essa versão.

Aumento da exposição a ameaças CVE

A posição oficial do projeto é um argumento útil caso você precise justificar o trabalho internamente: as versões em fim de vida útil (EOL) são sempre afetadas quando ocorre uma atualização de segurança. O Node.js não realiza novos testes nas versões EOL; portanto, seus alertas listam apenas as versões suportadas — mas os caminhos de código vulneráveis ainda estão presentes na versão 18, e não há previsão de lançamento de um patch oficial para eles.

A atualização de segurança de 13 de janeiro de 2026 é um bom exemplo disso. Ela corrigiu oito vulnerabilidades nas linhas de produtos suportadas, incluindo estas quatro:

• CVE-2025-55131 (Alta) – uma condição de corrida baseada em tempo limite faz com que o `Buffer.alloc` e as matrizes tipadas não sejam preenchidos com zeros, expondo memória não inicializada. Acessível por meio do módulo `vm` com limites de tempo de execução, o que é mais relevante em ambientes onde é executado código semiconfiável.
• CVE-2025-59465 (Alta) – um quadro HEADERS HTTP/2 malformado contendo dados HPACK inválidos causa a falha do processo por meio de um erro de soquete TLS não tratado.
• CVE-2025-59466 (Médio) – um erro do tipo “Tamanho máximo da pilha de chamadas excedido” torna-se impossível de ser interceptado quando o async_hooks está ativo, contornando o process.on(‘uncaughtException’). O alcance dessa vulnerabilidade é maior do que parece à primeira vista: o AsyncLocalStorage é baseado no async_hooks; portanto, o Next.js, os React Server Components e a maioria dos agentes APM estão sujeitos a essa vulnerabilidade.
• CVE-2026-21637 (Médio) – exceções lançadas a partir de callbacks do TLS PSK ou ALPN contornam os manipuladores de erros, causando negação de serviço e um vazamento de descritor de arquivo.

Essas correções foram lançadas nas versões 20.20.0, 22.22.0, 24.13.0 e 25.3.0. Não há um equivalente na versão 18.x, e não haverá.

Observação sobre as ferramentas: O projeto Node.js mantém o pacote `is-my-node-vulnerable`, que compara a versão instalada com o Banco de Dados de Segurança do Node.js. Execute `npx is-my-node-vulnerable`. No entanto, saiba como ele se comporta em um ambiente de execução EOL (fim de vida): em vez de listar CVEs individuais, ele informa que a versão está no fim de vida e a trata como vulnerável por padrão, pois as linhas EOL não são rastreadas em relação às versões de segurança recentes. Para obter detalhes por CVE e o status dos patches nas versões suportadas pela TuxCare, use o CVE Tracker.

 

Falhas na conformidade

Um ambiente de execução EOL raramente é reprovado em uma auditoria por si só. O que ele faz é eliminar a maneira mais simples de atender aos controles de gerenciamento de vulnerabilidades no PCI DSS, HIPAA, GDPRe a ISO 27001, que geralmente exigem que você identifique vulnerabilidades conhecidas e as corrija dentro de um prazo definido.

A norma PCI DSS é a que apresenta as especificações mais detalhadas quanto ao prazo. O requisito 6.3.3 exige que patches de segurança críticos sejam instalados no prazo de um mês após o lançamento. Quando o projeto de origem deixa de lançar patches para o seu ambiente de execução, não é possível cumprir essa exigência por meio da aplicação de patches; portanto, resta demonstrar controles compensatórios.

Há também um problema com o scanner que surpreende as pessoas. O próprio projeto Node.js agora emite CVEs contra versões em fim de vida útil (EOL), registradas como “sem suporte” quando atribuídas sob o código CWE-1104, que se refere ao uso de componentes de terceiros sem manutenção. O Node.js 18 pode, portanto, aparecer como uma falha em ferramentas como o npm audit ou o Snyk simplesmente por estar em fim de vida útil (EOL), independentemente de qualquer bug específico.

Se você estiver dentro do escopo da auditoria: escolha sua estratégia agora – atualização, aplicação de patches comerciais ou controles compensatórios documentados. Todas as três opções são defensáveis. Descobrir durante o trabalho de campo que você não possui nenhuma delas, por outro lado, não é.

Dependência e ruptura do ecossistema

As aplicações modernas em Node.js dependem de uma ampla árvore de dependências, e essa árvore muda sem aviso prévio. Pacotes, frameworks e serviços em nuvem descontinuam versões antigas de acordo com seus próprios cronogramas. A AWS, por exemplo, encerrou o suporte ao Node.js 18.x no AWS Cloud Development Kit em 30 de novembro de 2025, abrangendo a CLI do CDK, a biblioteca construct e projetos relacionados, como JSII, Projen e CDK8s.

O padrão é previsível. Novas versões de pacotes deixam de oferecer suporte às versões mais antigas do Node.js, então as equipes fixam as versões para manter tudo funcionando, e a árvore fixada também fica sem suporte. Quanto mais tempo você permanece nessa situação, mais dívida técnica se acumula, até que as atualizações de rotina comecem a exigir primeiro uma atualização do ambiente de execução.

Exemplo: Uma equipe que utiliza uma API do Node.js 18 precisa corrigir uma vulnerabilidade em uma biblioteca de registro de logs. A versão corrigida requer o Node.js 20 ou posterior. A atualização do ambiente de execução não está programada, então eles continuam usando a versão vulnerável. O patch existe, mas eles ainda não conseguem aplicá-lo.

Essa é a verdadeira natureza do risco de EOL. Ele geralmente surge por meio da árvore de dependências, e não do próprio tempo de execução.

Risco operacional e depuração mais complexa

Após o fim do ciclo de vida, o projeto Node.js deixa de disponibilizar correções de bugs e suporte técnico para essa versão, e a atenção da comunidade passa a se concentrar nas versões que ainda recebem suporte.

Isso altera a resposta a incidentes de uma maneira específica: você está depurando sem a ajuda do desenvolvedor original. Ao se deparar com um bug genuíno no runtime, não há nenhuma correção retroativa para aguardar, nenhuma triagem por parte do mantenedor e cada vez menos discussão na comunidade sobre uma versão que poucas pessoas ainda utilizam. Profilers, depuradores e agentes de APM também deixam de oferecer suporte a runtimes antigos, de modo que as ferramentas que você normalmente utilizaria podem não funcionar.

Planeje-se: se você estiver usando a versão 18 por enquanto, considere que o tempo médio de resolução para qualquer problema relacionado ao tempo de execução será maior e mantenha à mão um ambiente de depuração 18.x reproduzível, para não precisar montá-lo no meio de um incidente.

Suas opções agora que o Node.js 18 chegou ao fim do ciclo de vida

Agora que o Node.js 18 não tem mais suporte do projeto Node.js, cada equipe deve tomar uma decisão. Manter a situação atual é uma das opções disponíveis — só que isso geralmente não fica registrado em lugar nenhum, e é assim que acaba se tornando a opção padrão.

	Não fazer nada	Atualizar para uma versão LTS com suporte	Suporte Estendido
Esforço inicial	Baixo	Alto	Baixo
Esforço recorrente	Monitoramento, aprovação de riscos, evidências de auditoria	Nenhuma após a migração	Baixo
Aplicação de patches de segurança	Nenhum	Oficial e em andamento	Em andamento, para vulnerabilidades abrangidas
Risco à segurança	Cresce a cada lançamento	Mais baixo	Reduzido
Dívida técnica	Cresce	Aprovado	Ainda cresce
Ideal para quando	Isolado e prestes a ser desativado	Há disponibilidade neste trimestre	A atualização está prevista para daqui a dois ou mais trimestres

Não fazer nada

Manter o status quo é a opção mais barata neste trimestre e a mais cara em um horizonte de longo prazo. Quando um sistema está estável e não há nada que precise ser consertado, a tendência de não mexer nele é forte.

Isso não significa necessariamente que seja uma decisão errada. Um serviço que esteja genuinamente isolado, não lide com dados regulamentados e tenha uma data de desativação já definida para daqui a um ou dois trimestres pode nem valer a pena ser migrado.

O que torna essa decisão equivocada é considerá-la gratuita. Não fazer nada ainda implica custos relacionados ao monitoramento de vulnerabilidades, à aprovação da aceitação de riscos, à documentação de auditoria e a uma posição mais frágil quando algo realmente der errado. Essas horas são reais e se repetem.

Ponto de decisão: Se o serviço estiver exposto à Internet ou estiver no escopo da auditoria, essa opção está fora de questão. Se ele estiver isolado e com a aposentadoria programada, documente formalmente a aceitação do risco e passe para tarefas mais úteis.

Atualize para uma versão LTS com suporte

A atualização é a única opção que resolve o problema de vez, em vez de apenas contorná-lo. A partir de agosto de 2026, eis as opções entre as quais você poderá escolher:

• Node.js 24 (Krypton) – LTS ativo, fim do suporte em 30 de abril de 2028. A opção padrão para a maioria das equipes.
• Node.js 22 (Jod) – em manutenção LTS desde 21 de outubro de 2025, fim da vida útil em 30 de abril de 2027. Apenas correções de bugs críticos e atualizações de segurança.
• Node.js 26 – atualmente na linha “Current”, com promoção para a versão “Active LTS” prevista para outubro de 2026 e fim de vida útil planejado para 30 de abril de 2029.

 

Preste atenção à armadilha nessa lista. O Node.js 22 parece ser a escolha mais conservadora, mas já passou da fase de LTS ativo e tem menos de um ano de suporte restante; portanto, migrar da versão 18 para a 22 significa repetir todo o processo antes de abril de 2027. A menos que algo na sua árvore de dependências impeça especificamente a migração para a versão 24, não vale a pena o esforço de migrar para a versão 22.

A atualização restaura o suporte oficial à segurança e faz com que você volte a utilizar um ambiente de execução ainda compatível com o ecossistema mais amplo. O que não vai acontecer é que isso ocorra em uma tarde. A transição da versão 18 para a 24 abrange duas linhas LTS e várias versões principais da V8: os módulos nativos precisam ser recompilados de acordo com a nova ABI, as compilações do node-gyp e os binários pré-compilados precisam ser verificados, e as compilações oficiais para Linux exigem uma glibc mais recente do que as compilações do Node.js 18 — o suficiente para descartar distribuições mais antigas sem uma alteração na imagem base. Reserve recursos para um ciclo completo de testes no ambiente de staging, em vez de apenas um aumento de versão na CI.

Dica profissional: Ignore o Node.js 20. Ele chegou ao fim de vida útil em 30 de abril de 2026; portanto, migrar para ele seria um passo lateral para outro ambiente de execução sem suporte. Se sua migração ocorrer após o Node.js 26 entrar em LTS em outubro de 2026, a versão 26 terá o período de suporte planejado mais longo — avalie isso em relação ao histórico de produção mais extenso da versão 24 e ao suporte mais amplo a dependências. De qualquer forma, lembre-se de que o projeto informa que as datas do cronograma estão sujeitas a alterações.

Suporte ao ciclo de vida ilimitado da TuxCare

Nem todo sistema pode ser atualizado dentro do cronograma do projeto. Ciclos de validação longos, processos de aprovação de mudanças, pilhas de tecnologia certificadas e aplicativos fornecidos por fornecedores — tudo isso adia a data realista em trimestres, em vez de semanas.

Com o Suporte de Ciclo de Vida Ilimitado da TuxCare, o Node.js 18 continua recebendo patches de segurança para vulnerabilidades cobertas após o fim oficial do ciclo de vida. Os patches são fornecidos sem alterações no código do aplicativo, o que torna essa abordagem viável para equipes que não podem recertificar um aplicativo no momento. A TuxCare oferece suporte ao Node.js 12, 14, 16, 18 e 20.

Encare isso como uma ponte, e não como um destino. Isso aborda o aspecto do problema relacionado a correções e gerenciamento de vulnerabilidades. Não impede que sua árvore de dependências se desestruture nem que sua dívida técnica aumente, e a atualização ainda terá que ocorrer, mais cedo ou mais tarde.

Ponto de decisão: Se for realisticamente possível lançar a atualização neste trimestre, faça a atualização e pule a fase de transição. Se a data estiver prevista para daqui a dois ou mais trimestres, ou se você estiver sob auditoria e não puder aplicar o patch, faça a transição e mantenha o financiamento para a migração.

Proteja suas cargas de trabalho do Node.js 18 com a TuxCare

O Node.js 18 não sofreu alterações. O que mudou foi o status de suporte dele. O mesmo binário que era um ambiente de execução mantido em abril de 2025 é agora o componente mais antigo e sem manutenção na base de sua aplicação, e passa a apresentar novas vulnerabilidades não corrigidas sempre que o projeto lança uma atualização de segurança.

O problema é que a solução óbvia já traz uma resposta errada embutida. O Node.js 22 é a atualização intuitiva a partir da versão 18 e a que exige menos tempo. O Node.js 24 é a meta certa para a maioria das equipes, mas também é a migração mais exigente. Essa diferença entre a resposta fácil e a correta é exatamente onde o suporte estendido mostra seu valor.

Para organizações que não conseguem chegar lá imediatamente, o Suporte de Ciclo de Vida Ilimitado para Node.js mantém as cargas de trabalho do Node.js 18 protegidas contra vulnerabilidades conhecidas enquanto a migração é planejada e testada adequadamente, sem exigir alterações no código do aplicativo.

Se você ainda estiver usando o Node.js 18, decida o que fazer neste trimestre: atualizar, fazer a transição ou aceitar o risco, conforme documentado. A única opção que fica mais cara quanto mais você demora para decidir é não escolher nada.

Perguntas frequentes sobre o fim do suporte ao Node.js 18