HTTP/2 Bomb: Nova DoS Attack Esgota Servidores Web em Segundos
Uma nova e potente ataque de negação de serviço (DoS), apelidada de HTTP/2 Bomb, está aterrorizando servidores web populares. A técnica explora vulnerabilidades no protocolo HTTP/2, combinando compressão HPACK e a tática Slowloris para consumir gigabytes de memória em instantes.
MundiX News·05 de junho de 2026·5 min de leitura·👁 19 views
Especialistas da Calif apresentaram uma nova ameaça de negação de serviço (DoS) denominada HTTP/2 Bomb, que afeta servidores web e proxies amplamente utilizados, incluindo nginx, Apache HTTP Server, Microsoft IIS, Envoy e Cloudflare Pingora. Este ataque inovador combina duas técnicas já conhecidas, permitindo que uma única máquina esgote rapidamente dezenas de gigabytes de memória em um servidor.
De acordo com os pesquisadores, a vulnerabilidade reside na configuração padrão do HTTP/2 e não está ligada a uma implementação específica do protocolo. É notável que a descoberta desta falha foi auxiliada pelo OpenAI Codex, que facilitou a fusão de duas técnicas de ataque já existentes. A HTTP/2 Bomb baseia-se na combinação da compressão HPACK e da técnica Slowloris. A primeira parte é responsável por um aumento drástico no consumo de memória, enquanto a segunda impede que o servidor libere essa memória alocada.
O ataque explora o mecanismo HPACK, um algoritmo de compressão de cabeçalhos HTTP/2. Um atacante insere um registro na tabela dinâmica HPACK e, em seguida, refere-se a ele repetidamente usando uma entrada de índice de apenas um byte. Consequentemente, um byte de tráfego de entrada pode forçar o servidor a alocar milhares de bytes de memória. Nos testes realizados pelos pesquisadores, o Envoy e o Apache HTTP Server apresentaram os piores resultados, com coeficientes de amplificação atingindo aproximadamente 5700:1 e 4000:1, respectivamente. No entanto, a característica crucial da HTTP/2 Bomb não é a compressão em si. Os especialistas explicam que um servidor normalmente libera a memória alocada após a conclusão de uma requisição. Para evitar isso, o atacante define o tamanho da janela de controle de fluxo (flow-control window) para zero. Isso impede que a requisição seja totalmente concluída, e a memória ocupada permanece vinculada à conexão.
Os autores do estudo afirmam que é a combinação desses dois mecanismos que torna o ataque tão perigoso. Limitações no tamanho dos cabeçalhos decodificados não oferecem proteção contra a HTTP/2 Bomb, pois os próprios cabeçalhos permanecem pequenos. A carga principal recai sobre as estruturas internas que o servidor cria para processar cada entrada. Testes práticos demonstraram que até mesmo um PC doméstico comum com uma conexão de 100 Mbps é capaz de derrubar um servidor vulnerável em questão de segundos. Por exemplo, no caso do Apache HTTP Server e do Envoy, um único cliente pode ocupar e reter cerca de 32 GB de memória em aproximadamente 20 segundos. Durante os testes, os pesquisadores obtiveram os seguintes resultados: Envoy 1.37.2 esgotou 32 GB de memória em cerca de 10 segundos; Apache httpd 2.4.67 em 18 segundos; nginx 1.29.7 em aproximadamente 45 segundos; Microsoft IIS no Windows Server 2025 ocupou 64 GB de memória em cerca de 45 segundos.
Os detalhes técnicos completos da HTTP/2 Bomb serão divulgados pelos especialistas ainda este mês na conferência Real World AI Security. No entanto, o código de prova de conceito (PoC) já foi publicado. É importante notar que o problema no nginx foi corrigido na versão 1.29.8, com a introdução de um novo parâmetro, max_headers. A correção para o Apache HTTPD foi incluída no mod_http2 2.0.41 e o problema recebeu o identificador CVE-2026-49975. Para Microsoft IIS, Envoy e Cloudflare Pingora, ainda não há patches disponíveis. Proprietários desses sistemas são aconselhados a desativar o HTTP/2 sempre que possível, ou a implementar um proxy ou firewall na frente do servidor com restrições rigorosas na quantidade de cabeçalhos. Além disso, a proteção pode ser fornecida por CDNs, reverse proxies, WAFs e configurações de servidor não padrão que impeçam o acesso direto ao endpoint HTTP/2 vulnerável.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Especialistas da Calif apresentaram uma nova ameaça de negação de serviço (DoS) denominada HTTP/2 Bomb, que afeta servidores web e proxies amplamente utilizados, incluindo nginx, Apache HTTP Server, Microsoft IIS, Envoy e Cloudflare Pingora. Este ataque inovador combina duas técnicas já conhecidas, permitindo que uma única máquina esgote rapidamente dezenas de gigabytes de memória em um servidor.
De acordo com os pesquisadores, a vulnerabilidade reside na configuração padrão do HTTP/2 e não está ligada a uma implementação específica do protocolo. É notável que a descoberta desta falha foi auxiliada pelo OpenAI Codex, que facilitou a fusão de duas técnicas de ataque já existentes. A HTTP/2 Bomb baseia-se na combinação da compressão HPACK e da técnica Slowloris. A primeira parte é responsável por um aumento drástico no consumo de memória, enquanto a segunda impede que o servidor libere essa memória alocada.
O ataque explora o mecanismo HPACK, um algoritmo de compressão de cabeçalhos HTTP/2. Um atacante insere um registro na tabela dinâmica HPACK e, em seguida, refere-se a ele repetidamente usando uma entrada de índice de apenas um byte. Consequentemente, um byte de tráfego de entrada pode forçar o servidor a alocar milhares de bytes de memória. Nos testes realizados pelos pesquisadores, o Envoy e o Apache HTTP Server apresentaram os piores resultados, com coeficientes de amplificação atingindo aproximadamente 5700:1 e 4000:1, respectivamente. No entanto, a característica crucial da HTTP/2 Bomb não é a compressão em si. Os especialistas explicam que um servidor normalmente libera a memória alocada após a conclusão de uma requisição. Para evitar isso, o atacante define o tamanho da janela de controle de fluxo (flow-control window) para zero. Isso impede que a requisição seja totalmente concluída, e a memória ocupada permanece vinculada à conexão.
Os autores do estudo afirmam que é a combinação desses dois mecanismos que torna o ataque tão perigoso. Limitações no tamanho dos cabeçalhos decodificados não oferecem proteção contra a HTTP/2 Bomb, pois os próprios cabeçalhos permanecem pequenos. A carga principal recai sobre as estruturas internas que o servidor cria para processar cada entrada. Testes práticos demonstraram que até mesmo um PC doméstico comum com uma conexão de 100 Mbps é capaz de derrubar um servidor vulnerável em questão de segundos. Por exemplo, no caso do Apache HTTP Server e do Envoy, um único cliente pode ocupar e reter cerca de 32 GB de memória em aproximadamente 20 segundos. Durante os testes, os pesquisadores obtiveram os seguintes resultados: Envoy 1.37.2 esgotou 32 GB de memória em cerca de 10 segundos; Apache httpd 2.4.67 em 18 segundos; nginx 1.29.7 em aproximadamente 45 segundos; Microsoft IIS no Windows Server 2025 ocupou 64 GB de memória em cerca de 45 segundos.
Os detalhes técnicos completos da HTTP/2 Bomb serão divulgados pelos especialistas ainda este mês na conferência Real World AI Security. No entanto, o código de prova de conceito (PoC) já foi publicado. É importante notar que o problema no nginx foi corrigido na versão 1.29.8, com a introdução de um novo parâmetro, max_headers. A correção para o Apache HTTPD foi incluída no mod_http2 2.0.41 e o problema recebeu o identificador CVE-2026-49975. Para Microsoft IIS, Envoy e Cloudflare Pingora, ainda não há patches disponíveis. Proprietários desses sistemas são aconselhados a desativar o HTTP/2 sempre que possível, ou a implementar um proxy ou firewall na frente do servidor com restrições rigorosas na quantidade de cabeçalhos. Além disso, a proteção pode ser fornecida por CDNs, reverse proxies, WAFs e configurações de servidor não padrão que impeçam o acesso direto ao endpoint HTTP/2 vulnerável.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.