Cloudflare Pingora CVE-2026-105299

Requires a specific chained topology, not a default deployment: a pre-0.9.0 Pingora proxy forwarding over its HTTP/1 upstream path (the HTTP/2 path already strips Connection and is unaffected), placed in front of a downstream HTTP/1 intermediary that honors Connection nominations (e.g. Go's net/http/httputil.ReverseProxy), where the origin trusts a header that Pingora adds in upstream_request_filter (e.g. X-Forwarded-For for IP-based authorization). Limiting factors: the vulnerable HTTP/1 intermediary and the origin's trust of a Pingora-added header must both be present; deployments on 0.9.0+ with default policy are protected (and remain vulnerable only if they opt into HttpUpstreamRequestPolicy::preserve()); Cloudflare CDN customers are explicitly unaffected because no such chain exists internally and Connection headers are sanitized before reaching Pingora gateways.

Signals are mixed and point to a conditional, not broad, priority. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N, base 8.7) correctly flags AC:H - exploitation is not against a default install but depends on a specific chained topology. No EPSS score was provided and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation. The reporter demonstrated a working proof-of-concept privately (access to an IP-restricted endpoint via X-Forwarded-For), but no public exploit code was supplied in the input, so this is 'no public exploit identified at time of analysis' rather than confirmed in-the-wild use. No SSVC decision data was provided. The high base score is driven by the authorization-bypass potential (C:H) and scope change (S:C, because the flaw in Pingora undermines the origin's trust boundary), but real-world risk is gated by the requirement that a downstream HTTP/1 intermediary honor Connection nominations AND that the origin trust a Pingora-added header for access control. For deployments without that exact chain - including all Cloudflare CDN customers, per the vendor note - real risk is low. Net: a genuine, verifiable authorization-bypass bug for a specific minority of deployments, not a drop-everything mass-exploitation event.

An attacker sends an HTTP/1 request through a pre-0.9.0 Pingora proxy with a Connection header that nominates a trusted header (e.g. 'Connection: X-Forwarded-For'); Pingora adds X-Forwarded-For in upstream_request_filter but fails to strip the attacker's Connection nomination. A downstream HTTP/1 intermediary (such as Go's httputil.ReverseProxy) honors the nomination and removes the Pingora-set X-Forwarded-For before it reaches the origin, so the origin's IP-based authorization is bypassed. A private PoC exists (reporter-demonstrated), but no public exploit code was provided; AC:H reflects the required multi-hop deployment topology.