CVE-2026-105299 in Pingora
Summary
by MITRE • 10/20/2026
Summary
Before version 0.9.0, the HTTP/1 upstream path in pingora-proxy passed the downstream request through upstream_request_filter and wrote it to the upstream without removing the client's Connection header, other hop-by-hop headers, or the headers Connection nominated, although RFC 9110 Section 7.6.1 requires intermediaries to remove them. The HTTP/2 upstream path already removed Connection and related HTTP/1-specific headers. A client could therefore nominate a header that the application adds in upstream_request_filter (for example, Connection: keep-alive, X-Forwarded-For). A downstream HTTP/1 intermediary that honors Connection would then strip the Pingora-added header before it reached the origin.
Impact
Specifically affects chained deployments where an HTTP/1 intermediary between Pingora and the origin processes Connection nominations (for example, Go's net/http/httputil.ReverseProxy) and the origin trusts headers added by that intermediary (for example, X-Forwarded-For for IP-based authorization). A remote, unauthenticated attacker can have those headers removed, potentially bypassing authorization. The reporter demonstrated access to an IP-restricted endpoint using X-Forwarded-For for IP validation on the origin. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server.
Note that Cloudflare CDN customers were unaffected, as no such chained deployment as described above exists with internal Pingora services, and Connection headers are sanitized before arriving at Pingora gateways.
Mitigation:
*
Upgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits: https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded , https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee
*
Do not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.
*
If you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/20/2026
In versions of pingora-proxy prior to 0.9.0, a critical protocol compliance flaw existed within the HTTP/1 upstream request handling mechanism that allowed for the potential bypass of security controls relying on forwarded client identity information. The vulnerability stems from the proxy's failure to strictly adhere to RFC 9110 Section 7.6.1 regarding hop-by-hop headers. Specifically, when forwarding requests to an origin server via HTTP/1, pingora-proxy passed downstream request data through its upstream_request_filter without stripping the Connection header or any other hop-by-hop headers that were nominated by that connection directive. While the HTTP/2 path correctly removed these specific headers, the HTTP/1 implementation retained them, creating a discrepancy in security posture depending on the protocol version used for client connections. This oversight allowed a malicious actor to manipulate the request pipeline by nominating headers such as X-Forwarded-For or other custom fields within the Connection header value.
The operational impact of this vulnerability is most severe in chained proxy deployments where an intermediate HTTP/1 intermediary sits between pingora-proxy and the origin server, and that intermediary honors the Connection directive to strip nominated hop-by-hop headers before forwarding them upstream. In such configurations, if pingora-proxy adds a trusted security header like X-Forwarded-For within its filter logic, but fails to remove it from the list of headers nominated by the client's Connection header, the subsequent intermediary will strip this critical header prior to reaching the origin server. Consequently, the origin server receives requests without the expected identity information, potentially allowing an unauthenticated remote attacker to bypass IP-based authorization mechanisms or other access controls that depend on these forwarded headers for validation. This scenario mirrors the class of issues identified in CVE-2022-31813 affecting Apache HTTP Server, where improper handling of hop-by-hop headers leads to header injection and subsequent security control evasion.
From a technical classification perspective, this vulnerability aligns with CWE-75: Bypassing Firewalls Using Packet Fragmentation or similar bypass techniques involving protocol manipulation, specifically falling under the broader category of Improper Input Validation (CWE-20) regarding hop-by-hop headers. In terms of the MITRE ATT&CK framework, this behavior facilitates unauthorized access and privilege escalation by allowing attackers to manipulate request metadata that is critical for identity verification, effectively enabling them to masquerade as trusted clients or bypass network-level restrictions intended to limit access based on source IP addresses. The exploitability relies heavily on specific deployment architectures; notably, Cloudflare CDN customers were unaffected because their internal architecture does not utilize the described chained HTTP/1 intermediary pattern between Pingora services and origin servers, and Connection headers are sanitized at the gateway level before reaching the proxy logic in question.
To mitigate this vulnerability, organizations running pingora-proxy versions earlier than 0.9.0 must upgrade to version 0.9.0 or later immediately. The updated release enforces strict compliance with RFC standards by automatically removing hop-by-hop headers and any headers nominated within the Connection directive from upstream requests before they are sent to the origin server. Furthermore, newer versions reject requests that attempt to nominate sensitive pseudo-headers such as Host, X-Forwarded-For, X-Forwarded-Host, or X-Forwarded-Proto through the Connection header, thereby preventing this specific attack vector at the protocol level. For deployments unable to upgrade immediately, a manual mitigation strategy involves modifying the upstream_request_filter logic to explicitly remove the Connection header and all headers it nominates before any trusted headers are added by the application code. Additionally, administrators should ensure that the HttpUpstreamRequestPolicy is not set to preserve mode if the origin server relies on pingora-added headers for security decisions, as this setting restores the vulnerable passthrough behavior observed in earlier versions.