11 de novembro: Atualizações de segurança do Node.js para versões com suporte e versões fora de suporte

Principais conclusões

• O Node.js planeja lançar correções de alta gravidade para as versões 22.x, 24.x e 26.x no dia 11 de novembro ou logo em seguida.
• O Upstream considera as versões em fim de vida como afetadas, mas não disponibiliza correções para elas.
• A ELS for Runtimes está preparando correções retroativas para oito versões do Node.js que chegaram ao fim da vida útil em todas as distribuições suportadas.
• Reinicie todos os aplicativos Node.js após a atualização e verifique os backports de fim de vida útil por versão do pacote, e não node --version.

O Node.js agendou sua próxima rodada de lançamentos de segurança para quarta-feira, 11 de novembro de 2026, ou logo em seguida. Novas versões estão a caminho para as linhas 22.x, 24.x e 26.x, e o projeto classifica a vulnerabilidade mais grave em cada linha como “Alta”. Os IDs CVE e os detalhes técnicos permanecem em sigilo até que os lançamentos sejam divulgados; portanto, quaisquer alegações antecipadas sobre métodos específicos de ataque devem ser vistas com uma boa dose de desconfiança.

Para equipes que executam o Node.js por meio de alt-nodejs No que diz respeito aos pacotes, o anúncio é apenas metade da história. Isso inclui servidores de hospedagem CloudLinux, bem como os hosts Debian, Ubuntu, Alpine e Enterprise Linux cobertos pelo Endless Lifecycle Support (ELS) da TuxCare para Node.js. Uma correção publicada no nodejs.org, por si só, não corrige nada que esteja em execução nesses sistemas. Os pacotes atualizados precisam ser compilados, publicados e instalados, e os aplicativos em execução precisam ser reiniciados para que a correção entre em vigor. A maior parte do trabalho preparatório pode ser feita agora, bem antes que quaisquer detalhes sejam divulgados.

As linhas de fim de vida a montante não podem ser remendadas

A versão lançada pelo desenvolvedor original abrange apenas as versões 22, 24 e 26. O comunicado do Node.js afirma que as versões em fim de vida útil são sempre afetadas quando ocorre uma atualização de segurança, mesmo que o desenvolvedor original não ofereça mais correções para elas. Isso não significa que todas as versões antigas contenham todos os bugs recém-corrigidos, mas nada que esteja rodando o Node.js 20, 18 ou versões anteriores deve ser considerado seguro apenas porque sua versão não consta na lista de lançamentos.

Essa lacuna é exatamente o que o ELS for Runtimes aborda. A equipe do ELS da TuxCare está preparando correções retroativas para oito produtos em fim de vida útil alt-nodejs linhas, Node.js 10, 12, 14, 16, 18, 19, 20 e 23; assim, um aplicativo fixado em um runtime mais antigo poderá receber as correções desta rodada como uma atualização de pacote, em vez de uma migração de emergência. O backporting é um verdadeiro trabalho de engenharia — a correção precisa ser adaptada a um código que o upstream não mantém mais —, mas o plano é lançar essas compilações em 11 de novembro, juntamente com todo o restante, logo após o lançamento do upstream. O Documentação do ELS para Runtimes lista quais versões do Node.js são compatíveis com cada sistema operacional.

Quais repositórios contêm as compilações corrigidas?

No CloudLinux, o Node.js Selector é executado em alt-nodejs pacotes, e a versão do Node.js é escolhida por aplicativo, não por servidor nem mesmo por conta. É assim que um servidor de hospedagem acaba, sem que se perceba, executando três ou quatro versões do Node.js simultaneamente, incluindo algumas que já não têm mais suporte do desenvolvedor original.

O mesmo alt-nodejs Os pacotes também são disponibilizados pelos repositórios da TuxCare para clientes do ELS, abrangendo o Debian 10 a 13, o Ubuntu 18.04 a 26.04 e o Alpine 3.23 e 3.24, além de compilações assinadas pela TuxCare para o Enterprise Linux. Eles são instalados em /opt/alt/, junto com a versão do Node.js que já vem com a distribuição, e atualize da maneira habitual yum, apt, ou apk fluxo de trabalho. As compilações do Node.js 23 estão disponíveis apenas no Debian 12, no Debian 13 e no Alpine.

Quando os pacotes atualizados estarão disponíveis

A CloudLinux planeja iniciar a compilação assim que o Node.js publicar as correções e espera lançar a versão atualizada alt-nodejs pacotes ainda no mesmo dia. Isso abrange as versões 22, 24 e 26, além das linhas com fim de vida útil em todas as versões do CloudLinux, da 6 à 10, e as compilações do repositório TuxCare são lançadas na mesma execução. Esse plano depende do lançamento do upstream; portanto, trata-se de uma meta e não de um prazo de entrega fixo.

Os servidores com CloudLinux oferecem dois outros tipos de pacotes Node.js, cada um com seu próprio processo de atualização. Em servidores cPanel que executam o CloudLinux 8, ea-nodejs22 também vem dos repositórios do CloudLinux, mas é compilado a partir do pacote do cPanel. Sua correção depende de o cPanel publicar primeiro uma versão atualizada e, em seguida, do CloudLinux disponibilizar o pacote correspondente. O nativo do sistema operacional nodejs os pacotes seguem novamente um caminho separado, por meio das atualizações regulares dos sistemas operacionais baseados no RHEL e no AlmaLinux. Qualquer ambiente de execução instalado fora desses canais precisa ser verificado separadamente, já que um alt-nodejs A atualização não vai afetar isso.

Tarefas preparatórias que vale a pena realizar antes de quarta-feira

No CloudLinux, inscreva-se na página de status do CloudLinux para esta versão. O CloudLinux planeja divulgar uma estimativa de tempo de disponibilidade (ETA) no início da terça-feira, 10 de novembro, e, em seguida, publicar atualizações sobre o andamento a cada poucas horas até que os pacotes estejam disponíveis. Clientes do ELS que utilizam outras distribuições podem ficar atentos às compilações corrigidas na lista de correções disponíveis para o Node.js da TuxCare.

Em seguida, faça um levantamento. Execute a opção que corresponder ao gerenciador de pacotes do host (RPM, DEB ou APK):

rpm -qa 'alt-nodejs*'
dpkg -l 'alt-nodejs*'
apk info | grep alt-nodejs

Isso mostra quais versões estão instaladas, não quais aplicativos as utilizam. No CloudLinux, verifique também o Node.js Selector para ver a versão atribuída a cada aplicativo. Em outros sistemas, as unidades do systemd, as configurações do PM2 e as imagens de contêiner podem apontar, cada uma, para um binário diferente; portanto, verifique-as também. Um aplicativo que não tenha sido atualizado durante o período de atualização pode continuar executando uma versão antiga do runtime, enquanto todos os outros parecem estar atualizados.

Então, planeje reinicializações, pois a atualização do pacote por si só não é suficiente. A instalação de um pacote atualizado substitui o binário no disco, mas um aplicativo Node.js em execução continua usando o antigo até ser reiniciado, independentemente do que o gerenciador de pacotes indique.

Os aplicativos gerenciados pelo Node.js Selector podem ser reiniciados a partir de sua interface ou com este comando, utilizando o nome da conta e a raiz do aplicativo:

cloudlinux-selector restart --json --interpreter nodejs --user <user> --app-root <app_root>

Qualquer processo em execução fora do Node.js Selector é reiniciado da maneira como esse serviço é normalmente gerenciado. Em seguida, isso lista todos os processos do Node.js em execução com sua hora de início, de modo que qualquer processo iniciado antes da atualização se destaca:

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

Em servidores que hospedam muitos aplicativos, defina com antecedência a ordem de reinicialização e coordene com os responsáveis pelos aplicativos nos casos em que o tempo de inatividade seja um fator importante. Uma reinicialização planejada e escalonada é melhor do que uma reinicialização apressada na noite do lançamento.

O que fazer assim que as encomendas chegarem

Quando o relevante alt-nodejs Os pacotes já foram lançados; instale-os seguindo seu processo normal de gerenciamento de pacotes e reinicie os aplicativos afetados. Em seguida, verifique se cada aplicativo foi reiniciado corretamente e se está executando o ambiente de execução atualizado. A instalação bem-sucedida dos pacotes não garante que todos os aplicativos tenham incorporado a correção.

As linhas em fim de vida precisam de uma verificação adicional. Os pacotes 22, 24 e 26 são migrados para as novas versões do upstream, de modo que seus números de versão mudam conforme o esperado. Um backport funciona de maneira diferente, adicionando a correção à versão existente; assim, a versão do Node.js do upstream permanece a mesma e apenas o número de versão do pacote muda. Nessas linhas, node --version Parece idêntico antes e depois da atualização; portanto, compare a versão do pacote instalado com a compilação corrigida publicada pela CloudLinux ou pela TuxCare. Os scanners que comparam apenas as sequências de versão podem cometer o mesmo erro e sinalizar um backport corrigido como vulnerável.

O comunicado do Node.js conterá os detalhes da vulnerabilidade e as versões corrigidas do código-fonte assim que os lançamentos forem divulgados. Em um alt-nodejs No servidor, porém, a questão prática é mais simples. O pacote atualizado já foi instalado e o aplicativo já foi reiniciado nele? Quanto às linhas que o upstream deixou para trás, ELS para tempos de execução continua lançando correções, para que as migrações possam ocorrer de acordo com um cronograma definido pela equipe, em vez de um cronograma determinado por um órgão consultivo.

Baixe o ELS para Runtimes →

Referências

Node.js, “Quarta-feira, 11 de novembro de 2026 – Lançamentos de segurança”

Página de status do CloudLinux, “Atualizações de segurança do Node.js, 11 de novembro de 2026”

Documentação do TuxCare