A single wrong variable on one line in XQUIC, Alibaba’s QUIC and HTTP/3 library, lets any remote client crash the server with a short burst of completely legal traffic. There is no patch.
FoxIO researcher Sébastien Féry disclosed the flaw on July 8 and nicknamed it XRING. He says it needs no login and no malformed packets: about 260 bytes of ordinary QPACK traffic takes the server process down.
XQUIC is open-source, so the risk is not Alibaba’s alone: any server that embeds it and serves HTTP/3 with the default QPACK settings is exposed. That includes Tengine, Alibaba’s Nginx-based web server, which FoxIO says fronts the company’s cloud and CDN on sites including Taobao and Alipay.
Every release through v1.9.4, the latest, is affected. There is no fixed release and no CVE as of July 10. Until a fix ships, operators can set SETTINGS_QPACK_MAX_TABLE_CAPACITY to 0, which turns off QPACK’s dynamic table, or drop HTTP/3 support entirely.
The bug lives in how HTTP/3 compresses headers. To avoid sending the same header (say, user-agent) over and over, HTTP/3 uses QPACK. It keeps a shared table that the client directs the server to build up and resize through a dedicated control channel, the encoder stream.
XQUIC stores that 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.
When the client asks to grow the table, XQUIC allocates a bigger buffer and copies the old data across. That copy has four cases, depending on whether the data wraps in the old buffer, the new one, both, or neither. In one of them, 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, and XQUIC decides there are 70 tail bytes to move when there are really 6.
That wrong number flows into a memory copy. 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 number, and the copy runs off the end of memory.
In FoxIO’s release build on Ubuntu 26.04, glibc’s _FORTIFY_SOURCE=2 caught the bad length and killed the process. Without that check, the copy writes out of bounds, from the old buffer past the end of the new one. Féry showed a crash but did not test whether that corruption could be exploited further.
None of the values in the attack breaks QPACK’s rules. XQUIC advertises a 16 KiB dynamic-table limit by default; the payload 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 mistake has been in XQUIC since its first public release in January 2022, and a proof of concept is public.
XRING is the latest in a string of remote crashes in HTTP/2 and HTTP/3 stacks. Three weeks earlier, THN reported a use-after-free in NGINX’s HTTP/3 module (CVE-2026-42530) that a remote, unauthenticated client could reach through the same QPACK encoder stream XRING abuses, a different bug class on the same attack surface.
In June, Calif’s HTTP/2 Bomb caused remote denial of service against Nginx, Apache, IIS, and Envoy by abusing HPACK, HTTP/2’s header compression, and the predecessor to QPACK.
In February, HAProxy patched two QUIC crashes, one an integer underflow during token validation, the same type of bug behind XRING, though it needed a malformed packet where XRING needs none. That difference is the point: legal input, one arithmetic slip, a dead server.
FoxIO demonstrated a crash, not code execution, and reported no exploitation in the wild. It says it emailed Alibaba on April 7 through the project’s security policy, which promises a reply within three working days, then followed up four more times through May 9 without an answer before going public.
The Hacker News has asked Alibaba whether a fix and a CVE are coming, and whether FoxIO’s five disclosure attempts reached its security team. It has asked FoxIO whether the flaw has been exploited in the wild and whether the underlying heap write can be pushed past a crash. The story will be updated with any response.
