# Unpatched XRING Vulnerability in XQUIC Exposes HTTP/3 Servers to Remote Denial of Service
A critical vulnerability in XQUIC, Alibaba's open-source QUIC and HTTP/3 library, allows remote attackers to crash vulnerable servers using nothing more than legitimate HTTP/3 traffic. The flaw, disclosed on July 8, 2026, and dubbed XRING, remains unpatched as of press time, leaving an unknown number of production HTTP/3 deployments at risk.
The vulnerability stems from a single line of code that miscalculates buffer size during a header compression table resize operation. With as little as 260 bytes of ordinary QPACK traffic, an unauthenticated attacker can send any affected server offline, forcing legitimate users into denial-of-service conditions without requiring special privileges, authentication, or malformed packets.
## The Threat
FoxIO researcher Sébastien Féry has publicly detailed how the vulnerability can be exploited to crash XQUIC-based servers with minimal effort. The attack requires:
The proof of concept code is already public, making exploitation straightforward for any threat actor with basic HTTP/3 client capabilities. In testing on Ubuntu 26.04, the crash was caught by glibc's memory protection mechanisms (_FORTIFY_SOURCE=2), resulting in server process termination. On systems without equivalent protections, the memory corruption could potentially cascade into more severe outcomes, though this has not been tested or exploited in the wild.
## Background and Context
XQUIC has been embedded in production systems since its initial open-source release in January 2022. The vulnerability has persisted through all versions up to and including v1.9.4, the latest release as of this writing. No patched version exists. Critically, XQUIC powers Tengine, Alibaba's Nginx-based web server, which serves as the primary frontend for Alibaba's cloud infrastructure and CDN, including high-traffic properties such as Taobao and Alipay.
### Disclosure Timeline
The disclosure process reveals a significant responsiveness gap:
| Date | Event |
|------|-------|
| April 7, 2026 | FoxIO reports vulnerability to Alibaba via official security policy (3-day response SLA) |
| May 9, 2026 | Final follow-up email sent after four previous unanswered attempts |
| July 8, 2026 | FoxIO publicly discloses vulnerability without vendor patch |
| July 10, 2026 | No CVE identifier assigned; no patched release available |
The three-month communication gap without response prompted responsible disclosure after exhausting private notification channels.
## Technical Details
### How QPACK Header Compression Works
HTTP/3 uses QPACK (QUIC Packet Protection) for header field compression, a mechanism designed to reduce bandwidth by caching frequently repeated headers (such as User-Agent or Content-Type) in a shared dynamic table. Rather than resending the same header on every request, the client references it by index, saving bytes on the wire.
The dynamic table is managed through a dedicated control channel called the encoder stream. The client can instruct the server to grow the table's capacity when needed. XQUIC stores this table using a ring buffer—a fixed block of memory where data wraps from end to beginning once the buffer fills.
### The Bug
The vulnerability lies in the resize logic when the client requests to grow the dynamic table. XQUIC must allocate a larger buffer and copy existing data from the old buffer to the new one. The copy operation has four code paths depending on whether data wraps in the old buffer, new buffer, both, or neither.
In one specific case, the code calculating how much data to copy makes a critical mistake:
> It sizes the "leftover tail" data against the new, larger buffer's capacity instead of the old buffer's actual size.
Concrete example:
The overcounted length then flows into a memcpy() operation. Since the copy length is an unsigned size_t integer, subtracting the overcount from a smaller value causes an integer underflow—the value wraps to a near-maximum number (e.g., 18 exabytes). The memory copy then runs far beyond allocated boundaries, corrupting memory and crashing the process.
### Why This Works Against Any Server
The attack requires no special QPACK values or malformed data:
## Affected Systems
Any server embedding XQUIC with HTTP/3 support enabled using default settings is vulnerable, including:
The open-source nature of XQUIC means the blast radius extends far beyond Alibaba's infrastructure to any organization that has integrated the library.
## Broader Pattern: HTTP/2 and HTTP/3 Compression Attacks
XRING is the latest in a growing pattern of remote-crash vulnerabilities affecting modern HTTP stacks:
| Vulnerability | Protocol | Date | Vector | Status |
|---|---|---|---|---|
| XRING | HTTP/3 (QPACK) | July 2026 | Buffer size underflow | Unpatched |
| CVE-2026-42530 | HTTP/3 (QPACK) | June 2026 | Use-after-free in encoder stream | Patched (NGINX) |
| HTTP/2 Bomb | HTTP/2 (HPACK) | June 2026 | Header compression abuse | Patched |
| HAProxy QUIC crashes | QUIC | February 2026 | Integer underflow (malformed packets required) | Patched |
Each attack targets header compression—the mechanism designed to make HTTP faster. The recurring pattern suggests that header compression logic remains a high-risk surface for protocol implementation bugs.
## Implications for Organizations
Immediate Risk:
Supply Chain Considerations:
Detection Challenges:
## Recommendations
### Immediate Actions (Temporary)
Alibaba and system administrators have two configuration-based options while awaiting a patch:
1. Disable QPACK dynamic table compression:
```
Set SETTINGS_QPACK_MAX_TABLE_CAPACITY = 0
```
This disables QPACK's memory efficiency gains but prevents exploitation. Performance impact should be measured.
2. Disable HTTP/3 entirely:
For organizations where HTTP/2 or HTTP/1.1 adequately serve client needs, disabling HTTP/3 eliminates the attack surface entirely.
### Medium-Term
### Detection and Monitoring
## HackWire Analysis
The XRING vulnerability exposes a critical gap in HTTP/3 adoption: as organizations rush to deploy faster protocols, the complexity of features like header compression has outpaced battle-testing. Unlike HTTP/2's "HTTP/2 Bomb" (which also exploited HPACK), XRING succeeds with entirely legal traffic—no malformed packets, no edge cases required. This is the vulnerability class that should keep protocol implementers awake: a single arithmetic mistake, default settings, and no authentication requirement transform a performance optimization into a weapons-grade denial-of-service vector.
The three-month silence from Alibaba is particularly concerning. Responsible disclosure depends on vendor responsiveness; when vendors don't engage, researchers face impossible choices. FoxIO's decision to go public was defensible, but it also confirms what many in the industry suspect: open-source HTTP/3 stacks remain under-resourced for security maintenance. XQUIC powers Alibaba's most critical infrastructure (Taobao, Alipay), yet the disclosure process appears to have broken down entirely.
For defenders, this is a reminder that performance upgrades must be paired with security audits. HTTP/3 adoption should include staged rollouts with crash monitoring and kill-switches—exactly what XRING's exploitability suggests. Any organization running XQUIC-based HTTP/3 in production should assume compromise of availability and plan for immediate mitigation. Until Alibaba ships a patch, operators should choose between disabling QPACK's dynamic table or HTTP/3 itself. Neither is painless, but both beat silent crashes during peak traffic.
— HackWire Editorial
## Related Coverage