Um novo exploit batizado de “HTTP/2 Bomb” emergiu como uma ameaça crítica à infraestrutura web global. O impacto e os detalhes desta vulnerabilidade tornaram-se mais evidentes após a divulgação de uma análise detalhada numa postagem no LinkedIn pela pesquisadora de segurança Jolanda de Koff. O ataque ja ja possui a CVE-2026-49975 reservada, permite que um computador doméstico comum derrube servidores de larga escala (como NGINX, Apache, Microsoft IIS, Envoy e Cloudflare Pingora) em questão de segundos. A técnica força os servidores a alocarem dezenas de gigabytes de memória até pararem de responder, abusando de configurações padrão e de vulnerabilidades inerentes à arquitetura de compressão do protocolo HTTP/2.

A descoberta técnica inicial foi liderada pelo pesquisador Quang Luong (da firma de segurança Calif) em conjunto com a ferramenta de IA Codex, da OpenAI. A Inteligência Artificial analisou o código-fonte destes servidores e combinou duas técnicas antigas que pareciam inofensivas isoladamente, criando um ataque de exaustão de recursos sem precedentes. Como pesquisadores já disponibilizaram Provas de Conceito (PoCs) abertas, o tempo de resposta esperado por defensores tornou-se mínimo.

Vetor de Exploração

O núcleo da vulnerabilidade reside no mecanismo de compressão de cabeçalhos do HTTP/2, conhecido como HPACK (RFC 7541). Para economizar largura de banda, o protocolo mantém uma tabela dinâmica compartilhada entre o cliente e o servidor. Quando um cabeçalho é enviado, ele é armazenado nessa tabela, permitindo que requisições subsequentes façam referência a ele usando apenas 1 byte de dados.

O HTTP/2 Bomb converte essa otimização de rede em uma arma. Diferente de ataques anteriores (como CVE-2016-6581) que injetavam payloads massivos para estourar limites de tamanho, esta variante utiliza cabeçalhos quase vazios. A memória é esgotada não pelo conteúdo do cabeçalho em si, mas pela sobrecarga das estruturas e registros internos que o servidor precisa instanciar em memória para cada nova referência lida. Como o cabeçalho é leve, os mecanismos de limitação de tamanho (size cap) nunca são acionados.

Kill Chain e Payload

A cadeia de execução do exploit combina o abuso de memória com uma persistência de conexão, operando em duas fases letais:

1. Injeção na Tabela HPACK: O atacante armazena um cabeçalho simples na tabela dinâmica do servidor.

2. Bomb: Em uma única requisição, são enviados milhares de ponteiros de 1 byte referenciando o cabeçalho original. O servidor, por sua vez, cria uma cópia completa na memória para cada ponteiro. Em softwares como Apache e Envoy, o desperdício de alocação atinge cerca de 4.000 bytes por ponteiro de 1 byte enviado.

3. Flow-Control e Retenção: Para transformar o pico temporário de memória em uma interrupção total, o atacante abusa do recurso de flow-control definindo a janela de recebimento para 0 bytes. O servidor não consegue enviar sua resposta e fica impossibilitado de limpar a memória alocada.

4. Drip Attack: Esporadicamente, o atacante envia atualizações de 1 byte apenas para reiniciar o timeout da conexão, forçando a infraestrutura a reter os Gigabytes de memória “reféns” por tempo indeterminado.

Bypass de Fragmentação de Cookies: Em ambientes Apache e Envoy, o ataque ganha ainda mais eficácia devido a uma falha de implementação da RFC 9113, que permite a divisão de um Cookie em múltiplas frações. Esses servidores não contabilizavam as peças do Cookie divididas contra o limite de campos. O Apache agravava a situação ao reconstruir o cookie do zero a cada nova peça recebida, mantendo todas as versões obsoletas na memória.

Tabela de Impacto

Testes práticos em laboratório demonstraram uma taxa assustadora de alocação de memória antes do travamento completo (Out-Of-Memory/Crash):

• Envoy (1.37.2): Amplificação de ~5.700:1 (Consome ~32 GB em ~10 segundos).

• Apache httpd (2.4.67): Amplificação de ~4.000:1 (Consome ~32 GB em ~18 segundos).

• NGINX (1.29.7): Amplificação de ~70:1 (Consome ~32 GB em ~45 segundos).

• Microsoft IIS (Windows Server 2025): Amplificação de ~68:1 (Consome ~64 GB em ~45 segundos).

PoC para testes (OpenResty)

Comprovando a gravidade e a facilidade de replicação da falha, poucas horas após a divulgação do ataque, foi disponibilizado publicamente um Laboratório PoC (Proof of Concept) autossuficiente no GitHub pelo usuário xero.

Este laboratório foca em testar a vulnerabilidade especificamente no OpenResty (baseado no NGINX), simulando configurações comuns de sidecars de produção. A PoC é executada localmente via Docker e combina a bomba de referências do HPACK com o travamento de janela do Slowloris.

Os resultados práticos do laboratório são reveladores:

• Em uma configuração vulnerável (que modela o uso da diretiva large_client_header_buffers 32 32k comum em produção), uma única conexão com apenas 16 streams gerou um consumo de 1,2 GB de memória RAM (amplificação de ~84:1). Em servidores permitindo 128 streams simultâneos (padrão em muitas empresas), isso escalaria para quase 10 GB por conexão maliciosa.

O repositório também serve como um campo de testes educacional para Blue Teams, permitindo a validação de mitigações com configurações endurecidas (reduzindo os buffers e aplicando limites estritos) ou desativando o protocolo completamente.

Em testes realizados em minha máquina local, o servidor recebeu 1.257,4 MB em 2,5 segundos de execução, provando o potencial impacto e baixo custo de ataque da vulnerabilidade:

Mitigação

Ações recomendadas para administradores de sistemas e equipes de segurança:

• NGINX: Atualize imediatamente para a versão 1.29.8 (ou superior) e estabeleça um limite rígido usando a nova diretiva (max_headers 1000;). Caso o upgrade não seja viável no momento, a recomendação é desligar o suporte: http2 off;.

• Apache: Para mitigar o impacto da CVE-2026-49975, faça o downgrade temporário do protocolo para reduzir o blast radius. Use a configuração Protocols http/1.1. (Nota: reduzir o LimitRequestFields não impede o ataque devido à falha na contagem de cookies fragmentados).

• Sistemas Sem Patch (IIS, Envoy, Pingora): Desative o HTTP/2 se possível. Alternativamente, instale um WAF, CDN ou Reverse Proxy na borda que tenha capacidade de impor limites absolutos de cabeçalhos e fragmentos por requisição.

• Hardening Geral (OS Level): Limite a memória disponível por processo worker usando Cgroups ou ulimit -v. Isso garante que processos isolados sejam encerrados pelo OOM Killer do sistema operacional e reiniciados automaticamente, impedindo que a máquina inteira entre em estado crítico de paginação (swap).

Referências:

[1] Jolanda de Koff (LinkedIn): Postagem original de alerta sobre a vulnerabilidade HTTP/2 Bomb

[2] HackingPassion (Jolanda de Koff): HTTP/2 Bomb Takes Down nginx Apache IIS Envoy and Cloudflare

[3] Calif Security Research: Memory Exhaustion Vulnerabilities in HTTP/2 Implementations

[4] PoC de Validação (xero): hbomb-slowloris-poc-lab (GitHub)

[5] NVD: CVE-2016-6581

[5] MITRE: CVE-2026-49975

[6] RFC 7541: HPACK – Header Compression for HTTP/2