Falha explora alocação de memória no HPACK combinada com janela de controle de fluxo zerada, afetando configurações HTTP/2 padrão em NGINX, Apache HTTPD, IIS, Envoy e Cloudflare Pingora.
| Componente | Implementações HTTP/2 padrão em NGINX, Apache HTTPD, Microsoft IIS, Envoy e Cloudflare Pingora, com exploração centrada no HPACK e no controle de fluxo do protocolo. |
| Vetor | Cliente remoto envia requisições HTTP/2 com amplificação de alocação por entradas de cabeçalho quase vazias e mantém a conexão presa com janela de controle de fluxo de zero byte. |
| Impacto | Exaustão de memória e indisponibilidade do servidor; em cenário demonstrado, um único cliente pode manter 32 GB de memória alocados em Apache HTTPD e Envoy em cerca de 20 segundos. |
| Prioridade | Atualizar NGINX para 1.29.8 ou superior e Apache mod_http2 para 2.0.41; quando atualização não for viável, desabilitar HTTP/2 nos serviços expostos conforme a configuração do produto. |
| Versões e correções | NGINX 1.29.8 adiciona max_headers com padrão de 1000; Apache HTTPD recebeu correção no mod_http2 2.0.41; Microsoft IIS, Envoy e Cloudflare Pingora não tinham correção disponível no momento descrito. |
| Limite de atribuição | O contexto descreve uma vulnerabilidade de negação de serviço e não confirma exploração ativa, vazamento de dados, execução remota de código ou movimentação lateral. |
A vulnerabilidade chamada HTTP/2 Bomb descreve uma condição de negação de serviço remota em servidores web que aceitam HTTP/2 com configurações padrão. O problema afeta NGINX, Apache HTTPD, Microsoft IIS, Envoy e Cloudflare Pingora. O ponto técnico central não é uma carga útil volumosa tradicional, mas a combinação entre compressão de cabeçalhos HPACK e retenção de memória por controle de fluxo. O atacante envia dados pequenos no tráfego de rede, força o servidor a criar estruturas internas para muitos cabeçalhos e mantém essas alocações presas ao impedir que a conexão avance normalmente.
A cadeia combina duas ideias conhecidas: uma bomba de compressão e uma retenção no estilo Slowloris. A parte de compressão mira o HPACK, mecanismo usado pelo HTTP/2 para representar cabeçalhos de forma compacta. O comportamento descrito faz com que uma quantidade mínima de bytes recebidos gere uma alocação completa de cabeçalho no servidor, repetida milhares de vezes por requisição. A segunda parte usa uma janela de controle de fluxo de zero byte, impedindo a liberação do material alocado. O resultado é consumo de memória sustentado por conexões que custam pouco para o cliente manter.
O detalhe importante para equipes de segurança é que os limites tradicionais de tamanho total de cabeçalhos podem não capturar essa variante. Em bombas HPACK clássicas, a amplificação costuma aparecer no valor decodificado: um valor grande é colocado na tabela e referenciado repetidamente, o que levou servidores a limitar o tamanho decodificado dos cabeçalhos. Nesta variante, o cabeçalho permanece quase vazio, e a pressão de memória surge da contabilidade por entrada que o servidor precisa manter. Como há pouco conteúdo efetivo a decodificar, o limite baseado apenas em tamanho decodificado pode não ser acionado.
O fluxo começa com uma conexão HTTP/2 contra um servidor vulnerável. Em vez de enviar uma requisição convencional com poucos cabeçalhos úteis, o cliente produz muitas entradas que exploram o custo interno de gerenciamento de cabeçalhos. Cada entrada tem baixo peso no fio, mas obriga o servidor a reservar memória para objetos, metadados ou estruturas de acompanhamento associadas ao processamento de cabeçalhos. A amplificação, portanto, não depende de um corpo grande, de um arquivo transferido ou de um cabeçalho com valor extenso; ela nasce do descompasso entre o tamanho transmitido e o custo de bookkeeping no servidor.
Depois da alocação, a etapa de retenção impede que a memória seja liberada no ritmo esperado. O uso de uma janela de controle de fluxo zerada permite que o cliente mantenha a conexão aberta sem consumir proporcionalmente a mesma quantidade de recursos. Isso transforma uma amplificação que poderia ser transitória em um estado persistente. Enquanto o servidor preserva as estruturas associadas à requisição ou ao fluxo, o cliente mantém o canal em condição de baixo custo. Essa é a semelhança operacional com Slowloris: a pressão não vem apenas de volume bruto, mas de muitas conexões ou fluxos que permanecem incompletos e obrigam o servidor a reservar recursos.
O impacto descrito é severo para disponibilidade. Em um cenário hipotético, um computador doméstico com conexão de 100 Mbps teria capacidade de tornar um servidor vulnerável inacessível em segundos. O contexto também informa que um único cliente pode consumir e manter 32 GB de memória em Apache HTTPD e Envoy em aproximadamente 20 segundos. Esses números indicam que o gargalo observado está na memória do servidor, não na largura de banda do atacante. Não há no contexto confirmação de execução de código, roubo de dados ou comprometimento de contas; a consequência técnica sustentada é negação de serviço por exaustão de memória.
A superfície afetada inclui serviços que expõem HTTP/2 em configurações padrão nos produtos citados. Isso abrange front-ends web, proxies reversos, gateways, balanceadores, serviços de borda e componentes de malha ou roteamento que aceitem conexões HTTP/2 de clientes não confiáveis. Em ambientes modernos, essa camada pode estar tanto no perímetro quanto entre serviços internos. O risco operacional aumenta quando a instância vulnerável é responsável por concentrar tráfego de muitas aplicações, pois a indisponibilidade do proxy ou servidor HTTP pode derrubar múltiplos sistemas dependentes.
As correções e alternativas variam por produto. Para NGINX, a orientação descrita é atualizar para 1.29.8 ou superior, versão que adiciona a diretiva max_headers com valor padrão de 1000. Se a atualização não puder ser aplicada, a mitigação indicada é desabilitar HTTP/2 com a diretiva http2 off;. Para Apache HTTPD, a correção está no mod_http2 2.0.41; quando a atualização não for possível, a alternativa indicada é restringir protocolos para HTTP/1.1 por configuração. Para Microsoft IIS, Envoy e Cloudflare Pingora, o contexto informa que não havia correção disponível no momento da publicação, o que torna controles compensatórios e redução de exposição ainda mais relevantes.
- Servidores NGINX com HTTP/2 habilitado em configuração padrão antes da correção indicada.
- Apache HTTPD usando
mod_http2vulnerável antes da versão 2.0.41. - Microsoft IIS, Envoy e Cloudflare Pingora com HTTP/2 exposto e sem correção disponível no momento descrito.
- Proxies reversos, gateways e componentes de borda que aceitam conexões HTTP/2 diretamente de clientes externos.
A investigação deve se concentrar em sinais de esgotamento de memória associados a sessões HTTP/2, não apenas em picos de tráfego volumétrico. Um evento compatível pode apresentar aumento rápido de uso de memória no processo do servidor web ou proxy, enquanto a largura de banda de entrada permanece relativamente baixa. Esse contraste é relevante porque a técnica se apoia em alta relação entre bytes enviados e memória mantida no servidor. Métricas de processo, número de conexões HTTP/2 abertas, duração de fluxos incompletos e taxa de requisições com muitos cabeçalhos são pontos de observação mais úteis do que somente tráfego total por segundo.
Também é importante diferenciar a atividade de uma sobrecarga legítima de clientes lentos. A presença recorrente de conexões HTTP/2 que permanecem abertas, combinada com janelas de controle de fluxo zeradas e crescimento persistente de memória, deve elevar a prioridade da triagem. Em proxies e balanceadores, compare o comportamento por origem, por rota e por serviço de destino. A exploração descrita pode ser conduzida por um único cliente, então limiares baseados apenas em grandes botnets ou muitas origens podem falhar. A defesa deve procurar padrões de retenção de recursos por conexão e por fluxo.
Quando logs detalhados de HTTP/2 não registrarem internamente HPACK ou controle de fluxo, use telemetria indireta. Quedas de disponibilidade com erro de alocação, reinicializações de worker, encerramento abrupto de processos por pressão de memória e degradação simultânea de múltiplas aplicações atrás do mesmo proxy são sinais compatíveis. Em Apache HTTPD e Envoy, o dado de consumo de 32 GB por um único cliente em cerca de 20 segundos reforça que a janela de resposta é curta; por isso, alertas precisam considerar velocidade de crescimento de memória, não apenas limites absolutos próximos da exaustão.
- Crescimento rápido de memória em processos NGINX, Apache HTTPD, IIS, Envoy ou Pingora durante tráfego HTTP/2 de baixo volume relativo.
- Conexões HTTP/2 mantidas abertas por longos períodos com progresso mínimo de fluxo ou resposta.
- Requisições com grande quantidade de entradas de cabeçalho quase vazias ou pouco conteúdo útil decodificado.
- Eventos de indisponibilidade, reciclagem de workers, falhas de alocação ou degradação do proxy sem aumento proporcional de banda.
- Concentração de conexões suspeitas por uma única origem ou por pequeno conjunto de origens, já que o cenário não depende de alto número de clientes.
A primeira ação defensiva é aplicar as correções disponíveis nos produtos que já têm atualização indicada. Em NGINX, a versão 1.29.8 ou superior introduz limite de cabeçalhos por meio de max_headers, com padrão de 1000, reduzindo a capacidade de multiplicar entradas indefinidamente. Em Apache HTTPD, a correção está no mod_http2 2.0.41. Essas atualizações devem ser tratadas como prioridade de disponibilidade para serviços expostos à internet ou para componentes de borda que concentram tráfego de muitas aplicações.
Quando a atualização não puder ser aplicada imediatamente, a mitigação descrita é desabilitar HTTP/2 nos serviços vulneráveis. No NGINX, isso é feito por configuração com http2 off;. No Apache HTTPD, a alternativa indicada é configurar o serviço para aceitar HTTP/1.1 por meio da diretiva de protocolos. Essa decisão pode afetar desempenho e compatibilidade, mas reduz a superfície específica explorada pela combinação de HPACK e controle de fluxo HTTP/2. Para Microsoft IIS, Envoy e Cloudflare Pingora, como não havia correção disponível no momento informado, a contenção deve priorizar redução de exposição, filtragem de comportamento anômalo e monitoramento agressivo de memória.
Depois da correção ou mitigação, a validação precisa confirmar que HTTP/2 foi realmente atualizado, limitado ou removido da superfície exposta. Inventários devem mapear onde NGINX, Apache HTTPD, IIS, Envoy e Pingora estão em produção, incluindo instâncias usadas como proxy interno, gateway de API ou camada de serviço. Equipes de resposta devem revisar alertas de disponibilidade recentes para identificar episódios de exaustão de memória compatíveis com conexões HTTP/2 mantidas. Como o contexto não confirma exploração ativa, a busca deve ser conduzida como verificação de exposição e possível tentativa de negação de serviço, sem assumir comprometimento de dados.
- Atualizar NGINX para 1.29.8 ou superior e confirmar a presença do limite
max_headers. - Atualizar Apache HTTPD com
mod_http22.0.41 nos servidores que aceitam HTTP/2. - Desabilitar HTTP/2 temporariamente quando a correção não puder ser aplicada com segurança operacional.
- Para IIS, Envoy e Cloudflare Pingora, aplicar controles compensatórios até a disponibilidade de correção, incluindo monitoramento de memória e limitação de conexões suspeitas.
- Revisar inventário de proxies, gateways e servidores de borda para encontrar HTTP/2 exposto em configurações padrão.
0 Comentários