O projeto Node.js publicou em 11 de novembro de 2026 as versões 26.13.1, 24.22.3 e 22.23.5. Elas corrigem 16 vulnerabilidades com CVE: sete de severidade alta, seis média e três baixa. Na semana passada, o aviso prévio só dizia que haveria correções de severidade alta, como registrei em Node.js 26, 24 e 22 recebem correções de segurança em 11 de novembro. Agora os detalhes estão publicados, e eles mostram com mais clareza quem precisa atualizar primeiro.
Onde estão as falhas
Quase tudo o que é grave está no servidor HTTP/2 e na camada TLS do próprio Node. Entre as sete altas, segundo o comunicado:
- um cliente sem autenticação consegue derrubar o processo de um servidor
http2com configuração padrão, por TLS ou sem TLS (CVE-2026-123863), ou de um servidor TLS que usaSNICallback, OCSP ouserver.addContext()(CVE-2026-126051); - em HTTPS, uma combinação de
res.flushHeaders()antes do fim do corpo da requisição comres.end()pode fazer o servidor copiar a própria memória para o corpo da requisição, o que pode expor chaves privadas TLS e requisições de outros usuários (CVE-2026-123864); onode:httpsem TLS não é afetado; - no HTTP/2, o encerramento de um stream pode enviar ao cliente dados de resposta de outras conexões (CVE-2026-123866), e servir arquivo com
respondWithFile()abre caminho para corrupção de memória (CVE-2026-123874); - um cliente pode prender sessões HTTP/2 abertas para sempre, consumindo memória e descritores de arquivo (CVE-2026-123865);
- em servidores com regras de certificado de cliente diferentes por hostname, a renegociação TLS 1.2 permite trocar de hostname e levar a autenticação de um host para outro (CVE-2026-123872).
Entre as médias, duas também mexem com autenticação: um contexto SNI que define só a CA cai para a CA padrão e deixa passar clientes que não deveria (CVE-2026-123867), e o https.Agent pode reaproveitar uma sessão TLS validada com a lista padrão de certificados numa requisição que pedia uma política mais restrita (CVE-2026-123877). Outra média grava a URL do proxy com usuário e senha nas mensagens de erro ERR_PROXY_INVALID_CONFIG, que costumam acabar em logs e ferramentas de monitoramento de erros (CVE-2026-123871). As três baixas tratam do Permission Model e do zlib.
As versões também atualizam dependências: llhttp nas três linhas, undici em 24 e 26 e SQLite em 22 e 24.
Quem precisa correr
O comunicado lista as três linhas suportadas como afetadas. Algumas falhas altas, como a CVE-2026-123863 e a CVE-2026-123874, valem só para 24 e 26. A ordem de prioridade abaixo é avaliação minha, a partir das condições descritas em cada CVE.
Está no topo quem expõe o Node diretamente à internet terminando TLS ou HTTP/2 no próprio processo: servidores http2 ou https nativos, frameworks configurados para servir HTTP/2 e serviços com mTLS (autenticação mútua por certificado) com regras por hostname. Nesses casos, um cliente anônimo consegue derrubar o serviço ou ler memória.
Quando um CDN, balanceador ou proxy reverso termina o TLS e fala HTTP/1.1 com o Node, a maior parte das falhas de servidor HTTP/2 e TLS não chega à aplicação. Ainda sobram as correções do lado cliente (https.Agent), o vazamento de credencial de proxy em logs e as atualizações do llhttp, que valem para qualquer servidor HTTP. Esse grupo também atualiza, com menos urgência.
Node 20 e 25 já saíram de suporte de segurança, em 30 de abril e 1º de junho de 2026, segundo o endoflife.date. O comunicado diz que versões fora de suporte "são sempre afetadas" quando sai uma release de segurança, e elas não recebem patch. Para quem ainda está nelas, a decisão é de migração, e o que pesa nela foi o tema de Uma versão suportada ainda exige uma decisão de migração.
O que fazer agora
- Subir para 26.13.1, 24.22.3 ou 22.23.5, conforme a linha em uso. São patches dentro da mesma linha, sem troca de versão maior.
- Reconstruir as imagens Docker a partir de uma tag atualizada. Um container que continua rodando mantém o binário antigo.
- Em plataformas gerenciadas que escolhem o runtime por você, confirmar com o provedor quando a nova versão entra e se a troca é automática.
- Procurar URLs de proxy com credenciais nos logs e nas ferramentas de monitoramento de erros e trocar essas senhas se aparecerem, porque a correção impede novos vazamentos, mas não apaga o que já foi gravado.
Para quem se enquadra no primeiro grupo, eu trataria como trabalho desta semana. O comunicado não define prazo e não fala em exploração ativa.
O que ainda não está claro
O comunicado não informa se alguma das falhas já está sendo explorada nem traz nota CVSS para cada uma. Também não diz quando imagens oficiais e provedores gerenciados passam a entregar as versões novas. Se alguma entrar no catálogo de vulnerabilidades exploradas da CISA, a prioridade sobe também para quem está atrás de um proxy.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
