CVE-2026-105298 in Pingora
Summary
by MITRE • 10/20/2026
Summary
Before version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs that read the request URI (session.req_header().uri) saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (for example, [email protected]). This violates RFC 9113 Section 8.3.1, which requires an intermediary to use the :authority value for Host and replace any existing Host field.
Root cause
*
HTTP/2 to HTTP/1.1: Host was generated from :authority only when the request had no Host header, so a conflicting client Host was forwarded unchanged.
*
HTTP/2 to HTTP/2: the client Host header was removed and used to overwrite the upstream :authority, after request filters had already run against the original :authority.
*
The HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.
Impact
A remote, unauthenticated attacker can send a single HTTP/2 request that the application sees as one host and the upstream receives as another. Where request filters, access controls, or cache keys use the URI authority and the upstream routes by Host, this can lead to:
*
Cache poisoning: a response from another virtual host is stored under the victim host's cache key and served to other users (this also requires the upstream to serve different content per Host).
*
Host-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.
Deployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.
Note that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.
Mitigation:
*
Upgrade to pingora 0.9.0 or later. Pingora now returns 400 Bad Request for HTTP/2 requests whose Host differs from :authority, that contain more than one Host, or whose authority contains userinfo, and keeps the upstream Host or :authority consistent with the request authority. Fix commits: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76
*
If you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains '@'.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
In versions of Pingora prior to 0.9.0, a critical protocol compliance vulnerability existed within the handling of HTTP/2 requests, specifically concerning the synchronization between the :authority pseudo-header and the traditional Host header. This flaw allowed for a discrepancy where request filters, cache keys, and logging mechanisms operated on one authority value while the upstream server received a different one. The root cause stems from inconsistent logic in how Pingora processed incoming HTTP/2 traffic during protocol translation or forwarding. When translating from HTTP/2 to HTTP/1.1, the system only generated the Host header from the :authority pseudo-header if no existing Host header was present; otherwise, it forwarded the client-supplied Host value unchanged, ignoring potential conflicts with the authority field. In scenarios involving HTTP/2 to HTTP/2 forwarding, Pingora removed the client's Host header and used it to overwrite the upstream :authority only after request filters had already executed against the original :authority value. Furthermore, the HTTP/2 server implementation failed to validate that the Host header matched the :authority pseudo-header as required by RFC 9113 Section 8.3.1, which mandates that intermediaries must use the :authority value for the Host and replace any existing Host field. Additionally, Pingora accepted :authority values containing userinfo components, such as [email protected], violating standard authority format requirements.
The operational impact of this vulnerability is significant for deployments relying on host-based routing, caching strategies, or access control lists that utilize the request URI's authority component. A remote, unauthenticated attacker can craft a single HTTP/2 request where the Host header differs from the :authority pseudo-header to exploit this inconsistency. This discrepancy enables cache poisoning attacks wherein responses intended for one virtual host are stored under the cache key of another victim host and subsequently served to other users, provided the upstream server serves different content based on the Host header. It also facilitates host-based access control bypasses, allowing an attacker to send a request that passes security checks configured for one host but is ultimately processed by a different virtual host on the backend infrastructure. These attacks rely on the assumption that the application logic and caching layers trust the authority seen during initial processing while the upstream server makes routing decisions based on the divergent Host header received later in the pipeline. Deployments that do not accept HTTP/2 from clients or those that do not use the request authority for security or caching decisions remain unaffected by this specific vector.
To mitigate this vulnerability, organizations should upgrade Pingora to version 0.9.0 or later immediately. The updated versions enforce strict compliance with RFC standards by returning a 400 Bad Request error for HTTP/2 requests where the Host header differs from the URI authority, contain multiple Host headers, or include userinfo in the authority field. This ensures that the upstream Host and :authority remain consistent with the request authority throughout the processing pipeline. For environments unable to upgrade immediately due to operational constraints, a temporary mitigation involves implementing custom request filters to reject HTTP/2 requests where the Host header does not match the URI authority or where the authority contains an at symbol (@), which indicates the presence of userinfo. This workaround effectively blocks the malformed requests that trigger the inconsistency before they reach critical routing or caching logic. The fix commits addressing these issues are available in the official Pingora repository, ensuring long-term stability and security for HTTP/2 proxying operations.