HTTP/2 Bomb causa negação de serviço remota em servidores web amplamente usados

Exploração combina compressão HPACK e retenção de conexões HTTP/2 para manter alocações de memória em nginx, Apache httpd, IIS, Envoy e Cloudflare Pingora.

Componente	Configurações padrão de HTTP/2 em nginx, Apache httpd, Microsoft IIS, Envoy e Cloudflare Pingora, com variante do Apache httpd associada a CVE-2026-49975.
Vetor	Requisições HTTP/2 que combinam referências HPACK de 1 byte a cabeçalhos já inseridos na tabela dinâmica com janela de controle de fluxo anunciada como zero byte e pequenos frames WINDOW_UPDATE para manter a conexão ativa.
Impacto	Exaustão remota de memória, com possibilidade de dezenas de gigabytes alocados em segundos por um único atacante em conexão residencial, levando a negação de serviço por pressão de memória.
Prioridade	Aplicar correções disponíveis, limitar quantidade de cabeçalhos por requisição, desabilitar HTTP/2 onde não houver correção e impor limites de memória por worker, processo ou contêiner.
Versões e correções	nginx 1.29.8 incluiu a diretiva max_headers com limite padrão de 1.000 cabeçalhos; Apache httpd recebeu correção em mod_http2 v2.0.41; IIS, Envoy e Pingora estavam sem correção indicada no material analisado.
Artefatos técnicos	A classe explora HPACK definido na RFC 7541 e controle de fluxo por stream em HTTP/2 descrito na RFC 9113, usando sobrecarga de alocador e metadados por entrada como fator de amplificação.

Resumo técnico

Uma técnica de negação de serviço remota chamada HTTP/2 Bomb foi divulgada afetando configurações padrão de HTTP/2 em servidores e proxies de ampla adoção: nginx, Apache httpd, Microsoft IIS, Envoy e Cloudflare Pingora. A falha não depende de execução de código, credenciais válidas ou exploração local; o impacto descrito é consumo agressivo de memória no servidor até o ponto de degradação ou indisponibilidade. O elemento central é a combinação de dois comportamentos já conhecidos em HTTP/2: compressão de cabeçalhos com estado por HPACK e retenção prolongada de respostas por controle de fluxo. Isoladamente, cada comportamento já era reconhecido como fonte de risco; a novidade técnica está no encadeamento que transforma uma amplificação transitória em alocação persistente.

O ataque começa com a tabela dinâmica de HPACK. Nesse mecanismo, o cliente pode registrar um cabeçalho e depois reutilizá-lo por referência indexada, reduzindo bytes no tráfego. O problema aparece quando o servidor precisa materializar cópias internas do cabeçalho a cada referência, mesmo quando o custo no fio é mínimo para o atacante. O contexto técnico informa que uma referência de 1 byte pode forçar alocações aproximadas de 70 bytes em nginx, IIS e Pingora, e de cerca de 4.000 bytes em Apache httpd e Envoy. Em uma única requisição com milhares de referências, a diferença entre custo de envio e custo de processamento vira uma pressão de memória assimétrica.

A segunda parte impede que essas alocações sejam liberadas rapidamente. O cliente anuncia janela de controle de fluxo por stream com tamanho zero, fazendo com que o servidor não consiga concluir a resposta. Em seguida, pequenos frames WINDOW_UPDATE de 1 byte mantêm o timeout de envio sendo renovado. O resultado é uma retenção intencional: objetos de memória que deveriam ser temporários permanecem vinculados a conexões e streams vivos. Essa característica eleva o risco operacional, porque um atacante com largura de banda limitada pode manter várias alocações presas no servidor sem precisar sustentar tráfego volumoso durante todo o período de indisponibilidade.

Fluxo técnico

O fluxo técnico pode ser entendido em três fases defensivas: preparação da tabela HPACK, multiplicação das referências e congelamento do ciclo de resposta. Na primeira fase, o cliente insere um cabeçalho na tabela dinâmica de compressão. Na segunda, a requisição passa a conter grande quantidade de referências indexadas ao mesmo valor. Para o cliente, cada referência representa um custo mínimo de transmissão; para o servidor, cada referência exige decodificação, criação de estruturas internas e contabilidade associada ao cabeçalho processado. A amplificação descrita não vem apenas do tamanho do cabeçalho decodificado, mas do custo administrativo de armazenar entradas quase vazias, metadados de alocador e estruturas auxiliares por implementação.

A condição que torna a falha persistente está no controle de fluxo do HTTP/2. Ao declarar janela de zero byte, o cliente evita que a resposta avance normalmente. O servidor permanece com dados e estado de stream aguardando capacidade de envio. Pequenos frames WINDOW_UPDATE mantêm a sessão viva o suficiente para que os timeouts usuais não encerrem o fluxo. Do ponto de vista de defesa, isso é relevante porque o volume de tráfego pode parecer baixo em comparação com ataques volumétricos tradicionais. O gargalo principal passa a ser memória por worker, processo ou instância, não necessariamente largura de banda, CPU ou quantidade bruta de pacotes.

A variante atribuída ao Apache httpd recebeu CVE-2026-49975 após divulgação coordenada em 27 de maio de 2026, com correção no mesmo dia. O nginx teve correção indicada na versão 1.29.8, incluindo a diretiva max_headers com teto padrão de 1.000 cabeçalhos. Para Microsoft IIS, Envoy e Cloudflare Pingora, o material analisado não indica correção disponível no momento da publicação. Nesses casos, as alternativas defensivas ficam concentradas em desabilitar HTTP/2 temporariamente, inserir camada intermediária capaz de limitar cabeçalhos por requisição ou aplicar restrições de memória para evitar que um processo leve o host inteiro a swap ou indisponibilidade sistêmica.

A análise de causa aponta para uma limitação de específicação na RFC 7541. A proteção esperada pelo parâmetro SETTINGS_HEADER_TABLE_SIZE considera o tamanho da tabela dinâmica e a razão de amplificação do conteúdo decodificado, mas não cobre adequadamente o custo de estrutura por entrada em implementações reais. Esse detalhe é importante porque cinco implementações independentes teriam interpretado a mesma área da específicação de modo compatível com o mesmo tipo de falha. Para engenharia de segurança, a lição é que limites de bytes lógicos nem sempre protegem contra esgotamento de recursos quando a camada de implementação adiciona overhead significativo por objeto.

Superfície afetada

A superfície exposta inclui servidores web, gateways, proxies reversos e camadas de borda que aceitam HTTP/2 diretamente de clientes externos. A análise citada no contexto identificou mais de 880.000 sites públicos com suporte a HTTP/2 e execução de uma das famílias de servidor afetadas, embora parte relevante desses serviços possa estar atrás de CDNs. A presença de CDN reduz a exposição direta apenas quando a borda efetivamente encerra HTTP/2, impõe limites próprios e não repassa ao origin padrões que reproduzam a falha. Ambientes que permitem tráfego HTTP/2 direto até o origin continuam mais sensíveis.

Serviços de alta disponibilidade devem tratar a falha como risco de capacidade e resiliência. O impacto esperado não é leitura de dados, roubo de credenciais ou execução remota de código; é indisponibilidade por consumo de memória. Ainda assim, em produção, esse tipo de falha pode derrubar workers, aumentar latência, acionar reinicializações em cascata e degradar balanceadores quando a política de health check remove instâncias de forma repetida. Sistemas que compartilham host entre múltiplos serviços ficam mais vulneráveis a efeitos colaterais, especialmente quando não há isolamento forte por cgroups, limites de contêiner ou quotas por processo.

• Servidores expostos com HTTP/2 habilitado em nginx, Apache httpd, Microsoft IIS, Envoy ou Cloudflare Pingora.
• Origins que recebem HTTP/2 diretamente, sem CDN ou proxy intermediário com limite rígido de cabeçalhos por requisição.
• Ambientes com workers sem limite de memória, onde uma falha de processo pode empurrar o host para swap ou afetar serviços vizinhos.
• Instalações de Apache httpd que ainda não aplicaram mod_http2 v2.0.41 quando usam HTTP/2.
• Instalações de nginx anteriores à correção indicada na versão 1.29.8, quando não há controle equivalente de quantidade de cabeçalhos.

Hunting e telemetria

A detecção deve priorizar comportamento de protocolo e pressão de recurso, não apenas volume de tráfego. Uma campanha HTTP/2 Bomb pode gerar conexões persistentes com baixo throughput aparente, muitas referências de cabeçalho no processamento interno e crescimento rápido de memória por worker. Em proxies e servidores que exportam métricas por processo, operadores devem cruzar aumento de RSS, número de streams HTTP/2 ativos, duração anormal de conexões e baixa taxa efetiva de resposta. O sinal mais forte é a combinação de alocação crescente com respostas que não terminam por causa de controle de fluxo restritivo.

Em logs de aplicação, a visibilidade pode ser limitada, porque a falha ocorre antes de um fluxo HTTP convencional ser plenamente concluído. Por isso, telemetria de camada 7, métricas de servidor, eventos de OOM, reinicializações de worker e contadores de HTTP/2 são mais úteis que apenas logs de URL. Equipes com observabilidade em proxies devem procurar sessões HTTP/2 que mantêm streams abertos por períodos incomuns, variações anormais em frames WINDOW_UPDATE pequenos e discrepância entre bytes recebidos e memória consumida. Quando houver WAF, CDN ou proxy intermediário, a análise deve verificar se a camada de borda enxerga e limita a contagem real de cabeçalhos após a decodificação HPACK.

• Crescimento rápido de memória residente em workers de nginx, Apache httpd, IIS, Envoy ou Pingora durante conexões HTTP/2 persistentes.
• Streams HTTP/2 com resposta bloqueada, baixa transferência útil e renovação contínua de controle de fluxo.
• Eventos de encerramento por OOM, reinício de worker ou degradação de latência sem aumento proporcional de banda consumida.
• Requisições com quantidade incomum de cabeçalhos materializados após decodificação, mesmo quando o tamanho no fio parece reduzido.
• Diferença acentuada entre tráfego de entrada pequeno e consumo de memória elevado por conexão ou por stream.

Mitigação

A ordem de resposta deve começar pela identificação de serviços que aceitam HTTP/2 de clientes externos. Em Apache httpd, a correção indicada é aplicar mod_http2 v2.0.41 quando a implantação usa esse módulo. Em nginx, a versão 1.29.8 introduz a diretiva max_headers com limite padrão de 1.000 cabeçalhos, reduzindo a capacidade de multiplicação por referências. Para Microsoft IIS, Envoy e Cloudflare Pingora, como o contexto não indica patch disponível no momento da publicação, a medida defensiva mais direta é desabilitar HTTP/2 temporariamente ou colocar o serviço atrás de proxy que imponha limite rígido de quantidade de cabeçalhos por requisição.

A mitigação também precisa considerar modo de falha. Limites de memória por worker, cgroups, quotas de contêiner e restrições por processo reduzem a chance de um único serviço levar o host inteiro à indisponibilidade. Uma política em que um worker excede limite, é encerrado e retorna de forma controlada é preferível a permitir consumo sem teto até swap, thrashing e perda ampla de capacidade. Essa contenção não corrige a causa, mas transforma uma falha sistêmica em evento mais isolado e monitorável.

Após aplicar correções ou mudanças de configuração, a validação deve confirmar que HTTP/2 continua servindo tráfego legítimo dentro dos limites esperados, que requisições com grande quantidade de cabeçalhos são rejeitadas ou encerradas cedo e que workers não acumulam memória de forma indefinida sob conexões longas. Equipes que dependem de CDN devem validar a arquitetura real de terminação: se a CDN encerra HTTP/2 e fala HTTP/1.1 com o origin, o risco muda; se repassa HTTP/2 ou permite bypass direto ao origin, o serviço permanece dentro da superfície afetada.

• Inventariar todos os endpoints públicos com HTTP/2 habilitado e mapear se a terminação ocorre na borda, no proxy interno ou no servidor origin.
• Aplicar mod_http2 v2.0.41 em Apache httpd quando aplicável e atualizar nginx para versão com max_headers ou controle equivalente.
• Desabilitar HTTP/2 temporariamente em IIS, Envoy ou Pingora quando não houver correção disponível e o risco de exposição direta for alto.
• Configurar proxy, CDN ou gateway para impor limite rígido de quantidade de cabeçalhos por requisição após decodificação.
• Definir limites de memória por worker, processo ou contêiner e monitorar eventos de OOM como sinal de exploração ou teste indevido.