Pesquisadores de cibersegurança revelaram dois ataques de negação de serviço, ou DoS, que exploram a forma como grandes redes de distribuição de conteúdo, as CDNs, convertem o tráfego HTTP/3 enviado pelo cliente em requisições HTTP/1.1 para os sites que hospedam. O efeito é uma amplificação de um fluxo de baixa largura de banda em até 350 vezes contra o servidor de origem.
Os ataques, batizados de “CDN Tsunami”, foram testados contra Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly e Tencent.
As seis plataformas se mostraram vulneráveis à variante de amplificação de largura de banda, e cinco à variante de conexão. A Cloudflare não foi afetada pela segunda porque faz o buffer da requisição completa antes de abrir uma conexão com a origem.
Para que o ataque funcione, o site precisa estar hospedado em um dos seis provedores, com HTTP/3 ativo na borda, sem necessidade de mudanças na configuração do próprio site. O estudo diz que o HTTP/3 vem ativado por padrão na Cloudflare e na CloudFront.
No entanto, a documentação da Cloudflare descreve o HTTP/3 como disponível em todos os planos e traz etapas para habilitá-lo, em vez de afirmar que ele está ativado por padrão. Já a documentação da AWS informa que HTTP/2 é a versão padrão para novas distribuições do CloudFront.
O fator de 350 vezes se aplica apenas a Alibaba, Baidu e Tencent. Esses três provedores oferecem suporte à tabela dinâmica do QPACK, e o valor medido ficou em cerca de 64 fluxos simultâneos. Já os máximos observados em Cloudflare, CloudFront e Fastly variaram de 36,41 vezes a 51,2 vezes.
Nenhum identificador CVE foi atribuído, e não há relato de exploração em ambiente real. Embora Baidu e Tencent tenham confirmado os relatórios e implantado as correções propostas, os pesquisadores afirmam que todas as medidas de mitigação foram aplicadas na CDN, e não no site de origem.
As duas técnicas receberam os nomes HTTP/3 Bandwidth Amplification, ou HBA, e HTTP/3 Connection Amplification, ou HCA. Ambas se baseiam na mesma lacuna de implantação, em que a CDN fala HTTP/3 com o navegador, mas apenas HTTP/1.1 com o site por trás dela, uma incompatibilidade que, segundo a equipe, existe porque “as CDNs não suportam HTTP/3 de ponta a ponta”.
A HBA explora o QPACK, o formato de compactação de cabeçalhos introduzido com o HTTP/3. Como o HTTP/1.1 não tem um mecanismo equivalente, a CDN precisa expandir cada pequeno valor de índice recebido de volta para um cabeçalho bruto completo antes de encaminhar a requisição. Na prática, uma requisição que custa poucos bytes ao atacante acaba gerando para a origem o tamanho já descompactado.
A largura de banda usada pelo atacante ficou abaixo de 500 Kbps nas três CDNs com tabela dinâmica e abaixo de 5 Mbps nas demais, enquanto o consumo medido na origem permaneceu acima de 100 Mbps durante todo o teste.
A variante com tabela dinâmica exige que o atacante primeiro envie uma requisição HTTP/3 com um cabeçalho grande, que a CDN insere na tabela, e depois referencie essa entrada repetidas vezes usando pequenos valores de índice. O suporte é limitado a Alibaba, Baidu e Tencent, que anunciam tabela de 4 KB com tamanho máximo de entrada de 3.072 bytes.
Os fatores máximos de amplificação de largura de banda medidos com a tabela estática do QPACK foram os seguintes:
Baidu, 66,06 vezes, com suporte à tabela dinâmica
Alibaba, 65,8 vezes, com suporte à tabela dinâmica
Tencent, 54,08 vezes, com suporte à tabela dinâmica
Amazon CloudFront, 51,2 vezes, sem suporte à tabela dinâmica
Cloudflare, 48,27 vezes, sem suporte à tabela dinâmica
Fastly, 36,41 vezes, sem suporte à tabela dinâmica
A HCA mira a capacidade de conexões, e não a largura de banda. Cinco das seis CDNs abrem uma conexão HTTP/1.1 com a origem assim que recebem o frame HEADERS do HTTP/3, antes da chegada do corpo da requisição. Como o HTTP/3 permite multiplexação, uma única conexão do cliente pode carregar vários fluxos, e cada um deles aciona sua própria conexão TCP no backend. O envio de frames DATA a uma taxa muito baixa mantém essas conexões abertas, enquanto a CDN continua tratando a requisição como incompleta.
Contra um servidor Apache configurado com timeout de 300 segundos e limite de 256 conexões, quatro conexões HTTP/3, cada uma multiplexando 96 fluxos, forçaram 384 conexões no backend. Já a Fastly exigiu 48 conexões de 8 fluxos, porque limita as conexões ao backend a 10 por conexão HTTP/3.
Os tempos de resposta para um cliente legítimo chegaram a 60 segundos na Alibaba e a até 90 segundos na Baidu e no CloudFront, que devolveram HTTP 504 Gateway Timeout. Na Fastly, o tempo subiu para 15 segundos, com retorno de HTTP 503 Service Unavailable.
A Tencent encerrou a conexão do lado do cliente cerca de 10 segundos após receber uma requisição de teste e não retornou resposta.
Os experimentos foram limitados pelos próprios pesquisadores, com a origem restringida a 100 Mbps e o atacante a 30 Mbps. Não há registro de testes acima desses valores. O estudo afirma que os ataques escalam para servidores de maior capacidade, mas essa hipótese não foi verificada.
Também foi observado que o fator de amplificação atinge o pico próximo de 64 fluxos simultâneos e depois cai, algo que os pesquisadores atribuem ao custo de CPU na borda da CDN. No entanto, não foram apresentados dados de uso de CPU na borda.
Para medir a exposição, a equipe enumerou subdomínios na lista Tranco Top 1M, rastreou os registros CNAME e NS, cruzou-os com sufixos conhecidos atribuídos às CDNs e testou cada um com aioquic.
Isso resultou em 151.685 subdomínios hospedados pelas seis plataformas. Desses, 42.330 responderam a uma requisição HTTP/3 e foram classificados como potencialmente vulneráveis, com destaque para CloudFront, com 17.431, Cloudflare, com 12.371, e Fastly, com 11.606. O teste apenas confirma que a borda da CDN responde a HTTP/3 e que nenhum servidor de origem fora do ambiente controlado pelos pesquisadores foi atacado.
No artigo, os resultados são comparados ao CDN Judo, estudo de 2020 sobre a conversão equivalente de HTTP/2 para HTTP/1.1 em CDNs, que relatou fatores de cerca de 44 vezes com a tabela estática e 166 vezes com a tabela dinâmica.
As medidas de mitigação propostas aos fornecedores, todas aplicadas na CDN, são as seguintes:
Limitar o tamanho de qualquer entrada de campo de cabeçalho inserida na tabela dinâmica do QPACK, com sugestão de 512 bytes
Restringir quantas vezes uma entrada da tabela dinâmica pode ser referenciada em um único fluxo, com sugestão de no máximo 10
Impor um tamanho máximo para requisições HTTP/1.1 descompactadas e rejeitar qualquer valor acima desse limite antes do encaminhamento, com sugestão de 64 KB
Fazer o buffer da requisição HTTP/3 completa, incluindo os frames HEADERS e DATA, antes de abrir uma conexão entre a CDN e a origem
Limitar o número de conexões entre a CDN e a origem que uma única conexão HTTP/3 do cliente pode acionar
Aplicar timeout às conexões entre a CDN e a origem de forma independente da conexão do cliente, com sugestão de 30 segundos sem dados encaminhados de forma significativa
Segundo a seção de divulgação do artigo, a Tencent já implantou mitigação que limita o número de conexões entre a CDN e a origem e restringe o tamanho dos cabeçalhos na tabela dinâmica. O texto também registra recompensas de bug bounty de cerca de US$ 350 da Baidu e US$ 150 da Tencent.
A mesma seção diz que os outros quatro fornecedores reconheceram a divulgação e ainda discutiam os achados internamente. O artigo não informa se os ataques foram testados novamente após as mitigações da Baidu e da Tencent, nem se o código do ataque ou a estrutura de medição será publicada.
O trabalho é assinado por pesquisadores da National University of Singapore, da Fuzhou University, da University of Sheffield e da Johns Hopkins University. A apresentação está prevista para o Symposium on Reliable Distributed Systems, em Roma, de 22 a 24 de setembro de 2026.
A tabela dinâmica do QPACK também foi alvo de outra falha, divulgada em 8 de julho, quando o pesquisador da FoxIO Sébastien Féry relatou que cerca de 260 bytes de tráfego QPACK em conformidade com a especificação poderiam derrubar qualquer servidor que executasse XQUIC, a biblioteca de QUIC e HTTP/3 da Alibaba, que fornece suporte a HTTP/3 para o servidor web Tengine usado pela empresa em sua infraestrutura de cloud e CDN.
A divulgação ocorre poucos dias depois de o OpenSSL Project informar, em 13 de agosto, a
CVE-2026-14456
, uma falha de baixa gravidade em que um servidor QUIC enfileira canais de entrada para identificadores de conexão de destino desconhecidos sem impor limite algum. A correção introduz um limite para conexões pendentes, definido por padrão em 256.
Na mesma semana, a Cloudflare afirmou em seu relatório H1 2026 DDoS Threat Report que o “centro de gravidade do vetor de ataque mudou de enchentes de botnet para reflexão e amplificação”, com ataques baseados em DNS respondendo por 34,3% de toda a atividade na camada de rede no primeiro semestre de 2026.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...