HTTP/3 Servers Hit by Qpack Amplification Attacks: Analyzing the New Threat

Introduction

A recent discussion on Hacker News titled "Qpack amplification attacks against HTTP/3 servers" has brought attention to a security threat targeting the emerging HTTP/3 protocol. Although the post received only 11 points and few comments, it reveals a threat vector against the new HTTP/3 protocol.

HTTP/3, the next-generation HTTP protocol built on QUIC, aims to improve speed and security. However, QPACK, its header compression mechanism, could be abused for amplification attacks. This article provides an in-depth analysis of this attack vector, its principles, potential impact, and defense strategies.

What is Qpack?

QPACK is the header compression algorithm used in HTTP/3, similar to HPACK in HTTP/2. It reduces header size by maintaining dynamic and static tables, thereby improving transmission efficiency. However, QPACK's design allows both servers and clients to dynamically update the tables, which gives attackers an opportunity.

Attackers could exploit QPACK's header compression features to craft malicious requests that cause amplified server responses, consuming significant bandwidth and resources. This amplification attack is similar to DNS amplification attacks, but targets HTTP/3 servers.

Key Differences Between HPACK and QPACK

HPACK is the header compression scheme for HTTP/2, operating over reliable TCP connections where header blocks arrive strictly in order. This allows a single dynamic table and reliance on ordering. QPACK, on the other hand, runs over QUIC, where multiple streams may arrive out of order. Using HPACK directly would cause head-of-line blocking. To address this, QPACK introduces two unidirectional control streams: the "encoder stream" and the "decoder stream". It uses absolute indexing and relative indexing to distinguish references to the dynamic table and coordinates table state through mechanisms such as the "Known Received Count".

This design introduces a security-related side effect: the dynamic table capacity is negotiated via SETTINGS parameters, and both endpoints must reserve memory for the table. When references have not yet been acknowledged, the encoder must also limit the number of "blocked streams". Attackers may exploit these windows where limits are not tightened to induce the peer to perform excessive work during decoding or maintain an excessively large table state. Understanding the differences between QPACK and HPACK in flow control and state synchronization is a prerequisite for assessing the feasibility of amplification attacks.

Principles of Qpack Amplification Attacks

The core of an amplification attack is that the attacker sends a small request that triggers a large response from the server. In the QPACK context, an attacker might manipulate the header compression table to force the server to include a large amount of header information in the response, or exploit the dynamic table update mechanism to cause response bloat.

Specifically, an attacker can send carefully crafted requests that cause the server to consume excessive resources when decoding headers, or include redundant header fields in responses. Because HTTP/3 is based on UDP, attackers can also spoof source IP addresses to direct amplified traffic to victims.

UDP Reflection Amplification and Source Address Spoofing

Amplification attacks typically involve two elements: an "amplification factor" where the response size is significantly larger than the request size, and the ability to spoof the source address so that responses are reflected to a third-party victim. Classic cases have occurred on UDP protocols such as DNS, NTP, and Memcached, with amplification factors reaching tens or even tens of thousands of times.

Although QUIC is based on UDP, its handshake phase includes source address validation mechanisms (such as Retry packets and address validation tokens), which in theory can mitigate pure reflection abuse. However, once a connection is established, if an attacker already holds a valid connection, they can repeatedly trigger high-cost responses within the same connection. In the window before the connection is fully validated, if the server implementation allows Initial or 0-RTT data carrying large header blocks, a limited amplification surface may still exist. Therefore, when assessing QPACK amplification attacks, the key is to determine whether the server processes heavyweight header decoding and response construction before address validation is complete.

Potential Impact and Risks

If HTTP/3 servers do not limit QPACK header sizes, they may face serious amplification attack risks. Attackers can easily exploit this vulnerability to launch distributed denial-of-service (DDoS) attacks, causing service unavailability.

Moreover, as HTTP/3 deployment becomes more widespread—especially with large internet companies beginning to adopt it—the potential impact of such attacks is significant. Security researchers need to pay attention to QPACK implementation details to ensure servers can resist such attacks.

Defense Measures and Recommendations

To mitigate Qpack amplification attacks, server implementations should take the following measures:

• Limit the size and number of header fields to avoid response bloat.
• Strictly limit the size of the dynamic table to prevent abuse by attackers.
• Implement rate limiting and connection count controls to reduce the attack surface.
• Monitor anomalous traffic patterns to detect amplification attack behavior promptly.

Additionally, developers and operations teams should stay informed about HTTP/3 protocol security updates and apply patches promptly.

Conclusion

Qpack amplification attacks are an emerging threat to HTTP/3 servers. Although currently not widely discussed, their potential risks should not be ignored. As HTTP/3 becomes more prevalent, the security community needs to continuously monitor such attack vectors and adopt effective defense measures.

For enterprises and developers, understanding how QPACK works and implementing strict security configurations is key to ensuring the security of HTTP/3 deployments.

One-line Summary

Analyzes the principles, risks, and defenses of Qpack header compression being used for amplification attacks against HTTP/3 servers.

Paragraph Summary

The article centers on a Hacker News discussion about Qpack amplification attacks, introducing the basic principles of the HTTP/3 header compression mechanism QPACK and its similarity to HPACK in HTTP/2. Because QPACK relies on dynamic and static tables to negotiate header compression, attackers may manipulate the compression tables and craft malicious requests to force the server to generate bloated header data during decoding or response, thereby exchanging small requests for large responses and creating an attack effect similar to DNS amplification. The article notes that HTTP/3's UDP-based nature also allows source IP spoofing to direct amplified traffic to victims, potentially evolving into DDoS. For defense, it recommends limiting header field size and count, strictly constraining dynamic table capacity, implementing rate and connection controls, and continuously monitoring protocol security updates.