Uma única conexão de internet residencial, de 100 Mbps, pode fazer um servidor web consumir 32 GB de RAM em menos de 20 segundos e simplesmente parar de responder. Essa é a promessa da HTTP/2 Bomb, uma nova classe de ataque de negação de serviço (DoS) descoberta por inteligência artificial e divulgada em 2 de junho de 2026. A vulnerabilidade atinge as configurações padrão de cinco das principais implementações de servidores web: nginx, Apache HTTPD, Microsoft IIS, Envoy e Cloudflare Pingora. A descoberta foi feita pela empresa de segurança Calif, que utilizou o modelo Codex, da OpenAI, para combinar duas técnicas conhecidas há quase uma década — mas que, sozinhas, eram consideradas mitigadas.
Duas técnicas antigas, uma combinação letal
A HTTP/2 Bomb não é uma vulnerabilidade nova no sentido tradicional. Ela explora a interação entre dois mecanismos legítimos do protocolo HTTP/2, descritos nas RFCs 7541 e 9113. O primeiro é a compressão HPACK. No HTTP/2, cabeçalhos podem ser comprimidos usando uma tabela dinâmica: uma vez que um cabeçalho é registrado, ele pode ser referenciado por um índice de apenas 1 byte. O problema é que o servidor, ao receber essa referência, precisa expandir o cabeçalho completo na memória. Um byte na rede pode se transformar em centenas ou milhares de bytes no servidor. Essa compressão desproporcional é conhecida como HPACK bomb e foi catalogada como CVE-2016-6581.
O segundo mecanismo é o controle de fluxo do HTTP/2, que funciona com janelas de dados. Um atacante pode definir a janela de fluxo como zero bytes e, pouco antes do timeout, enviar um frame WINDOW_UPDATEcodecodecodecode de 1 byte. Isso mantém a conexão viva indefinidamente, sem que o servidor consiga liberar a memória alocada para aquela sessão. É uma variação do clássico ataque Slowloris, adaptado ao HTTP/2.
Individualmente, essas técnicas já tinham defesas conhecidas. Contra a HPACK bomb, os servidores passaram a limitar o tamanho máximo do cabeçalho após a descompressão. Contra o Slowloris, limites de timeout e de número total de cabeçalhos eram suficientes. A HTTP/2 Bomb, porém, faz a combinação das duas de forma a anular essas proteções.
No ataque, o invasor envia cabeçalhos quase vazios — cada um com poucos bytes — mas que, ao serem referenciados pelo índice HPACK, geram uma estrutura de gerenciamento de memória relativamente grande no servidor. Como o dado descomprimido é pequeno, o limite de tamanho de cabeçalho não é acionado. E como a conexão é mantida viva pelo WINDOW_UPDATEcodecodecodecode constante, o servidor não consegue liberar a memória. Para piorar, a especificação do HTTP/2 (RFC 9113, seção 8.2.3) permite explicitamente a fragmentação do cabeçalho Cookiecodecodecodecode em múltiplos frames, o que permite ao atacante gerar centenas de cabeçalhos virtuais sem violar limites de contagem — como ocorre no Apache HTTPD e no Envoy.
Conexão residencial de 100 Mbps, 32 GB em 20 segundos
Os dados divulgados pela Calif em seu blog técnico são impressionantes. Usando uma única máquina cliente conectada por uma linha residencial de 100 Mbps, a equipe conseguiu consumir e reter 32 GB de RAM em servidores Apache HTTPD e Envoy em cerca de 20 segundos. A tabela a seguir resume os resultados para cada software testado.
| Software | Taxa de amplificação | Resultado (demo) | CVE | Patch |
|---|---|---|---|---|
| Envoy | ~5.700:1 | ~32 GB em ~10 s | — | Disponível (em verificação) |
| Apache HTTPD | ~4.000:1 | ~32 GB em ~18 s | CVE-2026-49975 | mod_http2 v2.0.41 |
| nginx | ~70:1 | ~32 GB em ~45 s | — | 1.29.8+ |
| Microsoft IIS | ~68:1 | ~64 GB em ~45 s | — | Nenhum |
| Cloudflare Pingora | Não divulgado | — | — | Nenhum |
Os dados mostram que nginx e IIS têm taxas de amplificação bem menores (cerca de 70x), mas ainda assim conseguem consumir 32 GB em 45 segundos. Mantendo a conexão ativa, o consumo pode prosseguir até derrubar o servidor por falta de memória. Uma busca no Shodan indica mais de 880 mil sites usando HTTP/2 com esses softwares diretamente expostos.
Status dos patches e medidas de mitigação
A resposta dos desenvolvedores variou. A nginx foi a mais rápida: alertada em abril, lançou na versão 1.29.8 uma diretiva max_headerscodecodecodecode (padrão 1000) que permite limitar o número de cabeçalhos por requisição. Para quem não pode atualizar, a recomendação é desabilitar o HTTP/2 com http2 off;codecodecodecode.
No Apache HTTPD, o desenvolvedor Stefan Eissing lançou o mod_http2 v2.0.41 no mesmo dia da divulgação (27 de maio), corrigindo a vulnerabilidade que recebeu o identificador CVE-2026-49975. Porém, esse patch ainda não foi incorporado ao ramo oficial 2.4.x — é necessário obtê-lo pelo repositório separado do mod_h2. Como alternativa, pode-se desabilitar o HTTP/2 com a diretiva Protocols http/1.1codecodecodecode.
O Envoy disponibilizou um patch em 3 de junho, mas a Calif ainda está verificando a completude da correção. Para Microsoft IIS e Cloudflare Pingora, não há patch disponível até o momento. A recomendação geral é desabilitar o HTTP/2 ou colocar um proxy reverso com limites rígidos de cabeçalhos na frente do servidor.
Independentemente do software, uma medida eficaz de mitigação é impor limites de memória ao processo do servidor web usando cgroups, ulimit -vcodecodecodecode ou limites de memória do contêiner. Um worker que atinge o limite e morre por OOM (out-of-memory) é preferível a um servidor inteiro que entra em swap e para de responder.
O que a descoberta por IA revela sobre o futuro da segurança
Além do impacto técnico imediato, a HTTP/2 Bomb levanta questões profundas sobre o ciclo de vida de vulnerabilidades. As duas técnicas usadas eram conhecidas há quase dez anos. Cada uma tinha defesas individuais. No entanto, cinco implementações independentes — escritas por equipes diferentes, em linguagens diferentes — tinham o mesmo ponto cego: a combinação das duas.
O fundador da Calif, Thai Duong, foi um dos descobridores da vulnerabilidade CRIME em 2012 e participou da revisão do HPACK. Ele mesmo admitiu que, ao reler as notas da época, não havia considerado essa combinação. Quem encontrou o elo perdido foi o modelo Codex, da OpenAI. A Calif demonstrou que, ao alimentar a IA com os diffs dos patches da nginx e do Apache, o modelo foi capaz de reconstruir um exploit funcional e, mais importante, deduzir que as outras três implementações (Envoy, IIS, Pingora) também eram vulneráveis — antes mesmo de qualquer teste prático.
Isso encurta drasticamente o tempo entre a divulgação de um patch e a criação de um exploit. Antes, esse intervalo era medido em dias ou semanas. Com IA, pode ser questão de horas. O modelo não só replica o ataque, como generaliza para variantes não documentadas. A implicação é clara: o modelo tradicional de divulgação responsável de 90 dias pode estar obsoleto. Qualquer patch público agora carrega o risco de ser imediatamente transformado em arma por sistemas automatizados.
Para administradores de servidores web no Brasil, a mensagem é urgente. Verifique se seu ambiente usa HTTP/2 diretamente em um dos softwares afetados. Aplique os patches disponíveis ou desabilite o protocolo. Reforce os limites de memória do processo. O código de prova de conceito já está público. A HTTP/2 Bomb não é uma ameaça teórica — é um ataque funcional que pode ser executado por qualquer pessoa com uma conexão residencial e um notebook.
