Pingora proxy: Pingora forwards client-nominated Connection headers to HTTP/1 upstreams, allowing ACL bypass in
Affects pingora-proxySource GCVE Database
Mentioned vulnerabilities
Not known to be exploited · CVSS 8.7 High : upgrade to 0.9.0 soon.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 36% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 0.9.0
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:NExploitation evidence
Disclosed: evidence found.
CVE published 20 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade pingora-proxy to 0.9.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
crates.iopingora-proxypkg:cargo/pingora-proxyOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
Pingora versions prior to 0.9.0 passed the downstream request through `upstream_request_filter` and wrote it to HTTP/1 upstreams 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. This 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. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server. This flaw was corrected in commits 28c18e6b6b04dd0bd937234e5950049e6d74cded and ca23f1668eca8e78be7ba62ef0edbd458b40eeee. 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::preserve()` restores the old passthrough behavior and should not be used if the origin relies on headers added by Pingora. Users should upgrade to Pingora >= 0.9.0. Note: 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.
References
- crates.io/crates/pingora-proxy (opens in a new tab)
- rustsec.org/advisories/RUSTSEC-2026-0390.html (opens in a new tab)
- github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded (opens in a new tab)
- github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee (opens in a new tab)