Pesquisadores da empresa de segurança Calif descobriram a Bomba HTTP/2, uma falha de negação de serviço remota que atinge as configurações padrão de NGINX, Apache HTTPD, Microsoft IIS e Envoy. Um simples computador doméstico, ligado a uma internet de 100 Mbps, consegue deixar um servidor vulnerável indisponível em segundos, consumindo até 32 GB de memória. A descoberta foi feita pelo OpenAI Codex, que encadeou duas técnicas conhecidas numa combinação inédita e devastadora, segundo o The Hacker News.

  • O que é: uma falha de DoS (negação de serviço) na compressão de cabeçalhos HTTP/2.
  • O que afeta: NGINX, Apache HTTPD, Microsoft IIS, Envoy e Cloudflare Pingora.
  • Poder de fogo: um único cliente pode prender até 32 GB de memória em cerca de 20 segundos.
  • Quem achou: a inteligência artificial OpenAI Codex, sob comando dos pesquisadores da Calif.
  • O que fazer: atualizar o NGINX para 1.29.8+, o Apache para mod_http2 2.0.41 e aplicar o Patch Tuesday de junho da Microsoft.

O que é a Bomba HTTP/2

A Bomba HTTP/2 é uma vulnerabilidade de esgotamento de recursos que explora o HPACK, o esquema de compressão de cabeçalhos usado pelo protocolo HTTP/2. O HPACK comprime os metadados de requisição e resposta usando codificação Huffman, reduzindo em média 30% o tamanho dos cabeçalhos. Foi projetado para resistir a ataques antigos, como o CRIME, que podia vazar cookies de autenticação a partir de cabeçalhos comprimidos.

O problema é que o servidor aloca, para cada cabeçalho recebido, uma quantidade de memória de controle — o chamado bookkeeping. A falha faz com que um único byte trafegado na rede vire uma alocação completa de cabeçalho no servidor, repetida milhares de vezes por requisição, explicam os pesquisadores da Calif. A diferença em relação às bombas de compressão clássicas é sutil, mas decisiva: aqui o cabeçalho é quase vazio e a amplificação vem do custo de manter cada entrada, não do seu tamanho.

A vulnerabilidade recebeu identificadores distintos por implementação. O conjunto de CVEs inclui CVE-2026-49975 (Apache HTTP Server e NGINX), CVE-2026-47774 (Envoy, CVSS 7.5) e CVE-2026-49160 (implementações HTTP/2 da Microsoft, CVSS 7.8), conforme consolidação da SecPod.

Como o ataque funciona na prática

A Bomba HTTP/2 combina duas técnicas antigas numa só. A primeira é a bomba HPACK, parente direta do CVE-2016-6581, divulgado em 2016. A segunda é um hold estilo Slowloris — um ataque de camada de aplicação que sobrecarrega o alvo abrindo e mantendo muitas conexões HTTP simultâneas.

O truque que torna a nova falha tão letal está no detalhe que burla as defesas existentes. Como explica a Calif ao The Hacker News, os servidores aprenderam a limitar o tamanho total do cabeçalho decodificado. A variante nova vai no sentido oposto: o cabeçalho é quase vazio, e a amplificação vem do trabalho que o servidor faz em torno de cada entrada. O limite de tamanho decodificado nunca dispara porque praticamente não há nada para decodificar.

O componente de retenção é uma janela de controle de fluxo de zero bytes, que impede o servidor de liberar a memória alocada. O resultado é que o atacante prende cada byte alocado pelo tempo que quiser, quase de graça. Em um cenário realista, um cliente solitário pode consumir e segurar 32 GB de memória contra Apache HTTPD e Envoy em aproximadamente 20 segundos.

A IA que encontrou a falha

Um dos aspectos mais notáveis da descoberta é a autoria. A Bomba HTTP/2 foi identificada pelo OpenAI Codex, o mesmo sistema que escreve código, encadeando duas técnicas documentadas há quase uma década. A IA percebeu que ninguém havia combinado a bomba de compressão com a retenção estilo Slowloris sobre o HPACK — um espaço cego que humanos revisaram e não viram.

Para os profissionais de segurança no Brasil, isso sinaliza uma mudança de patamar. Ferramentas de IA já não servem apenas para atacar, automatizando phishing e malwares. Começam a encontrar falhas estruturais em protocolos fundamentais da internet, na velocidade de uma análise de código exaustiva que um time humano demoraria semanas para realizar. É o mesmo receio que rondou o ecossistema depois de falhas anteriores, como a CVE-2025-53020, de esgotamento de memória no Apache httpd.

Quais servidores são afetados

A vulnerabilidade é ampla porque atinge a configuração padrão de HTTP/2 dos servidores mais usados do mundo. A tabela abaixo resume o estado de cada implementação afetada e o caminho de correção disponível.

Servidor CVE Correção disponível
NGINX CVE-2026-49975 Versão 1.29.8+ (diretiva max_headers)
Apache HTTPD CVE-2026-49975 mod_http2 v2.0.41
Microsoft IIS CVE-2026-49160 Patch Tuesday de junho de 2026
Envoy CVE-2026-47774 Versões 1.35.11, 1.36.7, 1.37.3 e 1.38.1
Cloudflare Pingora — Sem ação necessária

As fontes originais, incluindo o relato detalhado do The Hacker News e o comunicado técnico da HAProxy, confirmam que a falha existe na configuração padrão — ou seja, qualquer servidor exposto sem ajuste manual está potencialmente vulnerável até ser atualizado.

O impacto para sites brasileiros

Para o leitor brasileiro, o cenário é preocupante. O NGINX está entre os servidores web mais usados no país, sustentando desde lojas virtuais e portais de notícias até serviços públicos. Para entender por que essas plataformas são alvo recorrente, vale revisar o nosso guia completo sobre vulnerabilidades e hardening de Apache, NGINX e IIS. Como a falha permite que um único computador doméstico, numa conexão de 100 Mbps, derrube um servidor em segundos, o custo do ataque é mínimo e o do prejuízo, máximo — queda de faturamento em e-commerce, indisponibilidade de serviços essenciais e perda de reputação.

O ataque também é atraente para quem quer silenciar sites durante eventos sensíveis, como eleições, denúncias ou campanhas de pressão pública. Diferente de um ransomware, que exige invadir e cifrar dados, a Bomba HTTP/2 apenas precisa manter conexões abertas. Não há roubo de informações nem persistência, o que dificulta a investigação forense e torna a atribuição quase impossível.

A boa notícia é que grandes provedores de conteúdo, como a Cloudflare, informaram ao The Hacker News que sua arquitetura e mitigações de DDoS detectam e bloqueiam o ataque automaticamente. A Imperva também confirma que protege seus clientes contra o CVE-2026-49975. Quem não usa essas redes, porém, precisa agir por conta própria.

Como se proteger agora

A correção depende do servidor em uso, mas todas as trilhas são diretas. Os passos recomendados seguem o guia oficial da Calif e as notas dos próprios fornecedores.

  1. NGINX: atualize para a versão 1.29.8 ou superior, que introduz a diretiva max_headers com limite padrão de 1000. Se a atualização não for possível, desative o HTTP/2 com a instrução http2 off;.
  2. Apache HTTPD: instale o mod_http2 v2.0.41. Sem opção de upgrade, force o protocolo definindo Protocols http/1.1.
  3. Microsoft IIS: aplique as atualizações do Patch Tuesday de junho de 2026, que corrigem o CVE-2026-49160.
  4. Envoy: atualize para uma das versões corrigidas: 1.35.11, 1.36.7, 1.37.3 ou 1.38.1.
  5. Defesa em profundidade: mantenha um serviço de mitigação de DDoS na frente do servidor, especialmente em infraestruturas que recebem tráfego público intenso. Os princípios do hardening de servidores continuam sendo a primeira barreira.

O prazo para agir é curto. Embora a Calif tenha coordenado a divulgação com os fornecedores, qualquer servidor desatualizado e exposto à internet continua um alvo fácil até receber o patch. Revisar a versão instalada hoje custa minutos; recuperar um ambiente caído durante uma promoção de e-commerce custa muito mais.

Leia também

Por que as defesas falham

Os administradores que confiam apenas em limites de tamanho de cabeçalho podem se sentir falsamente seguros. A lição central da Bomba HTTP/2 é que a especificação HTTP/2 trata o risco de memória puramente como uma razão de amplificação — e a razão é só metade da equação. Um amplificador de 70:1 seria inofensivo se a memória fosse liberada ao fim da requisição. Ele vira ataque porque o HTTP/2 permite ao cliente segurar a conexão aberta quase de graça, prendendo cada byte alocado por quanto tempo quiser.

Isso significa que regras simples de firewall e limites de taxa convencionais, baseados em número de requisições, não detectam o problema. O tráfego parece legítimo e escasso em volume. A defesa eficaz exige ou a atualização do servidor, com os novos limites de cabeçalho, ou uma camada de proteção de aplicação capaz de identificar o padrão de retenção de memória característico do ataque.

Referências