Pesquisadores da empresa Calif descobriram uma vulnerabilidade de negação de serviço remoto que afeta os cinco principais servidores web do mundo — nginx, Apache, Microsoft IIS, Envoy e Cloudflare Pingora — em suas configurações padrão de HTTP/2. Um único atacante com conexão residencial consegue consumir 32 GB de memória do servidor em menos de 20 segundos, explodindo a alocação de cabeçalhos HPACK enquanto mantém a conexão aberta com janela de fluxo zero. A falha, batizada de HTTP/2 Bomb, foi revelada em 3 de junho de 2026 com proofs-of-concept públicos e CVEs já atribuídos para alguns dos afetados.
Como funciona o ataque
O HTTP/2 Bomb encadeia duas técnicas conhecidas de uma forma inédita. A primeira delas explora o HPACK, o algoritmo de compressão de cabeçalhos do HTTP/2 definido na RFC 7541. O atacante insere um cabeçalho na tabela dinâmica do servidor e depois emite milhares de referências indexadas de apenas 1 byte. Cada referência obriga o servidor a alocar uma cópia completa da entrada — com toda a sobrecarga de metadados do allocator. No Apache e no Envoy, um único byte no fio vira até 4.000 bytes na memória. No nginx e no IIS, a razão é menor (~70:1), mas o volume compensa.
O segundo componente é um hold estilo Slowloris: o cliente anuncia uma janela de controle de fluxo de zero bytes, impedindo que o servidor envie sua resposta. Pequenos frames WINDOW_UPDATE de 1 byte resetam o timeout periodicamente, mantendo toda a memória alocada presa indefinidamente. O resultado é que o servidor nunca libera os recursos, e a memória se acumula até o esgotamento total.
Por que os patches demoraram
A raiz do problema está na especificação RFC 7541. A seção 7.3 trata o risco de memória exclusivamente como uma razão de amplificação, assumindo que SETTINGS_HEADER_TABLE_SIZE seria um limite suficiente. Ela ignora a sobrecarga de bookkeeping por entrada — os metadados que o allocator do servidor cria em volta de cada cabeçalho. Cinco implementações independentes leram a mesma especificação e cometeram o mesmo erro. Para servidores que limitam o número de campos de cabeçalho, como Apache e Envoy, o atacante contorna a restrição fragmentando o header Cookie em milhares de “crumbs”, permitidos pela seção 8.2.3 da RFC 9113. No Envoy, a razão de amplificação chega a 5.700:1.
Servidores afetados e status
| Servidor | Amplificação | Memória consumida | Status do patch |
|---|---|---|---|
| Envoy 1.37.2 | ~5.700:1 | 32 GB em ~10s | Pendente |
| Apache httpd 2.4.67 | ~4.000:1 | 32 GB em ~18s | CVE-2026-49975 corrigido |
| nginx 1.29.7 | ~70:1 | 32 GB em ~45s | Versão 1.29.8 com max_headers |
| Microsoft IIS | ~68:1 | 64 GB em ~45s | Pendente |
| Cloudflare Pingora | ~70:1 | Variável | Pendente |
De acordo com o Shodan, mais de 880 mil websites públicos com HTTP/2 estão potencialmente expostos, embora muitos estejam protegidos por CDNs que podem mitigar parcialmente o ataque.
O que fazer agora
Administradores devem atualizar nginx para a versão 1.29.8 ou superior, que introduz a diretiva max_headers com limite padrão de 1.000 cabeçalhos. No Apache, aplicar o patch do CVE-2026-49975 ou desativar HTTP/2 com Protocols http/1.1. Para IIS, Envoy e Pingora, a orientação imediata é desativar HTTP/2 ou posicionar um proxy reverso com limites rígidos de conexão na frente. Limitar memória por processo (ulimit -v) também reduz o impacto. Provas de conceito e ambientes Docker para teste estão disponíveis no repositório público da Calif no GitHub.