XRING: Falha sem patch em XQUIC da Alibaba derruba servidores HTTP/3 com 260 bytes

Uma falha de uma única linha na XQUIC, biblioteca QUIC e HTTP/3 mantida pela Alibaba, permite que qualquer cliente remoto derrube servidores com uma rajada curta de tráfego perfeitamente legal. Batizada de XRING e divulgada em 8 de julho pelo pesquisador Sebastien Fery, da FoxIO, a vulnerabilidade não tem patch, não tem CVE atribuído e afeta todas as versões publicadas desde janeiro de 2022, incluindo a mais recente v1.9.4. Bastam cerca de 260 bytes de QPACK bem-formado para matar o processo do servidor.

O que aconteceu

A FoxIO tornou pública a falha depois de tentar cinco vezes contato com a equipe de segurança da Alibaba entre 7 de abril e 9 de maio sem obter resposta, quebrando a promessa de retorno em três dias úteis prevista na política de divulgação do próprio projeto. O bug afeta a XQUIC, biblioteca open-source usada dentro do Tengine, o servidor web derivado do Nginx que fronta grande parte da infraestrutura de nuvem e CDN da Alibaba, incluindo Taobao e Alipay.

Como a XQUIC é aberta, o alcance do problema vai muito além da própria Alibaba. Qualquer servidor que embarque a biblioteca e sirva HTTP/3 com a configuração padrão de QPACK fica exposto a negação de serviço remota sem autenticação. Até o momento da publicação, não há release corrigida nem número de CVE oficial.

Uma prova de conceito circula publicamente. A FoxIO demonstrou apenas o crash, sem execução de código, e afirma não ter observado exploração ativa. Ainda assim, a combinação de PoC pública, ausência de patch e superfície de ataque exposta na internet caracteriza janela de risco imediata para operadores.

Detalhes tecnicos da vulnerabilidade

O bug vive no coracao da compressao de cabecalhos do HTTP/3. Para evitar reenviar headers repetidos como user-agent em cada request, o protocolo usa o QPACK, que mantem uma tabela dinamica compartilhada entre cliente e servidor. O cliente comanda o crescimento e o redimensionamento dessa tabela atraves de um canal dedicado, o encoder stream.

A XQUIC armazena a tabela em um ring buffer, area fixa de memoria em que os dados sao gravados em ciclo, voltando ao inicio quando enchem. Quando o cliente pede para aumentar a tabela, a biblioteca aloca um buffer maior e copia os dados antigos. Essa copia tem quatro casos, dependendo de onde os dados enrolam no buffer antigo, no novo, em ambos ou em nenhum.

Em um desses casos, o codigo compara o tamanho da cauda residual dos dados com a capacidade do buffer NOVO em vez do antigo. O calculo estoura para cima: aumentar uma tabela de 64 bytes com o cursor de escrita perto do fim para 65 bytes leva a XQUIC a acreditar que precisa mover 70 bytes de cauda, quando na verdade sao apenas 6. Esse numero errado alimenta uma operacao de memoria que corrompe a heap e derruba o processo.

“Nenhum dos valores do ataque quebra as regras do QPACK. A XQUIC anuncia por padrao um limite de tabela dinamica de 16 KiB; o payload pede 64 bytes, depois 65. O cliente so precisa levar a tabela para o layout exato que atinge o ramo defeituoso.”

Sebastien Fery, FoxIO

Quem esta em risco

O impacto se distribui por qualquer ambiente que atenda HTTP/3 usando XQUIC com QPACK dinamico ativo, o que inclui:

• Servidores Tengine expostos ao publico, incluindo os que atendem propriedades da Alibaba Cloud e do ecossistema Alipay/Taobao
• CDNs, edge proxies e balanceadores customizados que embarcaram a XQUIC como stack QUIC
• Aplicacoes internas que ativaram HTTP/3 em produtos derivados sem revisar a origem da biblioteca
• Ambientes de teste e homologacao com HTTP/3 habilitado por padrao, que podem servir como pivot para reconhecimento

Cada crash desmonta o processo servidor e forca reinicializacao. Em cenarios com autoescalonamento, um atacante pode manter um ciclo continuo de derrubadas com custo trivial, drenando capacidade e disparando alertas de infraestrutura em cascata.

Analise

A XRING nao existe no vacuo. Ha tres semanas, a comunidade rastreou a CVE-2026-42530, um use-after-free no modulo HTTP/3 do NGINX explorado exatamente pelo mesmo canal QPACK que a nova falha abusa. Em junho, o Calif HTTP/2 Bomb derrubou remotamente Nginx, Apache, IIS e Envoy atraves da compressao HPACK. Em fevereiro, a HAProxy corrigiu dois crashes de QUIC, um deles com o mesmo padrao de estouro aritmetico visto agora na XQUIC, embora exigisse pacote malformado.

O padrao e claro: a superficie de compressao de headers em HTTP/2 e HTTP/3 esta se firmando como categoria consistente de vulnerabilidade critica de disponibilidade, com bugs recorrentes de baixa complexidade e alto impacto. Times de seguranca que ainda tratam HTTP/3 como “nova onda experimental” precisam recalibrar prioridades: a stack ja e alvo maduro, com PoCs publicas circulando e disclosure processes das grandes plataformas visivelmente tensionados.

Chama atencao tambem o silencio da Alibaba durante 32 dias em cinco tentativas de contato. E um sinal preocupante para quem depende de bibliotecas mantidas por gigantes de nuvem sem SLA formal de resposta a divulgacao coordenada. Vale revisar contratualmente esse ponto em ambientes regulados.

Recomendacoes praticas

• Auditar o inventario de servidores web e proxies para identificar toda instalacao de Tengine ou binarios que embarcam a XQUIC diretamente
• Como mitigacao imediata, ajustar SETTINGS_QPACK_MAX_TABLE_CAPACITY para 0, desativando a tabela dinamica do QPACK enquanto nao ha patch
• Considerar desabilitar HTTP/3 (Alt-Svc, cabecalhos QUIC) em edges publicos ate o vendor liberar release oficial corrigida
• Monitorar conexoes QUIC/HTTP/3 com contagem de reinicializacoes de processo por origem para detectar tentativas de exploracao
• Adicionar regras em WAF/edge para inspecionar payloads QPACK anomalos que resizeiem a tabela para valores proximos a bordas de ring buffer
• Rastrear listas de CVE e o repositorio da XQUIC no GitHub para aplicar o patch assim que sair, priorizando cargas expostas a internet

Fonte: The Hacker News