Mastodon Mastodon Mastodon Mastodon

How the XRING vulnerability exposes XQUIC HTTP/3 servers

Photo of author

CyberSecureFox Editorial Team

Published:

In the XQUIC library — Alibaba’s open-source implementation of the QUIC and HTTP/3 protocols — a vulnerability has been discovered that allows a remote unauthenticated client to crash the server process by sending approximately 260 bytes of entirely legitimate QPACK traffic. The vulnerability, dubbed XRING, affects all XQUIC releases up to and including the current version 1.9.4. As of July 10 there is no patch available and no CVE has been assigned. Operators of servers based on XQUIC are advised to immediately disable the QPACK dynamic table by setting the SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter to 0, or to completely deactivate HTTP/3 support.

How the vulnerability works

Researcher Sébastien Ferré from FoxIO publicly disclosed the vulnerability on July 8. The root cause lies in the logic for expanding the ring buffer that XQUIC uses to store the QPACK dynamic table. The code is located in the file xqc_ring_mem.c.

HTTP/3 uses QPACK to compress repeating headers. Via a dedicated control channel (the encoder stream), the client instructs the server to grow and resize the shared table. When the client requests an increase in the table size, XQUIC allocates a new, larger buffer and copies data from the old buffer into it. The copy routine handles four scenarios depending on whether the data are “wrapped” in the old buffer, in the new one, in both, or in neither.

In one of these scenarios, the code mistakenly computes the size of the “tail” data using the capacity of the new buffer instead of the old one. This leads to a severe overestimation of the length of the block to be copied. According to the researcher, when expanding a 64-byte table to 65 bytes with the write cursor near the end of the buffer, XQUIC calculates 70 bytes of tail data instead of the actual 6.

The inflated value is then used in length arithmetic for the memory copy call. Since the length is stored in an unsigned size_t type, subtracting an oversized number from a smaller value causes an integer underflow — the length “wraps around” to a near-maximum value. The result is an attempt to copy far beyond the bounds of the allocated memory.

In FoxIO’s test environment (Ubuntu, built with _FORTIFY_SOURCE=2), the glibc protection mechanism detected the invalid length and forcibly terminated the process. Without this check, the copy operation writes data beyond the end of the new buffer. The researcher demonstrated a crash, but did not investigate whether exploitation for arbitrary code execution is possible.

What makes XRING particularly dangerous

The key aspect of this vulnerability is that the attack requires neither authentication nor malformed packets. All values used in the attack comply with the QPACK specification. By default, XQUIC advertises a 16 KiB dynamic table limit; the exploit sequentially requests 64 and 65 bytes — both values are fully legitimate. The client only needs to bring the table into a specific “wrapped” state to trigger the faulty code path.

According to FoxIO, the bug has been present in XQUIC since the first public release in January 2022. A public PoC exploit is available on GitHub. No exploitation in real-world attacks had been observed at the time of disclosure.

Affected products and impact scope

XQUIC is an open-source library, so the risk is not limited to Alibaba’s own infrastructure. According to the researchers, any server that uses XQUIC to serve HTTP/3 with default QPACK settings is vulnerable. Among the affected products:

  • Alibaba XQUIC — all versions up to and including v1.9.4
  • Tengine — Alibaba’s Nginx-based web server, which, according to FoxIO, powers the company’s cloud infrastructure and CDN

It should be noted that statements about the extent of the impact on Alibaba’s infrastructure are based solely on the researcher’s data — no official confirmation from the vendor has been received.

Context: a series of HTTP/2 and HTTP/3 vulnerabilities

XRING fits into a worrying trend of remote denial-of-service vulnerabilities being discovered in HTTP/2 and HTTP/3 stacks. Three weeks earlier, a use-after-free vulnerability in the NGINX HTTP/3 module (CVE-2026-42530) was disclosed, exploitable via the same QPACK encoder stream — a different class of bug, but an identical attack surface. In February, HAProxy fixed two QUIC crashes, one of which was also caused by integer underflow — the same type of error as in XRING, but its exploitation required a malformed packet.

The fundamental difference with XRING is that fully legitimate input is sufficient to carry out the attack. A single arithmetic mistake, and the server stops working.

Mitigation recommendations

Since there is no official patch, operators of XQUIC-based servers must apply workarounds:

  1. Disable the QPACK dynamic table — set the SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter to 0. This removes the attack vector but increases the volume of header data transmitted.
  2. Disable HTTP/3 support entirely — a drastic step, but one that reliably prevents exploitation of this vulnerability.
  3. Monitor XQUIC updates — check the project repository for the release of a fixed version.
  4. Ensure _FORTIFY_SOURCE protection is enabled — in builds with this option, glibc intercepts invalid copies and terminates the process, preventing potential writes beyond the buffer. This does not eliminate the denial of service, but it reduces the risk of deeper exploitation.

Disclosure timeline

According to FoxIO, the company notified Alibaba on April 7 via the mechanism described in the project’s security policy (which promises a reply within three business days), and then sent four more messages up to May 9 — none of which received a response. After that, the researcher decided to disclose the issue publicly. There is no confirmation of this timeline from Alibaba.

Operators of servers using XQUIC or Tengine with HTTP/3 support should immediately apply the described workarounds — at a minimum, set SETTINGS_QPACK_MAX_TABLE_CAPACITY=0. With a public PoC available and no patch in place, the window for attack is open, and the cost of exploitation for an attacker is minimal: 260 bytes of traffic that do not require authentication or protocol violations.


CyberSecureFox Editorial Team

The CyberSecureFox Editorial Team covers cybersecurity news, vulnerabilities, malware campaigns, ransomware activity, AI security, cloud security, and vendor security advisories. Articles are prepared using official advisories, CVE/NVD data, CISA alerts, vendor publications, and public research reports. Content is reviewed before publication and updated when new information becomes available.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.