A single off-by-line arithmetic error in Alibaba's XQUIC library, the open source QUIC and HTTP/3 implementation used by millions of websites, lets any remote client crash the server with about 260 bytes of perfectly legal network traffic. There is no patch.
Dubbed XRING by researcher Sebastien Fery at FoxIO, the flaw (CVE-pending) affects every XQUIC release through v1.9.4, the latest. No authentication is needed, no malformed packets are required, and the attack works over a standard TLS 1.3 QUIC connection. FoxIO disclosed the vulnerability on July 8 after Alibaba did not respond to five follow-up emails over three months.
Vulnerability Details
The bug lives in how HTTP/3 compresses headers. HTTP/3 uses QPACK, a compression scheme that maintains a dynamic table shared between client and server. Instead of sending the same header like user-agent or accept-language on every request, the client directs the server to build and resize this table through a dedicated encoder stream.
XQUIC stores this table's bytes in a ring buffer, a fixed block of memory where data wraps from the end back to the start once it fills up. When the client asks to grow the table, XQUIC allocates a bigger buffer and copies the old data across. The copy logic has four cases depending on whether the data wraps in the old buffer, the new one, both, or neither. In one of these cases, the code sizes the leftover tail data against the new larger buffer's capacity instead of the old one's. It overcounts badly.
Grow a 64-byte table with the write cursor near the end and resize to 65 bytes, and XQUIC calculates there are 70 tail bytes to move when there are really only 6. That wrong number flows into a memcpy operation. The copy length comes from subtracting the overcount from a smaller value. Because that length is an unsigned size_t, it underflows and wraps to a near-maximum value, causing the copy to run off the end of memory.
On FoxIO's release build with glibc's _FORTIFY_SOURCE=2, the runtime check caught the bad length and killed the process. Without that safeguard, the copy writes out of bounds from the old buffer past the end of the new one, creating a heap buffer overflow that is theoretically exploitable.
Impact Assessment
The risk is not limited to Alibaba alone. XQUIC is an open source library, and any server that embeds it and serves HTTP/3 with the default QPACK settings is exposed. The most notable downstream consumer is Tengine, Alibaba's Nginx-based web server, which FoxIO says fronts the company's cloud and CDN infrastructure on properties including Taobao and Alipay. Organizations running Tengine with HTTP/3 enabled should treat this as urgent.
None of the values in the attack breaks QPACK's rules. XQUIC advertises a 16 KiB dynamic table limit by default. The proof of concept asks for 64 bytes, then 65. The client only has to drive the table into the exact wrapped layout that hits the faulty branch. FoxIO says the arithmetic mistake has been in XQUIC since its first public release in January 2022, meaning the bug is over four years old.
FoxIO demonstrated a crash but did not test whether the heap corruption could be pushed further to code execution. No exploitation in the wild has been reported as of July 10.
Affected Systems and Mitigation
There is no fixed release and no CVE assigned as of this writing. Until Alibaba ships a patch, operators have two mitigation options:
-
Disable QPACK dynamic tables: Set
SETTINGS_QPACK_MAX_TABLE_CAPACITYto0in your QUIC configuration. This turns off QPACK's dynamic table entirely, eliminating the attack surface. The tradeoff is slightly larger headers on each request since compression is less efficient. -
Drop HTTP/3 support entirely: If QUIC is not critical for your service, disable HTTP/3 at the load balancer or reverse proxy level. Fall back to HTTP/2 or HTTP/1.1 until a fix is available.
For Tengine users specifically, check whether your configuration enables HTTP/3 (quic or http3 directives). If so, apply one of the mitigations above or consider switching to an alternative HTTP/3 stack like NGINX's built-in QUIC module (which had its own QPACK use-after-free issue, CVE-2026-42530, patched in late June).
The Bigger Picture: A Pattern of HTTP/3 Stack Bugs
XRING is the latest in a string of remote crash vulnerabilities in HTTP/2 and HTTP/3 implementations discovered in 2026:
| Vulnerability | Date | Impact |
|---|---|---|
| XRING (XQUIC integer underflow) | July 8, 2026 | Remote DoS, potential heap overflow |
| CVE-2026-42530 (NGINX HTTP/3 UAF) | June 2026 | Remote DoS via QPACK encoder stream |
| HTTP/2 Rapid Reset (Calif) | June 2026 | Multi-vendor DoS (Nginx, Apache, IIS, Envoy) |
| HAProxy QUIC crashes | February 2026 | Remote DoS via malformed packets |
The pattern is clear: header compression in HTTP/2 (HPACK) and HTTP/3 (QPACK) is a persistent weak point. These are complex state machines with ring buffers, dynamic tables, and careful arithmetic. One wrong size_t calculation is all it takes to turn legitimate traffic into a denial of service vector.
Frequently Asked Questions
Does XRING affect my website? If your site is served through Alibaba Cloud, CDN, or Tengine with HTTP/3 enabled, it may be affected. Most shared hosting and standard NGINX or Apache setups without XQUIC are not vulnerable.
Is there a working exploit? FoxIO has a proof of concept that reliably crashes XQUIC servers. No public weaponized exploit has been released as of July 10.
Can this be used for remote code execution?
FoxIO did not demonstrate code execution, only a crash. The heap overflow could potentially be exploited further on systems without _FORTIFY_SOURCE, but this has not been shown.
Why is there no CVE yet? FoxIO reported the issue to Alibaba on April 7 through the project's security policy, which promises a reply within three working days. After five follow-ups through May 9 with no response, FoxIO went public on July 8.
How do I know if my server is running XQUIC?
Check your HTTP/3 implementation. XQUIC is commonly used by Tengine. Run strings $(which nginx) | grep -i xquic or check your server's dependency list.
Key Takeaways
- XRING is an unpatched integer underflow in XQUIC, Alibaba's QUIC library. It allows remote unauthenticated clients to crash HTTP/3 servers with ~260 bytes of legal QPACK traffic.
- The bug affects all XQUIC versions through v1.9.4. No patch or CVE exists as of July 10, 2026.
- Mitigate by disabling QPACK dynamic tables (
SETTINGS_QPACK_MAX_TABLE_CAPACITY=0) or dropping HTTP/3 support. - The vulnerability was disclosed responsibly after three months of unacknowledged follow-ups with Alibaba.
- XRING joins a growing list of HTTP/2 and HTTP/3 header compression bugs discovered in 2026. This attack surface needs more attention from the security community.
Sources: FoxIO disclosure via The Hacker News, FoxIO Security Advisory
Automated Transmission
This entry was synthesized and populated dynamically using native API integrations.