Pingora versions prior to 0.8.1 used the h2 crate's default HTTP/2 server limits, a 16 MiB decoded header-list size and no limit on concurrent streams, unless the application set its own. A remote, unauthenticated client can send 1-byte HPACK references to a near-empty header, making the server allocate hundreds of thousands of header fields per stream across an unlimited number of streams on one connection, and use HTTP/2 flow control to keep those streams open. This can exhaust memory and degrade or terminate the Pingora process.

This affects any Pingora service that terminates HTTP/2 (h2 or h2c) without explicitly setting max header list size and max concurrent streams. The reporter showed that a single connection could get a Pingora process with a 2 GiB memory limit OOM-killed.

This flaw was corrected in commit d193c8d49b8b7c1c1ede93183759caa4f6906bbd. When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection. Users should upgrade to Pingora >= 0.8.1. Applications that supply their own H2Options are not covered by these defaults and must set max header list size and max concurrent streams explicitly, or start from pingora core::protocols::http::v2::server::default h2 options(). H2Options::default() does not include these limits.

Note: Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.