CVE-2024-22019 no Node.js: como uma requisição HTTP pode saturar seu servidor

Publicado em 2026-10-27 por frfrand

Explicação do CVE-2024-22019: negação de serviço, servidores Node.js afetados, descoberta, detecção e mitigação.

Uma única conexão pode esgotar seu servidor?

Sim, em algumas falhas o problema não é roubar dados, mas fazer com que o serviço gaste recursos lendo informações sem os limites esperados. CVE-2024-22019, corrigida em publicações de segurança de fevereiro de 2024, afetava o servidor HTTP do Node.js e poderia facilitar ataques de negação de serviço (DoS).

O que é uma negação de serviço?

É um ataque que busca fazer com que o site pare de responder ou responda tão lentamente que os clientes legítimos não consigam usá-lo. Não requer necessariamente entrar em uma conta. Neste CVE, o problema estava relacionado à análise de mensagens HTTP que usam transferência por fragmentos (chunked encoding).

Como foi descoberto e a quem é atribuído?

O anúncio oficial do Node.js agradece a Bartek Nowotarski por reportar o problema e a Paolo Insogna pela correção. A detecção foi apoiada na análise de quanto o parser HTTP poderia consumir em casos extremos do protocolo. Este tipo de pesquisa revela falhas que podem permanecer ocultas por anos sob tráfego normal.

Como era explorado, sem entrar em instruções de ataque?

Um cliente malicioso poderia produzir uma solicitação HTTP com extensões de fragmento exageradas para forçar o servidor a ler uma quantidade ilimitada de bytes em uma conexão. Isso poderia consumir CPU e largura de banda mesmo quando o desenvolvedor confiava em limites de tamanho de corpo ou timeouts. A chave do problema era como o servidor processava uma parte da mensagem antes de aplicar algumas proteções habituais.

Quais versões e aplicações podiam ser afetadas?

O aviso original identifica as linhas ativas Node.js 18.x, 20.x e 21.x daquela época. Não significa que cada aplicação implantada hoje esteja afetada. É necessário contrastar versão, patches do fornecedor, servidor HTTP realmente utilizado e exposição pública. Um proxy reverso pode mudar a superfície exposta, mas não deve ser considerado por si só uma garantia.

Como detectar exposição ou sinais de abuso?

Verifique a versão real executada por cada serviço: não apenas a que aparece em package.json. Inspecione métricas de CPU, largura de banda, conexões longas e erros de disponibilidade. No Nginx ou no balanceador, busque padrões anômalos sem armazenar dados sensíveis desnecessários. Um aumento de CPU não comprova este CVE por si só: cruze evidências.

Como se corrige?

Atualize para uma versão do Node.js mantida que incorpore a correção. As ramas citadas são históricas: para 2026, verifique a política de suporte atual e evite ficar em uma linha sem manutenção. Também convém configurar limites de conexões e solicitações no proxy, alertas de saturação, rate limiting adequado e um procedimento de reinício controlado. Nenhuma dessas medidas substitui a instalação do patch.

Perguntas rápidas

O Express evita o problema? Não necessariamente; o Express geralmente se baseia no servidor HTTP do Node.js.

O atacante pode ler meu banco de dados? Este CVE descreve DoS; não se deve atribuir acesso a dados sem evidências adicionais.

O Docker resolve? O contêiner não corrige automaticamente o runtime incluído em sua imagem.

Fontes: Aviso oficial do Node.js de fevereiro de 2024 · Ficha CVE.

Onde acompanhar os alertas e solicitar suporte?

Na ArduMaker explicamos novas vulnerabilidades e compartilhamos orientações sobre revisão de versões, atualizações e medidas de contenção. Você pode consultar a página de CVE e suporte da ArduMaker. Se o seu sistema não usa WordPress, indique igualmente a tecnologia, versão e configuração ao descrever o caso para avaliar o que corresponde revisar. Um alerta publicado não significa que todos os servidores dessa tecnologia estejam afetados, nem que uma atualização pendente implique uma intrusão confirmada.

Atualização editorial: outubro de 2026. Verifique sempre o aviso oficial por possíveis mudanças de versões e mitigações.

Exemplo prático: uma API Node.js que para de responder

Situação: um serviço Express atrás do Nginx começa a consumir muita CPU durante um pico de conexões HTTP. A equipe suspeita do CVE-2024-22019, mas um gráfico de CPU não é uma confirmação.

Revise o runtime real do seu processo:

node --version
ps -eo pid,cmd | grep '[n]ode'

Contraste essa versão com o boletim do projeto e a imagem Docker ou o serviço systemd realmente implantado. Configure limites de conexão e timeouts no proxy como defesa adicional, e monitore conexões e disponibilidade.

Antes: atualizar apenas o package.json e reiniciar sem alterar o binário do Node.js. Depois: atualizar o runtime ou a imagem base, reconstruir, implantar, reiniciar e medir taxa de erros, latência e uso de CPU com tráfego normal.

Importante: não envie solicitações malformadas ou cargas de estresse a servidores alheios. Um teste controlado em staging é suficiente para validar a estabilidade da implantação e a versão da correção.