Uma falha batizada de XRING na biblioteca XQUIC, da Alibaba, permite que qualquer cliente remoto e sem autenticação derrube servidores HTTP/3 enviando aproximadamente 260 bytes de tráfego QPACK perfeitamente legítimo. A vulnerabilidade, divulgada em 8 de julho de 2026 pelo pesquisador Sébastien Féry, da FoxIO, afeta todas as versões públicas do XQUIC desde o primeiro lançamento em janeiro de 2022 até a atual v1.9.4. Não existe correção disponível.
A XQUIC é uma biblioteca open-source em C, lançada pela Alibaba no GitHub sob licença Apache 2.0, que implementa os protocolos QUIC e HTTP/3 definidos pela IETF.
A falha de uma linha
O XRING reside no gerenciamento do buffer circular (ring buffer) que o XQUIC usa para armazenar a tabela dinâmica do QPACK. O QPACK é o mecanismo de compressão de cabeçalhos do HTTP/3, equivalente ao HPACK do HTTP/2, e mantém uma tabela dinâmica compartilhada entre cliente e servidor para evitar retransmissão de campos repetidos.
O cliente controla a tabela do servidor por meio de um fluxo QUIC dedicado chamado encoder stream, enviando instruções para inserir entradas, remover antigas e redimensionar a tabela. Quando o cliente solicita o aumento da capacidade, o XQUIC aloca um novo buffer, arredondado para a próxima potência de dois, e copia os dados vivos do buffer antigo para o novo.
A cópia possui quatro cenários possíveis, conforme a distribuição dos dados nos buffers antigo e novo. Três deles estão corretos; o quarto, quando ambos os buffers contêm dados truncados, usa a variável errada.
O código calcula o tamanho dos dados na cauda do buffer antigo usando a variável mcap, que representa a nova capacidade, quando deveria usar a capacidade original. Esse erro de uma única variável faz com que o tamanho calculado seja maior que o próprio buffer de origem.
O valor exagerado alimenta três chamadas consecutivas de memcpy. A segunda lê 64 bytes além da alocação antiga. A terceira subtrai o valor inflado de um número menor; como o tipo size_t é sem sinal, a subtração produz um underflow de inteiro que resulta em um tamanho próximo ao máximo representável. A cópia subsequente escreve além dos limites do buffer alocado, e em sistemas com a proteção _FORTIFY_SOURCE=2 da glibc, o processo é terminado como medida de segurança.
Como o ataque funciona
A exploração não exige credenciais, pacotes malformados nem conhecimento técnico avançado. O tráfego enviado pelo atacante é totalmente compatível com a especificação QPACK, cada byte está dentro dos limites anunciados pelo servidor.
O XQUIC define SETTINGS_QPACK_MAX_TABLE_CAPACITY como 16 KiB por padrão, e o payload do ataque solicita tabelas de 64 e depois 65 bytes, valores bem abaixo do limite permitido. O cliente precisa apenas conduzir a tabela dinâmica até o estado exato de wrapped que atinge o ramo defeituoso.
Na prática, o atacante insere 61 entradas de dois bytes em uma tabela de 64 bytes, avançando o cursor de escrita até o offset 58. Uma entrada de 10 bytes então escreve 6 bytes na cauda e 4 no início do buffer, criando o layout truncado. Um aumento da capacidade para 65 bytes dobra a alocação para 128 enquanto os dados permanecem truncados, entrando no ramo com bug.
Um código de prova de conceito foi publicado no GitHub pela FoxIO, permitindo reprodução imediata por qualquer operador ou atacante. O PoC demonstra que aproximadamente 260 bytes de tráfego de cliente bastam para derrubar o processo do servidor.
Quem está vulnerável
O XQUIC é a biblioteca de código aberto que habilita suporte a HTTP/3 no Tengine, o servidor web derivado do Nginx mantido pela Alibaba e usado em serviços como Taobao e Alipay. Qualquer servidor que incorpore o XQUIC com as configurações padrão de QPACK herda a mesma exposição.
Por ser distribuída sob licença Apache 2.0 no GitHub, a biblioteca pode estar embutida em produtos de terceiros. A população de organizações afetadas é invisível de fora, e implantações que habilitaram a tabela dinâmica do QPACK com a configuração padrão estão expostas mesmo sem conhecer o XQUIC pelo nome.
Como mitigar agora
Sem correção do fabricante, os operadores devem aplicar controles compensatórios imediatamente em qualquer serviço voltado para a internet que incorpore o XQUIC:
| Medida | Como aplicar | Efeito colateral |
|---|---|---|
| Desativar tabela dinâmica QPACK | Definir SETTINGS_QPACK_MAX_TABLE_CAPACITY como 0, desativando a tabela dinâmica do QPACK e eliminando o caminho de código vulnerável | Reduz compressão de cabeçalhos; mantém HTTP/3 |
| Desativar HTTP/3 | Remover suporte ao protocolo no servidor | Volta para HTTP/2 ou HTTP/1.1 |
A identificação de servidores afetados pode usar fingerprints JA4Scan-QUIC divulgados pela FoxIO, que mapeiam builds do XQUIC em infraestruturas públicas. O monitoramento de logs deve incluir detecção de quedas anômalas de processos HTTP/3, conforme abordado em nosso guia de monitoramento de logs na defesa digital.
Contexto e divulgação
A FoxIO contatou a Alibaba em 7 de abril de 2026 pelo canal designado na política de segurança do XQUIC, que compromete resposta em três dias úteis. Após cinco mensagens de acompanhamento enviadas entre 17 de abril e 9 de maio sem obter resposta, a FoxIO decidiu divulgar a vulnerabilidade publicamente em 8 de julho.
O caso ilustra um padrão recorrente de risco em bibliotecas de transporte compartilhadas: um componente que poucas equipes de segurança conhecem pelo nome, embutido em produtos usados diariamente, cujos defeitos não aparecem nos feeds de avisos que a maioria das organizações monitora. A CVE-2026-6328, atribuída ao XQUIC pela própria Alibaba em abril de 2026, tratava de validação inadequada de entrada e verificação de assinatura criptográfica no processamento de frames QUIC, afetando versões até 1.8.3.
A priorização de vulnerabilidades sem CVE atribuído é um desafio operacional. Diferente das correções do Patch Tuesday de julho de 2026, que seguem fluxos padronizados, falhas como o XRING exigem acompanhamento de fontes técnicas especializadas e aplicação imediata de controles compensatórios.