Unpatched Flaw in Alibaba's XQUIC Lets Anyone Crash HTTP/3 Servers With 260 Bytes

Key points

• FoxIO researcher Sébastien Féry disclosed a denial-of-service flaw in Alibaba's XQUIC library on 8 July 2024, nicknamed XRING.
• Any remote client can crash an XQUIC server with roughly 260 bytes of ordinary, well-formed traffic.
• No authentication is required and no malformed packets are needed to trigger the crash.
• XQUIC has no patch available at time of disclosure.
• The root cause is a single incorrect variable on one line of the QPACK handling code.

A researcher has gone public with a flaw in Alibaba's XQUIC library that lets any stranger on the internet knock a server offline with a tiny burst of perfectly ordinary traffic.

XQUIC is open-source software Alibaba wrote to speak QUIC and HTTP/3, the newer protocols that carry a growing share of web traffic. Think of it as the plumbing that lets a browser talk to a website using the latest standards.

Sébastien Féry of FoxIO disclosed the bug on 8 July and named it XRING. He says an attacker needs no login and no oddly-shaped packets. About 260 bytes of legitimate QPACK traffic, the compression scheme HTTP/3 uses to shrink request headers, is enough to bring the server down. There's no patch.

What actually goes wrong?

A single wrong variable on one line of XQUIC's code causes the server to crash when it processes certain valid QPACK data. The traffic looks entirely normal on the wire, accepted and processed until the server falls over.

Because the packets are legal QUIC and legal QPACK, filtering them at the network edge is awkward. A firewall or load balancer can't easily distinguish an attack from a real browser request without deep inspection of encrypted streams. This puts XRING in the same uncomfortable category as the HTTP/2 denial-of-service vector we covered in our Citrix NetScaler story on 1 July: the attack traffic looks legitimate by design.

260 bytes is smaller than this paragraph. One request, one crash.

Who is affected?

Anyone running XQUIC as their HTTP/3 or QUIC server is exposed. XQUIC is used inside Alibaba's own infrastructure and has been adopted by outside developers wanting a production-grade QUIC library. It isn't as widely deployed as nginx, but it's out there.

Ordinary web users don't need to do anything. This is a server-side flaw. The risk is that a site or app you rely on uses XQUIC and gets taken offline until operators find a workaround.

What can operators do right now?

With no fix published, practical options are thin. Operators can turn off HTTP/3 and fall back to HTTP/2 over TCP, which bypasses XQUIC's QPACK path entirely. Alternatively, placing a QUIC terminator not based on XQUIC in front of the application removes the exposure. Aggressive rate-limiting on new QUIC connections slows an attacker but won't stop a determined one.

Féry's disclosure went out, as first reported by The Hacker News, without a coordinated vendor patch attached. That's unusual for a remotely-triggerable denial-of-service bug in a library used at Alibaba's scale, and it'll put pressure on the maintainers to ship a fix fast.

Should you worry about HTTP/3 more broadly?

XQUIC isn't the first HTTP/3-adjacent implementation to stumble. On 18 June we reported two critical bugs in NGINX's HTTP/3 module that opened the door to remote code execution. The protocols themselves are solid; the implementations carrying them are new code, and new code has bugs.

XRING is a reminder that a single-line mistake in a header-compression routine can hand a stranger the power to reboot your website with a request smaller than a tweet. Operators who moved to HTTP/3 for speed should be checking which library sits underneath. In a lot of shops, that answer is buried in a Dockerfile nobody's opened in a year.