HTTP/2 Bomb no Apache: Guia Definitivo para Verificar, Corrigir e Mitigar em Servidores Debian

 

A vulnerabilidade HTTP/2 Bomb (CVE-2026-49975) permite derrubar servidores Apache com uma única requisição. Veja como verificar, corrigir automaticamente e aplicar mitigações paliativas em Debian – tudo em um guia prático e reutilizável.

Fala, administrador(a) de sistemas! Se você gerencia servidores web, já sabe que boa parte das falhas críticas não são notícia de um dia só – elas viram assunto recorrente, seja porque o ataque foi largamente explorado, seja porque uma parcela significativa dos servidores continua vulnerável por meses. 

O CVE‑2026‑49975, apelidado de "HTTP/2 Bomb", é um desses casos: embora tenha sido descoberto e corrigido em junho de 2026, a vulnerabilidade ainda afeta qualquer servidor Apache HTTP que rode uma versão entre 2.4.17 e 2.4.67 com o módulo HTTP/2 ativado – e que não tenha sido atualizado desde então.

A falha é um dos raros exemplos em que o atacante pode derrubar um servidor a partir de uma única máquina doméstica com 100 Mbps em poucos segundos. Os testes de prova de conceito (PoC) mostram que um cliente malicioso consegue alocar e prender 32 GB de RAM no Apache em aproximadamente 18 segundos, com uma amplificação de cerca de 4.000:1 (um byte enviado vira 4 KB alocados no servidor). 

O mecanismo combina duas técnicas que já eram conhecidas há mais de uma década: uma bomba de compressão HPACK (que explora a tabela dinâmica de cabeçalhos do HTTP/2) e uma trava de controle de fluxo inspirada no Slowloris, que impede o servidor de liberar a memória alocada.

O objetivo deste guia não é apenas reproduzir a notícia, mas oferecer material prático e reutilizável para qualquer pessoa que administre um Apache no Debian. Você vai encontrar:

• Comandos prontos para verificar se seu servidor está vulnerável (ou se já foi corrigido).

• Um script de automação que aplica a correção em todos os servidores da sua rede.

• Mitigações alternativas para quem não pode aplicar a atualização imediatamente – desabilitando HTTP/2 ou usando limites de taxa via iptables e módulos do Apache.

• Uma indicação de leitura complementar (livro afiliado) que aborda de forma ampla a segurança de servidores Linux.

Com essas ferramentas, você conseguirá se proteger agora – e reutilizar o mesmo conhecimento sempre que surgir uma nova vulnerabilidade no Apache ou no protocolo HTTP/2.

Como verificar se você está vulnerável

Antes de aplicar qualquer correção, é prudente confirmar se sua versão do Apache realmente contém a falha. A vulnerabilidade atinge todas as versões do Apache entre 2.4.17 e 2.4.67 que tenham o módulo mod_http2 habilitado e estejam rodando sobre HTTP/2.

1. Verifique a versão do Apache

bash

apache2 -v

O retorno será algo como:

text

Server version: Apache/2.4.67 (Debian)

2. Verifique se o módulo HTTP/2 está ativo

bash

apache2ctl -M | grep http2

Se o comando retornar http2_module (shared), o módulo está carregado, e o servidor pode estar vulnerável.

3. Confirme se o servidor realmente está falando HTTP/2

bash

curl -v --http2 -k https://seudominio.com.br/ 2>&1 | grep -i "using HTTP/2"

Se aparecer > Using HTTP/2.x, então seu servidor aceita conexões HTTP/2.

4. (Opcional) Emita um alerta caso a versão esteja entre as afetadas

Crie um pequeno script de verificação (funciona no Debian):

bash

#!/bin/bash
VERSION=$(apache2 -v | grep "Server version" | awk '{print $3}' | cut -d/ -f2)
if [[ "$VERSION" > "2.4.17" ]] && [[ "$VERSION" < "2.4.67" ]]; then
  echo "⚠️  Apache $VERSION está na faixa vulnerável (2.4.17 - 2.4.67)."
  echo "   Verifique se o módulo http2 está ativo e atualize imediatamente."
else
  echo "✅ Apache $VERSION não está na faixa conhecida como vulnerável."
fi

Guarde esse script como check_http2_bomb.sh e execute‑o periodicamente.

Script de automação para aplicar a correção

Caso você gerencie um ou mais servidores Debian (oldstable, stable ou testing), a correção oficial já está disponível nos repositórios. 

O pacote corrigido inclui o backport do patch que faz com que os cabeçalhos Cookie fragmentados contem corretamente contra o limite LimitRequestFields, impedindo a explosão de memória.

Passos manuais

bash

sudo apt update
sudo apt upgrade apache2
sudo systemctl restart apache2

Após reiniciar, confira novamente se o serviço está rodando sem erros.

Script de automação (para um ou vários servidores)

Crie o arquivo /usr/local/bin/fix_http2_bomb.sh com o seguinte conteúdo:

bash

#!/bin/bash
# fix_http2_bomb.sh – Aplica a correção para CVE-2026-49975 em servidores Debian.
# Execute com privilégios de root ou via sudo.

set -e

LOG_FILE="/var/log/fix_http2_bomb.log"

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" | tee -a "$LOG_FILE"
}

log "Iniciando correção do HTTP/2 Bomb (CVE-2026-49975)..."

# 1. Atualiza a lista de pacotes
apt update >> "$LOG_FILE" 2>&1

# 2. Atualiza apenas o Apache2 (e dependências)
DEBIAN_FRONTEND=noninteractive apt upgrade -y apache2 >> "$LOG_FILE" 2>&1

# 3. Verifica se o módulo http2 ainda está carregado
if apache2ctl -M 2>/dev/null | grep -q "http2_module"; then
    log "Módulo http2 ainda ativo. Nenhuma ação extra necessária."
else
    log "ATENÇÃO: módulo http2 não está mais carregado. Verifique a configuração."
fi

# 4. Reinicia o Apache de forma segura (graceful)
systemctl reload-or-restart apache2 >> "$LOG_FILE" 2>&1

# 5. Testa a versão corrigida
NEW_VERSION=$(apache2 -v | grep "Server version" | awk '{print $3}' | cut -d/ -f2)
log "Correção aplicada. Nova versão do Apache: $NEW_VERSION"

log "Script finalizado com sucesso."
exit 0

Torne o script executável e agende uma execução semanal via cron:

bash

chmod +x /usr/local/bin/fix_http2_bomb.sh
echo "0 3 * * 1 root /usr/local/bin/fix_http2_bomb.sh" > /etc/cron.d/fix_http2_bomb

Esse script pode ser replicado para centenas de servidores usando ferramentas como Ansible ou SSH em massa – ele é idempotente e não quebrará a configuração existente.

📗  Recomendação de Leitura

Segurança em servidores Linux: Ataque e Defesa  (anúncio) -> https://amzn.to/4xjabDS

Se você prefere estudar em português e quer aprender a "pensar como um hacker" para se antecipar a invasões, essa é a pedida! O livro ensina a usar as ferramentas prediletas dos invasores (como Nmap e Netcat) a seu favor, blindando seus sistemas.

Eu ganho uma comissão quando você faz uma compra.

Mitigação alternativa caso não possa atualizar agora

Se você não pode parar o servidor ou aplicar a atualização imediata (por exemplo, por questões de compatibilidade com aplicações legadas), existem três medidas paliativas eficazes:

1. Desabilitar HTTP/2 completamente (recomendado)

Edite o arquivo de configuração global do Apache (geralmente /etc/apache2/apache2.conf ou /etc/apache2/mods-available/http2.conf). Adicione ou modifique a linha:

apache

Protocols http/1.1

Em seguida, desabilite o módulo http2 e reinicie o Apache:

bash

sudo a2dismod http2
sudo systemctl restart apache2

Essa medida é a mais segura porque elimina completamente o vetor de ataque, já que a vulnerabilidade só existe quando o servidor negocia HTTP/2 com o cliente

3. Bloqueio básico com iptables

Para ataques vindos de poucos IPs (por exemplo, testes internos), você pode limitar a quantidade de novas conexões por segundo:

bash

iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -m limit --limit 50/second --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

A primeira regra permite apenas 50 novas conexões por segundo, com um burst de até 200, descartando o excesso. Essa mesma regra pode ser adaptada para a porta 443 se o tráfego HTTPS também for afetado.

Atenção: essas mitigações são paliativas – elas reduzem a superfície de ataque, mas não corrigem a vulnerabilidade subjacente. O certo é aplicar a atualização do pacote assim que possível.

 Conclusão

O CVE-2026-49975 é um lembrete de que protocolos aparentemente maduros ainda escondem fragilidades profundas.

 A combinação de compressão HPACK com controle de fluxo mostrou que uma única requisição maliciosa pode ser 4.000 vezes mais cara para o servidor do que para o atacante, levando a um cenário de negação de serviço catastrófico.

Contudo, você não precisa conviver com esse risco. Adote a rotina de verificação sistemática (script check_http2_bomb.sh), automatize a correção (script fix_http2_bomb.sh) e, se houver impedimentos, aplique mitigações emergenciais como desabilitar HTTP/2 ou limitar novas conexões via iptables.

E, mais importante: mantenha‑se atualizado. O conhecimento sobre a “HTTP/2 Bomb” continuará relevante enquanto existirem servidores Apache 2.4.x com HTTP/2 ativado – e isso deve levar anos para ser erradicado completamente.