O problema do QPACK no HTTP/3 mostra como velocidade amplia a superfície de ataque

E se a próxima melhoria de desempenho da web também desse aos atacantes uma maneira mais barata de fazer os servidores consumirem recursos? Essa é a pergunta incômoda por trás dos relatos mais recentes de amplificação via QPACK. O HTTP/3 não está falhando porque sua ideia central seja equivocada. Em parte, ele falha porque toda otimização cria novos estados, novas camadas de tradução e novas premissas que os defensores precisam compreender.

O problema imediato é uma classe de ataques contra o QPACK, o mecanismo de compressão de cabeçalhos do HTTP/3. A FoxIO relata que um cliente remoto não autenticado pode fazer um servidor HTTP/3 alocar dezenas a milhares de vezes mais memória do que o volume de tráfego enviado. Essa assimetria é alarmante, mas a lição mais ampla importa mais que a manchete: protocolos modernos podem amplificar não apenas o tráfego de rede, mas também o trabalho de análise, a pressão sobre a memória e a complexidade operacional.

Um estudo separado de 2026 chega à mesma conclusão na fronteira da infraestrutura. Pesquisadores encontraram fragilidades na conversão de HTTP/3 para HTTP/1.1 em seis grandes provedores de CDN; na avaliação, os seis estavam vulneráveis a uma variante de amplificação de largura de banda, e cinco, a uma variante de amplificação de conexões. Os pesquisadores identificaram 42.330 subdomínios potencialmente vulneráveis e afirmaram que dois fornecedores de CDN reconheceram vulnerabilidades, concederam recompensas por bugs e implementaram medidas de mitigação, segundo o estudo. Essas são descobertas de pesquisa, não evidências de que toda implantação de HTTP/3 esteja exposta hoje — mas mostram como um recurso pode se tornar uma responsabilidade quando os sistemas dos dois lados de um gateway falam versões diferentes da web.

O HTTP/3 não eliminou a complexidade; apenas a transferiu para lugares mais difíceis

O apelo do HTTP/3 é real. Ele funciona sobre o QUIC, em vez do TCP, combinando funções relacionadas ao transporte e ao TLS e permitindo fluxos multiplexados. O projeto pretende resolver problemas de transporte, como o bloqueio de início de fila, e reduzir a latência de conexão. A Cloudflare observou o HTTP/3 alcançar 28% do tráfego analisado até maio de 2023, depois de subir de pouco mais de 23% em maio de 2022.

Mas desempenho, por si só, não é uma propriedade de segurança. O QUIC normalmente funciona no espaço do usuário sobre UDP, o que muda o que os controles de rede tradicionais conseguem enxergar e gerenciar. Sem a terminação de QUIC e TLS, dispositivos intermediários não conseguem inspecionar completamente solicitações HTTP/3, cabeçalhos ou a lógica do aplicativo. Eles ainda podem usar endereços IP, portas, taxas de pacotes, tamanhos de datagramas e padrões de fluxo, mas a visibilidade familiar de uma pilha centrada em TCP já não é suficiente.

O QPACK acrescenta outra camada de estado. A compressão é valiosa porque cabeçalhos repetidos não precisam ser transmitidos por completo, mas as representações comprimidas precisam ser decodificadas com base em estruturas compartilhadas, como tabelas dinâmicas. Se uma implementação lida mal com fluxos bloqueados ou criados para explorar a falha, uma entrada pequena pode exigir uma quantidade desproporcional de memória ou processamento. Na nossa avaliação, isso não é uma categoria incidental de bug. É o custo previsível de segurança de tornar o protocolo mais eficiente por meio de mecanismos com estado.

A lacuna mais perigosa está entre o projeto do protocolo e a realidade da implantação

A pesquisa sobre CDNs é especialmente importante porque o ataque não depende apenas de uma falha em uma implementação de servidor. Ele explora um descompasso: uma conexão HTTP/3 eficiente que chega a uma CDN pode ser convertida em tráfego HTTP/1.1 menos eficiente na direção da origem. A borda entende um modelo de desempenho; o back-end absorve outro.

Isso deveria mudar a forma como as organizações avaliam atualizações de protocolo. “Ativamos o HTTP/3 na borda” não é uma descrição completa da arquitetura. Os operadores também precisam perguntar o que acontece entre a borda e a origem, onde os cabeçalhos são expandidos, como a duração das conexões é controlada e qual componente é responsável pelos limites de taxa. Uma porta de entrada segura ainda pode virar um amplificador se a camada de tradução for tratada como encanamento, e não como superfície de ataque.

O mesmo princípio se aplica ao QPACK. Um servidor pode estar perfeitamente acessível e negociar o HTTP/3 corretamente, mas ainda apresentar um comportamento perigoso no uso de recursos diante de sequências incomuns de compressão. Por isso, os testes de segurança precisam medir mais do que a rejeição de entradas malformadas. Eles devem medir quanta memória, CPU, capacidade de conexão e tráfego downstream são consumidos antes da rejeição.

“É só desativar o HTTP/3” é uma mitigação, não uma estratégia

Os operadores têm, sim, uma opção brusca: bloquear a porta UDP 443 e eliminar o HTTP/3 durante um incidente. Mas isso também remove o HTTP/3 para usuários legítimos. Controles mais direcionados — limites de taxa, filtragem de pacotes malformados, validação de versão, validação de endereço e mitigação upstream — podem reduzir a exposição sem retirar o protocolo de todo mundo.

Essa distinção importa porque desativar um protocolo pode esconder fragilidades arquiteturais, em vez de corrigi-las. Se a origem não consegue tolerar o tráfego traduzido, ou se uma implementação não consegue limitar o uso de memória relacionado ao QPACK, a mesma fragilidade pode reaparecer quando o HTTP/3 for ativado novamente. A resposta correta não é ter medo permanente do QUIC; é adotar uma disciplina de implantação que trate o esgotamento de recursos como um problema central de funcionamento correto.

As divulgações recentes também deveriam desestimular classificações simplistas de gravidade. Um ataque não precisa ser trivial para ser relevante. Uma técnica que exige conhecimento especializado ainda pode ser valiosa para um atacante se funcionar contra uma infraestrutura compartilhada, afetar muitos locatários ou forçar os defensores a adotar uma resposta cara do tipo tudo ou nada. Por outro lado, um grande número teórico de amplificação não significa automaticamente comprometimento universal. A exposição depende da implementação, da configuração, dos controles de tráfego e do caminho exato entre o cliente, a CDN e a origem.

Nosso veredito é direto: o HTTP/3 continua valendo a pena, mas apenas onde toda a cadeia de recursos puder ser observada e testada. As organizações devem inventariar cada implementação de QUIC e HTTP/3, revisar os limites do QPACK e dos fluxos, testar a tradução entre CDN e origem e garantir que seu monitoramento consiga distinguir ataques de inundação via UDP de abusos na camada de aplicação. Os vencedores não serão as equipes que adotarem o protocolo mais novo primeiro. Serão as equipes capazes de explicar, em detalhes, o que o protocolo faz sua infraestrutura executar quando a entrada é hostil.