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.
• The bug lets any remote client 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, faster 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, no clever tricks, 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 is 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. The server accepts it, tries to handle it, and falls over.

Because the packets are legal QUIC and legal QPACK, filtering them out at the network edge is awkward. A firewall or load balancer cannot easily tell an attack from a real browser request without deep inspection of encrypted streams.

The attack is cheap. 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 who wanted a production-grade QUIC library. It is not as widely deployed as, say, nginx or Cloudflare's stack, but it is out there in the wild.

Ordinary web users do not 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 mitigate the issue.

What can operators do right now?

With no fix published, the practical options are limited. Operators can turn off HTTP/3 support and fall back to HTTP/2 over TCP, which does not go through XQUIC's QPACK path. They can put a different QUIC terminator, one not based on XQUIC, in front of their application. They can rate-limit new QUIC connections aggressively, which slows an attacker but does not stop a determined one.

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

Why does this matter beyond one library?

QUIC and HTTP/3 are still young. The protocols themselves are solid, but the implementations that carry 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 now be checking which library sits underneath. That answer, in a lot of shops, is buried in a Dockerfile no one has looked at in a year.