Um invasor remoto sem autenticação pode derrubar muitos servidores web HTTP/3 com uma única conexão. A empresa de segurança FoxIO revelou a falha e publicou um código funcional de prova de conceito.
Ao enviar um pequeno conjunto de cabeçalhos HTTP comprimidos que se expande na memória, o invasor pode fazer o servidor consumir milhares de vezes mais memória do que recebeu. Isso é suficiente para esgotar a memória de um servidor com a configuração padrão.
As falhas permitem apenas ataques de negação de serviço. Não há indícios de roubo de dados ou execução de código, nem relatos públicos de ataques reais. Já foram lançadas correções para quic-go, Cloudflare quiche, lsquic e Wireshark. Na data da divulgação, Bun, a biblioteca h3 para Rust e aioquic ainda não tinham correções.
A FoxIO encontrou a mesma categoria de falha em sete das dez implementações de HTTP/3 testadas. A causa comum está no QPACK, mecanismo usado pelo HTTP/3 para comprimir cabeçalhos de solicitações. Com ele, campos repetidos podem ser transmitidos como códigos curtos, em vez do texto completo.
O servidor deveria limitar o tamanho dos cabeçalhos depois de descompactá-los. As implementações afetadas limitam o conjunto comprimido recebido pela rede, mas não o resultado descompactado, ou aplicam o limite tarde demais. Com isso, uma única solicitação pode se expandir para centenas de milhares de campos de cabeçalho armazenados na memória do servidor.
O impacto pode ser amplo porque essas implementações são usadas por programas populares. quic-go é a biblioteca Go por trás de Caddy, Traefik e cloudflared. lsquic é a biblioteca da LiteSpeed, usada no LiteSpeed Web Server e no OpenLiteSpeed. O servidor HTTP/3 do Bun também usa lsquic.
O invasor não precisa de conta nem de acesso especial. Além disso, como o HTTP/3 funciona sobre o protocolo UDP, a solicitação chega ao servidor antes que muitos dos filtros normalmente usados possam atuar.
Veja quais implementações já haviam sido corrigidas e quais continuavam expostas em 22/10/2026:
| Implementação | Situação | Versão corrigida | Identificador |
|---|---|---|---|
| quic-go | Corrigida | 0.57.0 |
CVE-2025-64702
|
| Cloudflare quiche | Corrigida | 0.29.3 |
CVE-2026-12523
|
| lsquic | Corrigida | 4.9.0 | Sem CVE |
| Wireshark | Corrigida | 4.6.2 / 4.4.12 |
CVE-2025-13945
|
| Bun | Sem correção | Não disponível | Sem CVE |
| h3 (hyperium) | Sem correção | Não disponível | Sem CVE |
| aioquic / mitmproxy | Sem correção | Não disponível | Sem CVE |
Segundo a FoxIO, IIS, Envoy, ngtcp2/nghttp3 e o quiche do Google não são afetados. Essas implementações limitam os cabeçalhos descompactados durante a decodificação, em vez de aplicar o limite depois.
O fator de amplificação varia conforme a implementação, de acordo com os testes da FoxIO com configurações padrão. No quic-go, um conjunto comprimido de 1 MB se expandiu para cerca de 160.000 campos de cabeçalho e ocupou aproximadamente 15 MB de memória durante o processamento da solicitação, cerca de 17 vezes o volume enviado. O próprio comunicado do quic-go estima que a expansão pode chegar a aproximadamente 50 vezes.
Um segundo método produz uma proporção muito maior. O invasor armazena um campo de cabeçalho de cerca de 4 KB e, em seguida, faz referência a ele milhares de vezes usando referências de um byte. O servidor reconstrói o campo completo a cada referência. A FoxIO mediu uma amplificação de cerca de 4.000 vezes no Bun e de 600 a 1.800 vezes no lsquic.
O Bun apresenta um cenário especialmente grave. Seu servidor HTTP/3, descrito na documentação como experimental, usa lsquic, mas substitui por código próprio o trecho que limita a memória usada pelos cabeçalhos. O código verifica cada cabeçalho individualmente, mas não calcula o total acumulado. A FoxIO descobriu que, quando os cabeçalhos descompactados ultrapassam 2 GB, um contador de tamanho nesse código transborda e volta a zero, fazendo o servidor entrar em um ciclo sem fim.
Segundo a FoxIO, um único fluxo que transporta cerca de 516 KB pela rede pode deixar o servidor usando 100% do processador, sem se recuperar e impedindo o atendimento de novas solicitações. A ausência de um limite para o total acumulado permite que o contador transborde. O limite de 64 KB do próprio lsquic impede que isso aconteça.
O problema do Wireshark é diferente das falhas nos servidores. Ele derruba o analisador de HTTP/3, componente que identifica e interpreta esse protocolo em uma captura de tráfego, quando o programa descriptografa o tráfego usando um arquivo de registro de chaves ou abre uma captura que contém segredos de descriptografia. Não se trata de um servidor que o invasor possa alcançar pela rede. O Wireshark afirmou que “não tem conhecimento de exploits para esse problema”.
Os administradores devem atualizar as implementações para as versões corrigidas indicadas acima. Para as que ainda não têm correção, a FoxIO recomenda medidas temporárias: não expor o servidor HTTP/3 do Bun, desativar o HTTP/3 no mitmproxy com o parâmetro `--set http3=false` e definir um limite adequado com `max_field_section_size` na biblioteca h3 para Rust.
A correção do lsquic, lançada em 16/07/2026, limita a quantidade de conjuntos de cabeçalhos descompactados que o servidor mantém por fluxo. O padrão é um conjunto. A FoxIO afirmou que começou a investigar o problema após a pesquisa de Gal Bar Nahum sobre “MadeYouReset”, uma técnica de negação de serviço contra o HTTP/2. O estudo levantou a possibilidade de que a compressão de cabeçalhos do HTTP/3 tivesse uma falha semelhante.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...