A single, misplaced variable in **Alibaba**'s open-source **XQUIC** library, a foundational component for **QUIC** and **HTTP/3**, enables remote clients to crash servers with minimal, legitimate traffic. The vulnerability, dubbed **XRING** by **FoxIO** researcher **Sébastien Féry**, was publicly disclosed on July 8. ### The XRING Vulnerability Explained **Féry**'s research indicates that the **XRING** flaw requires no prior authentication or malformed packets. Approximately 260 bytes of ordinary **QPACK** traffic are sufficient to bring down the server process. The core of the issue lies in how **HTTP/3** compresses headers using **QPACK**, which maintains a dynamic, shared table managed by the client via an encoder stream. **XQUIC** stores this table data in a ring buffer. When a client requests to expand the table, **XQUIC** allocates a larger buffer and copies existing data. The bug occurs in one of four copy scenarios: when the code incorrectly calculates the size of leftover 'tail' data, comparing it against the new, larger buffer's capacity instead of the old one's. This leads to a severe overcount. For instance, resizing a 64-byte table to 65 bytes with the write cursor near the end can lead **XQUIC** to believe there are 70 tail bytes to move, when in reality there are only 6. This erroneous value then feeds into a memory copy operation. Because the copy length is derived from subtracting this overcounted value from a smaller one, it underflows, wrapping to a near-maximum `size_t` number. This results in an attempt to copy an extremely large amount of data, causing an out-of-bounds write and subsequently crashing the process.  In testing with a release build on Ubuntu 26.04, **glibc**'s `_FORTIFY_SOURCE=2` caught the bad length and terminated the process. Without this safeguard, the memory copy would write out of bounds, potentially leading to further exploitable corruption beyond a mere crash. ### Wide-Ranging Impact and Mitigation Given that **XQUIC** is open-source, the risk extends beyond **Alibaba** to any server embedding the library and serving **HTTP/3** with default **QPACK** settings. This includes **Tengine**, **Alibaba**'s **Nginx**-based web server, which **FoxIO** states fronts the company's cloud and CDN for major platforms like **Taobao** and **Alipay**. All **XQUIC** releases up to v1.9.4, the latest version as of July 10, are affected. Currently, there is no fixed release and no **CVE** assigned. Until a patch becomes available, operators have two primary mitigation strategies: * Set `SETTINGS_QPACK_MAX_TABLE_CAPACITY` to `0`, which disables **QPACK**'s dynamic table functionality. * Completely disable **HTTP/3** support on their servers. ### Disclosure and Broader Context **FoxIO** demonstrated a crash, not code execution, and has reported no in-the-wild exploitation. The researcher stated that they attempted to contact **Alibaba** on April 7 via the project's security policy, which promises a three-day reply window. Despite four subsequent follow-ups until May 9, no response was received, prompting public disclosure. This **XRING** vulnerability is the latest in a series of remote crashes impacting **HTTP/2** and **HTTP/3** stacks. Recently, a use-after-free vulnerability (**CVE-2026-42530**) was patched in **NGINX**'s **HTTP/3** module, also reachable via the **QPACK** encoder stream. In June, the 'HTTP/2 Bomb' allowed remote denial of service against **Nginx**, **Apache**, **IIS**, and **Envoy** by abusing **HPACK**, **HTTP/2**'s header compression predecessor to **QPACK**. Furthermore, **HAProxy** patched two **QUIC** crashes in February, one of which involved an integer underflow during token validation – the same class of bug as **XRING**, though it required a malformed packet.  The key distinction of **XRING** is its reliance on entirely legal input – a single arithmetic error leads to a dead server. The proof of concept for **XRING** is publicly available on **GitHub**. Ghost Protocol has reached out to **Alibaba** for comment regarding an impending fix and **CVE** assignment, as well as to confirm receipt of **FoxIO**'s disclosure attempts. We have also contacted **FoxIO** regarding potential in-the-wild exploitation and the exploitability of the underlying heap write beyond a crash. This story will be updated as new information becomes available.