0 votes

Class of QUIC vulnerabilities across implementations allows QPACK amplification attacks against HTTP/3 servers

1 comment

  1. AndreasChris
    Link
    Because the last 48 hours were so fun, here's another (less severe) security issue. This time it's the QUIC protocol that's affected. At least we're not dealing with RCE this time, but denial of...

    Because the last 48 hours were so fun, here's another (less severe) security issue. This time it's the QUIC protocol that's affected. At least we're not dealing with RCE this time, but denial of service is in scope for this one.

    A remote, unauthenticated client can force an HTTP/3 server to allocate tens to thousands of times more memory than it sends. One connection is enough to OOM or pin a default-configured server. Seven of the ten implementations tested are vulnerable; several are already fixed.

    QPACK compresses HTTP/3 headers to minimize traffic sent over the wire. Across the affected implementations, decoded-header limits are missing, incomplete, or applied too late. A small HEADERS frame can therefore expand into hundreds of thousands of header objects in memory. Preventing that expansion from exhausting resources requires enforcing a cumulative budget as fields are decoded and retained.

    The PoC for this one can be found at https://github.com/FoxIO-LLC/blog_poc/tree/main/headeraccordions

    It appears the initial report of a related bug was back in 2025, but given that more and more QUIC implementations were discovered to be vulnerable, I guess it took some time for this to be written up and released.