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
- Quando uma versão do Node.js chega ao fim de sua vida útil, o desenvolvedor original deixa de verificar se novas vulnerabilidades a afetam.
- A partir do Node.js 27, o projeto lança uma versão principal por ano, e todas as linhas de versão passam a ser LTS.
- As ferramentas de IA estão identificando bugs reais no Node.js, mas os relatos duplicados agora sobrecarregam os voluntários responsáveis pela triagem.
- As equipes que não conseguem fazer a atualização dentro do prazo precisam de um ambiente de execução corrigido, e não podem ficar na esperança de que nada venha a ser divulgado.
Um aplicativo Node.js não para de funcionar quando sua versão chega ao fim do ciclo de vida. O projeto original simplesmente deixa de oferecê-lo suporte. E, como explicou James Snell, membro do Comitê Técnico de Orientação do Node.js, em uma conversa informal recente com a TuxCare, essa diferença é muito maior do que parece.
“Sem retroportabilidade, sem correções”, disse ele. Quando chega um novo relatório de vulnerabilidade, a equipe nem sequer verifica se ele afeta uma linha em fim de vida (EOL). Um serviço pode parecer estar funcionando perfeitamente em produção, enquanto o trabalho de segurança realizado a montante já seguiu em frente discretamente, sem levá-lo em conta.
Esse foi um dos vários momentos espontâneos do “Keepers of the Runtime”, em que Snell conversou com Chris DeMars, defensor sênior de desenvolvedores da TuxCare. Sem slides, sem demonstração de produto. Eles discutiram por que o Node.js está mudando para uma versão principal por ano, como os relatórios de segurança gerados por IA estão afetando uma equipe de segurança voluntária e quanto trabalho humano está por trás de uma atualização de segurança que parece rotineira. Aqui está o que mais importa se você utiliza o Node.js em produção, embora valha a pena reservar meia hora para assistir à reprise completa.
O fim do ciclo de vida do Node.js significa o fim do trabalho de segurança realizado pelo desenvolvedor original
A descrição de Snell sobre o fim do ciclo de vida foi direta. Assim que uma versão principal deixa de receber suporte, nada mais é enviado para ela. Nenhuma correção de segurança, nenhuma correção de bug comum, nenhum backport de branches mais recentes. “Outras pessoas podem fazer isso, mas nós não vamos”, disse ele ao se referir ao teste de versões antigas em relação a novos relatórios. “Assim que chega ao fim do ciclo de vida, ela sai do nosso radar.”
As próprias orientações do projeto sobre vulnerabilidades em EOL seguem a mesma linha. Uma versão antiga pode muito bem ser afetada por uma vulnerabilidade divulgada em uma versão mantida, mas o upstream geralmente não investigará o ramo antigo para confirmar o impacto, muito menos criará uma correção.
Pense no que isso significa para o seu scanner. A partir de 2025, as novas CVEs do Node.js listam as linhas EOL como afetadas por padrão, a menos que o projeto indique o contrário. Isso mantém o aviso visível, mas ninguém no upstream confirmou a falha na sua versão, e ninguém no upstream está desenvolvendo a correção.
Um ambiente de execução EOL também não funciona isoladamente. O Node.js inclui componentes como o V8 e o OpenSSL, e Snell destacou que vulnerabilidades zero-day no V8 surgem o tempo todo, incluindo fugas da sandbox. Nem todas as falhas do V8 no lado do navegador chegam ao Node.js, mas alguém precisa identificar quais delas chegam, e, em uma linha de produto em fim de vida (EOL), essa pessoa não é o desenvolvedor original. Enquanto isso, bibliotecas e ferramentas continuam deixando de oferecer suporte a versões mais antigas do Node.js, de modo que adiar a atualização fica mais difícil a cada mês.
Nada disso significa que toda implantação em fim de vida útil (EOL) seja automaticamente vulnerável a ataques. A exposição depende da vulnerabilidade específica, da configuração e dos caminhos de código acessíveis. O que muda no fim de vida útil é que as respostas e os patches do desenvolvedor original deixam de ser fornecidos, e isso faz com que sua equipe tenha mais investigações a realizar justamente no momento em que suas opções estão se reduzindo.
Por que o Upstream não manterá as versões antigas disponíveis por mais tempo
As pessoas pedem à equipe de desenvolvimento que mantenha uma versão antiga em funcionamento por mais algum tempo. A resposta tem a ver com pessoas e máquinas. O Node.js é mantido principalmente por voluntários. Alguns colaboradores são patrocinados, mas, segundo Snell, quase todos que lançam atualizações, fazem backports e contribuem o fazem em seu tempo livre. “Não vamos simplesmente oferecer suporte generalizado para tudo para sempre”, disse Snell. “Não podemos. É impossível.”
Depois, há a CI. Segundo Snell, uma execução completa de CI abrange cerca de 55 combinações de plataforma, arquitetura e sistema operacional, com algo em torno de 7.800 testes em cada uma, e uma única execução pode levar até uma hora. As empresas disponibilizam essa infraestrutura, e sua capacidade é fixa. Multiplique isso por cada linha de versões antigas e a conta rapidamente fica impossível de fazer. Como disse Snell: “O fim da vida útil é o fim da vida útil porque simplesmente não podemos, fisicamente, dedicar os recursos necessários para mantê-la”.
Essa é uma posição justa; é difícil contestá-la. No entanto, isso deixa uma lacuna, e essa lacuna recai sobre quem ainda utiliza a versão antiga.
Por que o Node.js está mudando para uma versão principal por ano
Esse mesmo problema de capacidade explica o novo calendário de lançamentos. O cronograma anterior era um meio-termo estabelecido durante a reunificação do io.js: versões ímpares de curta duração, com suporte por apenas cerca de oito meses, para que os autores de bibliotecas e frameworks pudessem se antecipar às novidades, além de versões pares que se tornavam LTS para as empresas.
Dez anos de dados de download revelaram uma realidade diferente. “Na verdade, ninguém usava as versões de curto prazo”, disse Snell. As empresas já estavam atualizando o software mais ou menos uma vez por ano, se tanto. Os mantenedores, por sua vez, às vezes precisavam lidar com quatro ou cinco linhas de lançamento ativas ao mesmo tempo, e cada correção de segurança precisava ser rastreada por meio de ramificações que haviam se desdobrado de maneiras diferentes.
De acordo com o plano oficial de lançamento do Node.js, o Node.js 27 é a primeira versão do novo modelo. A cada ano, há um lançamento principal em abril, promovido a LTS em outubro, de modo que todas as linhas de lançamento acabam se tornando LTS. Um canal Alpha assume o papel de testes iniciais que antes era desempenhado pelos lançamentos ímpares e, após seis meses no Alpha, cada linha recebe 36 meses de suporte, desde seu primeiro lançamento “Current” até o fim da vida útil. O resumo de Snell sobre as vantagens foi simples: muito menos linhas para gerenciar, com aproximadamente três em andamento por vez.
| Linha de liberação | Começa a fase Alfa | Primeiro lançamento | Entra no LTS | Fim da vida |
|---|---|---|---|---|
| Node.js 26 (a última versão no modelo antigo) | Não se aplica | Maio de 2026 | Outubro de 2026 | Abril de 2029 |
| Node.js 27 | Outubro de 2026 | Abril de 2027 | Outubro de 2027 | Abril de 2030 |
| Node.js 28 | Outubro de 2027 | Abril de 2028 | Outubro de 2028 | Abril de 2031 |
Se sua equipe já utiliza apenas versões LTS, poucas mudanças ocorrerão além da numeração das versões. Se você desenvolve produtos com Node.js, a recomendação de Snell foi parar de esperar até abril para descobrir o que deixou de funcionar. Mudanças significativas e funcionalidades descontinuadas são lançadas em main constantemente. Adicione uma tarefa de teste básico na integração contínua (CI) que seja executada nas próximas compilações Alpha sem bloquear as fusões, e certifique-se de que alguém realmente analise os resultados. As compilações Alpha não se destinam à produção, mas identificar um problema com três ou quatro meses de antecedência sai muito mais barato do que descobri-lo durante uma janela de migração.
O que acontece entre um relatório de segurança do Node.js e uma correção
O Node.js recebe relatórios de vulnerabilidades por meio do HackerOne. Um avaliador primeiro verifica se o comportamento é real e, em seguida, decide se ele ultrapassa um limite de segurança definido pelo modelo de ameaças do projeto.
É fácil ignorar esse segundo critério. O modelo de confiança do Node é direto: se o código é executado, ele é considerado confiável. Uma falha de segmentação (segfault) que só pode ser provocada pela execução do seu próprio código localmente é provavelmente um bug comum, corrigido de forma aberta. Algo acessível por meio de uma entrada remota não confiável, como a execução remota de código ou uma negação de serviço remota, é tratado como uma vulnerabilidade.
Essas correções são desenvolvidas, revisadas e implementadas em um fork privado do Node, e a versão de segurança é gerada a partir daí. Somente após o lançamento é que as alterações são transferidas para o repositório público. Isso mantém o intervalo entre a divulgação e a disponibilidade do patch próximo de zero para as linhas suportadas, mas também significa que o prazo já começa a correr para você no momento em que um aviso é divulgado publicamente. A versão de 21 de outubro de 2026 é um bom exemplo — dez CVEs nas linhas 22.x, 24.x e 26.x, quatro delas classificadas como “Alta”. O artigo da TuxCare intitulado “10 CVEs do Node.js, um RCE no Brotli e o que fazer se sua versão estiver no fim do ciclo de vida (EOL)” detalha o que isso significa para quem usa uma linha no fim do ciclo de vida. A próxima rodada já está agendada também. O Node.js anunciou outra atualização de segurança para 11 de novembro de 2026, ou logo depois, cobrindo novamente as versões 22.x, 24.x e 26.x, com a pior vulnerabilidade classificada como “Alta”. O comunicado esclarece que as versões em fim de vida (EOL) são sempre afetadas quando ocorre uma atualização de segurança.
A IA está identificando bugs reais e sobrecarregando a fila de triagem
Foi nesse ponto que Snell ficou mais animado. A varredura assistida por IA funciona. “Ela está, sem dúvida, encontrando falhas reais”, disse ele. A precisão não é o principal problema. O volume é que é.
Pesquisadores que utilizam ferramentas semelhantes tendem a encontrar o mesmo bug ao mesmo tempo e a reportá-lo de forma independente. Snell descreveu ter recebido 10 ou 20 relatórios sobre um mesmo problema, com mais relatórios ainda chegando enquanto a correção estava em andamento e um fluxo contínuo chegando aos poucos após a divulgação. Durante um período recente de triagem, ele estimou que “provavelmente nove em cada dez relatórios eram duplicados” – sua estimativa com base naquela carga de trabalho, não uma taxa medida.
A atualização de segurança do segundo trimestre de 2026 da OpenJS Foundation confirma essa tendência. O Node.js recebeu 352 relatórios do HackerOne nos dois anos anteriores a esse trimestre. Em seguida, os relatórios aumentaram 4,6 vezes em fevereiro de 2026, após o lançamento de ferramentas de varredura assistidas por IA, e somente em março foram registrados 65. Na época da conversa, disse Snell, o Node.js já havia lançado correções para mais de 50 vulnerabilidades em 2026, um recorde.
Seu conselho aos pesquisadores foi prático. Leiam a política de segurança e o modelo de ameaças do projeto. Pesquisem nos relatórios divulgados publicamente pelo HackerOne para verificar se a falha já foi resolvida. E se o seu agente identificar 20 possíveis falhas, não enviem 20 relatórios de uma só vez. Classifiquem-nas e enviem as mais críticas primeiro.
O trabalho que não aparece nas notas de lançamento
Snell não chegou ao Node.js por meio de algum grande plano. Em 2013, enquanto trabalhava na IBM, ele encontrou um bug em que o Node tratava um método HTTP corrompido como P?T como um método válido, em vez de rejeitá-lo. Como ainda não havia um processo de relatório de segurança, ele abriu uma issue pública, ouviu que não entendia como esse tipo de software funcionava, corrigiu o problema sozinho e se afastou. O fork do io.js o trouxe de volta quando a IBM precisou de um líder técnico para tudo relacionado ao Node, e ele passou a integrar o TSC por volta de março de 2015.
O trabalho diário é menos glamoroso do que o cargo sugere. As manhãs começam com uma hora ou mais de notificações do GitHub, às vezes 800 ou 900 por dia. A revisão de código toma ainda mais do seu tempo. “Eu leio cada linha de cada PR, mesmo as mais extensas”, disse ele, sejam dez linhas ou 20 mil, muitas vezes em duas ou três revisões. A IA agora escreve a maior parte de seus testes, mas ainda não substituiu o julgamento humano.
Snell também refutou a ideia de que o Node.js tenha um roteiro de produto. “Não há gerente de produto. Nem mesmo há um gerente de projeto.” Ninguém pode comprar um recurso no Node. Depois que a integração contínua (CI) é aprovada, uma solicitação de pull (PR) pode ser aceita com duas aprovações após pelo menos 48 horas, ou com uma aprovação após uma semana, desde que ninguém se oponha. Portanto, se você quiser que o Node faça algo, o conselho dele é abrir uma PR e fazer você mesmo, em vez de exigir que voluntários desenvolvam isso de graça.
O que isso significa para as equipes que ainda utilizam versões mais antigas do Node.js
Comece pelo que está realmente em produção. Não pelo que o Dockerfile atual diz ou pelo que o ticket de migração indica, mas pelas versões do Node.js em execução na produção, incluindo os serviços que ninguém mexe há algum tempo. Compare-as com o cronograma de lançamentos do Node.js, identifique aquelas que já passaram do fim da vida útil (EOL) e designe um responsável para cada uma. O Node.js 20 chegou ao fim da vida útil em 30 de abril de 2026, e o Node.js 22 seguirá o mesmo caminho em abril de 2027; portanto, isso não é um problema apenas para equipes que utilizam versões muito antigas.
Se você puder fazer a atualização agora, faça-a. Uma versão LTS com suporte é a solução mais simples, e atualizações de rotina durante a operação são melhores do que ter que lidar com uma emergência a cada poucos anos.
Algumas aplicações não conseguem seguir esse cronograma. Imagine um serviço de pagamentos preso ao Node.js 18 porque um complemento nativo deixa de funcionar nas versões mais recentes do V8, com a migração dependendo de uma reformulação por parte do fornecedor prevista para daqui a dois trimestres. Em casos como esse, “vamos atualizar mais tarde” não é um plano de segurança, a menos que o ambiente de execução antigo ainda tenha como receber correções.
Essa é a lacuna que o Suporte de Ciclo de Vida Infinito (ELS) da TuxCare para Node.js preenche. Como parte do ELS para Runtimes, ele retroporta correções de segurança para versões do Node.js em fim de vida (EOL) cobertas pelo SLA e as disponibiliza como atualizações de pacotes, para que suas aplicações continuem rodando no runtime para o qual foram desenvolvidas enquanto você conclui a migração de acordo com seu cronograma. Basta reiniciar os processos do Node.js afetados após uma atualização para que eles utilizem o ambiente de execução corrigido. A cobertura remonta até o Node.js 10 no Enterprise Linux e abrange também o Ubuntu, o Debian e o Alpine Linux, com as versões suportadas variando de acordo com o sistema operacional; portanto, verifique a matriz de versões na documentação. Isso não elimina a necessidade de fazer a atualização no futuro. O serviço cobre o período entre o dia em que o desenvolvedor original deixa de corrigir uma versão e o dia em que você pode retirá-la de uso com segurança.
Também não é preciso esperar por uma ligação de vendas. Compre o ELS para Runtimes on-line, instale-o e coloque suas versões do Node.js em fim de vida útil (EOL) de volta no fluxo de atualizações.
Perguntas frequentes
O que acontece quando uma versão do Node.js chega ao fim de sua vida útil?
O Upstream suspende todas as confirmações nessa linha de código, incluindo correções de segurança, e não verifica se as vulnerabilidades recém-relatadas a afetam. A partir desse momento, o risco recai sobre a equipe responsável por ela.
Quando será lançado o Node.js 27?
A versão Alpha do Node.js 27 teve início em outubro de 2026. O primeiro lançamento da versão “Current” está previsto para abril de 2027, com a promoção para LTS em outubro de 2027 e o fim do suporte em abril de 2030.
É possível continuar usando o Node.js 18 ou o Node.js 20 após o fim do suporte?
Sim. Serviços de suporte comercial, como o “Endless Lifecycle Support for Node.js” da TuxCare, continuam fornecendo correções de segurança para versões em fim de vida útil (EOL) cobertas enquanto você planeja sua atualização, desde que você instale as atualizações e reinicie os processos afetados.
Assista à conversa informal na íntegra
A reprise traz as histórias que não foram incluídas nesta postagem, além da sessão de perguntas e respostas ao vivo sobre relatórios duplicados e retenção de voluntários. Assista a “Keepers of the Runtime” com James Snell e Chris DeMars.
E se parte da sua pilha ainda estiver em uma versão do Node.js para a qual o desenvolvedor original já não oferece mais correções, não espere que o próximo aviso de segurança tome a decisão por você. Adote o ELS for Runtimes e garanta que as versões cobertas continuem recebendo correções de segurança enquanto você realiza a atualização no seu próprio ritmo.
