XRING: 260 bytes, no patch, three months of Alibaba silence

FoxIO researcher Sébastien Féry published the XRING writeup on July 8 after a three-month disclosure standoff with Alibaba’s security team. The finding is a single integer underflow in the QPACK header-compression ring-buffer resize logic of Alibaba’s XQUIC library, the open-source QUIC and HTTP/3 stack that ships in Alibaba’s Tengine web server and runs in front of, among other things, Taobao and Alipay. About 260 bytes of spec-compliant QPACK traffic, sent by any remote client with no login, brings the server down. Every XQUIC release through v1.9.4 is affected. There is no CVE assigned as of publication. There is no patch.

Féry’s own timeline, laid out plainly in the FoxIO post, is the part that matters most for defenders. He emailed Alibaba’s security team on April 7, 2026, was told to expect a reply within three business days, and did not receive one. He followed up four more times through May 9. Silence. On July 8 he published, including the mitigations Alibaba never confirmed: set SETTINGS_QPACK_MAX_TABLE_CAPACITY to zero, or disable HTTP/3 entirely and fall back to HTTP/2 until a fix is available.

Analysis, and a note on scope. This is a class-of-bug and disclosure-process commentary. The technical mechanic is described only at the level FoxIO already published; defenders needing the full pathological input format should read the writeup and the linked FoxIO tooling directly.

The shape is older than the protocol

The specific mistake — an integer underflow in a ring-buffer resize path, triggered by legal but unusual instructions from the peer — is not novel. It is one of the classical failure modes of any network-facing state machine that manages a variable-size buffer against a size hint the peer controls. The 1990s and early 2000s were full of these, distributed across TCP/IP stacks, DNS resolvers, and early TLS implementations. The remediation pattern that eventually stuck was straightforward: signed arithmetic where the spec allows negatives, saturating arithmetic where it does not, and fuzz corpora that walk every field near its boundary. That work is well known. It is not, evidently, uniformly applied to newer protocols.

QUIC and HTTP/3 are still young code by that measure. The RFCs stabilized only in 2021. QPACK, the header-compression scheme specific to HTTP/3, is younger still as running code and considerably trickier than its HTTP/2 predecessor because the dynamic table has to survive out-of-order stream delivery. Every major QUIC and HTTP/3 library — nginx-quic, quiche, msquic, aioquic, XQUIC — is going to spend the next few years finding this class of bug in itself. That is not a criticism of the maintainers. It is what always happens at this point in a protocol’s adoption curve. The interesting question is not whether the bugs exist but how the projects react when a researcher writes in.

The disclosure side is the newer story

FoxIO followed a textbook coordinated-disclosure process. Ninety-plus days of quiet, five contact attempts, then publication with defender-usable mitigations included. The response side of the process — the vendor part — is what failed here, and it failed at Alibaba, which is not a small maintainer. XQUIC ships in production infrastructure that terminates HTTP/3 for hundreds of millions of users. The security-response function on a project of that scale is not a nice-to-have; a three-business-day reply commitment is the low bar it agreed to. Missing that commitment for three months, across five reminders, is the systems problem this piece is actually about.

There is a temptation to read the silence as an Alibaba-specific fact, and it may partly be one. But the pattern generalizes. Well-known open-source security researchers have written for years about how the “big cloud vendor releases an open-source library” model tends to divorce the code from any single team that would be paged if a security@ address received a report. Nobody owns the upstream in an operational sense; the mailbox exists but does not route to anyone accountable for it. The gap is structural.

What to do while there is no patch

For anyone running Tengine, XQUIC directly, or a fronting product that embeds it — this list is not complete; check the XQUIC repository and your vendor’s advisory before assuming you are unaffected — the honest short-term guidance is Féry’s own. Setting SETTINGS_QPACK_MAX_TABLE_CAPACITY to zero prevents the vulnerable code path from being entered at all; the cost is that HTTP/3 responses lose the header-compression savings QPACK exists to provide. Disabling HTTP/3 outright and letting traffic fall back to HTTP/2 has a smaller performance impact for most workloads and closes the exposure entirely. Neither is a permanent fix, and neither substitutes for a patched release. Both are what running defenders can actually do this week.

If a patch lands and this piece has not been updated, the FoxIO post and the XQUIC repository will carry the current status. Follow those. This one will not chase the timeline.