Unpatched XRING Bug in Alibaba's XQUIC Lets Attackers Crash Servers With 260 Bytes

A newly disclosed critical unpatched vulnerability in XQUIC, Alibaba’s open-source QUIC and HTTP/3 library, allows a remote, unauthenticated attacker to crash server processes using nothing more than 260 bytes of spec-compliant traffic.

Dubbed XRING, the flaw affects every released version of XQUIC and has no available fix, leaving the infrastructure powering Tengine, the Nginx-based web server backing Alibaba’s cloud and CDN services, including Taobao and AliPay, exposed to trivial denial-of-service attacks.

The discovery came out of research into QUIC stack fingerprinting for JA4Scan, an active TLS and QUIC scanning tool from FoxIO. During testing, researchers found that a single miscoded variable in XQUIC’s dynamic table resize logic could be weaponized into a full remote crash.

Unpatched XRING Bug in Alibaba’s XQUIC

HTTP/3 relies on QPACK to compress repeated headers, such as user-agent, into small index references rather than full strings. QPACK uses two tables: a static table hardcoded by the specification, and a dynamic table built at runtime as client and server exchange headers.

Clients control this dynamic table over a dedicated QUIC encoder stream, issuing instructions to insert entries, evict old ones, or resize the table’s capacity.

XQUIC implements this dynamic table using a ring buffer. When live data spans the buffer’s boundary, entries “wrap” a state XQUIC calls a truncated layout. Resizing the table when both the old and new buffers are in this truncated state triggers the vulnerable code path.

The resize function xqc_ring_mem_resize handles four branching scenarios based on buffer layout. Three are correct. The fourth, where both old and new buffers hold truncated data, contains the bug:

size_t ori_sz1 = mcap - soffset_ori;

This line should reference the original buffer capacity, not mcap, the new capacity. Since XQUIC rounds allocations up to the next power of two, growing a table from 64 to 65 bytes triggers an allocation jump to 128 bytes. The miscalculated ori_sz1 then becomes far larger than the actual old buffer, feeding an oversized value into three chained memcpy calls.

The second memcpy reads 64 bytes past the old allocation. The third computes its length as used - ori_sz1 and because ori_sz1 exceeds used and size_t is unsigned, this arithmetic underflows to a near-maximum value, turning a routine copy into a runaway heap write that crashes the process.

Triggering XRING requires no malformed packets, only carefully timed, spec-compliant QPACK instructions. Per RFC 9204, each dynamic table entry consumes name_len+value_len+32 bytes, so a 64-byte table holds exactly one 2-byte entry at a time. Repeating inserts 61 times positions the ring buffer’s write cursor 6 bytes from the boundary. ‘

A subsequent 10-byte insert wraps the buffer into a truncated state. Requesting a resize to 65 bytes, doubling the allocation to 128, lands squarely in the buggy branch, all while staying within XQUIC’s default 16 KiB capacity limit.

Mitigation

Until a patch ships, administrators can neutralize the bug by setting SETTINGS_QPACK_MAX_TABLE_CAPACITY to 0, disabling the dynamic table entirely.

Researchers reported the issue to Alibaba in April 2026 through the project’s SECURITY.md contact and GitHub’s vulnerability form, followed by multiple unanswered follow-ups through May. With no response after three months, the team published the findings on July 8, along with proof-of-concept code on GitHub.

Organizations running Tengine or XQUIC-based services can identify exposed servers using JA4Scan-QUIC fingerprints, now integrated into SecurityScorecard’s Driftnet.io platform, with support coming to Cortex Xpanse, Censys, and other EASM tools.