Node.js: falhas em HTTP/2 e HTTPS permitem que clientes derrubem servidores e leiam dados de outros usuários

O que aconteceu

Em 11 de novembro de 2026, o projeto Node.js publicou versões de segurança para suas três linhas de lançamento suportadas. As versões corrigidas são 22.23.5, 24.22.3 e 26.13.1. Elas corrigem 16 vulnerabilidades no próprio Node.js, e sete delas têm gravidade alta. As versões também atualizam as dependências incluídas llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) e sqlite (22.x, 24.x).

Os problemas mais importantes estão no código de servidor que o Node.js fornece para HTTP/2, HTTPS e TLS:

• Queda do servidor HTTP/2 (24.x e 26.x): qualquer cliente não autenticado pode fazer o processo do Node.js parar. O servidor só precisa da configuração padrão de HTTP/2 e de um handler que responda antes de o corpo da requisição ter chegado por completo. O projeto considera esse comportamento típico. O ataque funciona tanto com TLS quanto com conexões sem criptografia.
• Exposição de memória no HTTP/2 (as três linhas): um servidor pode enviar a um cliente trechos de sua memória, inclusive respostas destinadas a outras conexões. A partir de 24.22.0 e 26.9.0, um cliente pode provocar isso por conta própria. Nas versões 22.x e nas 24.x e 26.x mais antigas, pode ocorrer quando o servidor encerra um stream no meio de uma resposta, por exemplo após um timeout de inatividade.
• Exposição de memória no HTTPS (as três linhas): um cliente não autenticado pode ler memória de outras conexões, "incluindo chaves privadas TLS e requisições de outros usuários", segundo o projeto. Isso exige um handler que chame res.flushHeaders() antes de o corpo da requisição terminar e, depois, chame res.end() com dados. Para ler a memória vazada, o atacante também precisa de uma rota que devolva ou armazene o corpo de uma requisição.
• Esgotamento de recursos no HTTP/2 (as três linhas): um cliente pode fazer qualquer servidor HTTP/2 padrão manter memória e descritores de arquivo indefinidamente.
• Entrega de arquivos no HTTP/2 (24.x e 26.x): um cliente pode corromper a memória do servidor quando ele entrega arquivos com stream.respondWithFile() ou stream.respondWithFD(). Nas três linhas, cancelar esses downloads também pode derrubar o servidor (gravidade média).
• Queda de servidor TLS (24.x e 26.x): um cliente pode derrubar um servidor TLS que use os hooks SNICallback, OCSPRequest, newSession ou resumeSession, ou server.addContext().
• Contorno de certificado de cliente no TLS (as três linhas): alguns servidores aplicam regras mais rígidas de certificado de cliente a determinados nomes de host. Nesses servidores, um cliente aprovado para outro host pode mudar para um host mais restrito durante a renegociação do TLS 1.2 sem cumprir as regras dele.

O aviso não relata ataques que explorem essas falhas.

Quem é afetado

• Servidores que executam Node.js 22.x anterior à 22.23.5, 24.x anterior à 24.22.3 ou 26.x anterior à 26.13.1.
• Linhas fora de suporte, incluindo 20.x e 25.x, não recebem correção nesta versão. O projeto informa que essas versões estão sempre afetadas.
• Os problemas graves do lado do servidor só importam quando um processo Node.js aceita conexões HTTP/2, HTTPS ou TLS diretamente. Exemplos são os módulos nativos node:http2, node:https ou node:tls, ou frameworks que os usam para terminar TLS ou HTTP/2.
• Servidores HTTP simples criados com node:http não são afetados pela exposição de memória no HTTPS.
• A queda no HTTP/2 afeta apenas as linhas 24.x e 26.x, não a 22.x.

Sua exposição é bem menor se um proxy reverso como nginx, Apache, HAProxy ou um balanceador de carga encerra o TLS e o HTTP/2, e o Node.js recebe apenas HTTP/1.1 sem criptografia vindo dele. Ainda assim, você deve atualizar, pois a versão também traz outras correções e atualizações de dependências.

O que fazer agora

1. Encontre todas as instalações do Node.js. Lembre-se de pacotes do sistema, gerenciadores de versão (nvm, n, Volta), imagens Docker, runners de CI e painéis de hospedagem que trazem seu próprio Node.js.
2. Atualize para a versão corrigida da sua linha: 22.23.5, 24.22.3 ou 26.13.1. Se você usa pacotes de distribuição ou de fornecedores (por exemplo, NodeSource ou a distribuição Linux), instale a atualização assim que sua fonte de pacotes disponibilizar essas versões.
3. Saia de versões fora de suporte. Se ainda executa 20.x, 25.x ou versões anteriores, migre para uma linha suportada. O aviso não lista nenhuma solução alternativa para servidores que não podem ser atualizados.
4. Reconstrua as imagens de contêiner com uma imagem base do Node.js atualizada e reimplante-as. Atualizar apenas o host não altera o Node.js dentro dos contêineres.
5. Reinicie todos os processos Node.js (unidades systemd, PM2, contêineres Docker etc.) para que o novo runtime seja carregado. Depois, verifique se suas aplicações respondem normalmente.
6. Considere trocar segredos caso tenha sido exposto. O aviso não diz se servidores que atenderam às condições da exposição de memória no HTTPS devem substituir chaves TLS ou outros segredos. Se um servidor HTTPS em Node.js seu atendia a essas condições e estava acessível pela internet, considere renovar o certificado TLS e a chave.

Como verificar se você é afetado

• Execute node -v em cada servidor e dentro de cada contêiner (docker exec <container> node -v). Versões abaixo de 22.23.5, 24.22.3 ou 26.13.1 em sua linha, ou qualquer linha fora de suporte como 20.x ou 25.x, estão afetadas.
• Com o PM2, pm2 list e pm2 show <app> mostram qual binário e versão do Node.js cada aplicação usa.
• Verifique se suas aplicações encerram HTTP/2 ou TLS diretamente no Node.js: procure no código por http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback e addContext.
• Verifique o gerenciador de processos e os logs do sistema em busca de reinicializações ou quedas inesperadas do Node.js. Abortos repetidos de um servidor HTTP/2 podem indicar tentativas de provocar a queda.

Fontes

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html