Pingora vulnerabilities

Before version 0.9.0, the HTTP/1 upstream path in pingora-proxy did not remove the Connection header, other hop-by-hop headers, or headers nominated by Connection, despite RFC 9110 requirements. A client could nominate a header added by the application in upstream_request_filter (e.g., X-Forwarded-For), which would then be stripped by an HTTP/1 intermediary before reaching the origin.

Before version 0.9.0, Pingora accepted HTTP/2 requests where the Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (e.g., [email protected]), violating RFC 9113 Section 8.3.1.

Before version 0.8.1, Pingora's HTTP/2 server used the h2 crate's default limits, allowing a remote, unauthenticated client to send 1-byte HPACK references to a near-empty header. This caused the server to allocate hundreds of thousands of header fields per stream across an unlimited number of streams on one connection, potentially exhausting memory and terminating the Pingora process.