Summary
A request-header handling flaw in Pingora's HTTP/1 upstream path can allow a client to nominate headers for removal through the Connection header. In certain chained deployments, an intermediary may strip trusted headers added by Pingora, potentially enabling authorization bypass when the origin relies on those headers.
A request-header handling flaw in Pingora's HTTP/1 upstream path can allow a client to nominate headers for removal through the Connection header. In certain chained deployments, an intermediary may strip trusted headers added by Pingora, potentially enabling authorization bypass when the origin relies on those headers.
Affected context
The vulnerability occurs in Pingora deployments where:
- Downstream clients can send HTTP/1 requests containing Connection header nominations
- Pingora adds or transforms trusted headers in an upstream request filter
- Another HTTP/1 intermediary sits between Pingora and the origin
- The intermediary honors Connection-nominated headers and removes them
- The origin trusts headers such as X-Forwarded-For for authorization or client identity
Deployments that sanitize Connection headers before requests reach Pingora, or that do not use an intermediary with this behavior, may not expose the same risk.
The vulnerability occurs in Pingora deployments where:
- Downstream clients can send HTTP/1 requests containing Connection header nominations
- Pingora adds or transforms trusted headers in an upstream request filter
- Another HTTP/1 intermediary sits between Pingora and the origin
- The intermediary honors Connection-nominated headers and removes them
- The origin trusts headers such as X-Forwarded-For for authorization or client identity
Deployments that sanitize Connection headers before requests reach Pingora, or that do not use an intermediary with this behavior, may not expose the same risk.
Exploit preconditions
- Attack surface: HTTP/1 request handling through a Pingora proxy
- Required access: Remote network access to an exposed Pingora endpoint; authentication is generally not required
- Trigger point: Processing of a downstream Connection header and subsequent upstream request forwarding
- Chained dependency: An HTTP/1 intermediary must process Connection nominations between Pingora and the origin
- Trust dependency: The origin must rely on headers added by Pingora or an earlier trusted proxy for authorization
- Why exploitation is possible: Pingora can forward client-controlled hop-by-hop nominations without removing the nominated headers, allowing a downstream intermediary to delete trusted upstream headers
- Attack surface: HTTP/1 request handling through a Pingora proxy
- Required access: Remote network access to an exposed Pingora endpoint; authentication is generally not required
- Trigger point: Processing of a downstream Connection header and subsequent upstream request forwarding
- Chained dependency: An HTTP/1 intermediary must process Connection nominations between Pingora and the origin
- Trust dependency: The origin must rely on headers added by Pingora or an earlier trusted proxy for authorization
- Why exploitation is possible: Pingora can forward client-controlled hop-by-hop nominations without removing the nominated headers, allowing a downstream intermediary to delete trusted upstream headers
Why this happens
The underlying bug is incomplete hop-by-hop header sanitization in the HTTP/1 upstream request path. Pingora forwarded the downstream request through its upstream filtering logic without removing the Connection header, other hop-by-hop headers, or headers nominated by Connection, even though intermediaries are required to remove them.
This maps to CWE-444: Inconsistent Interpretation of HTTP Requests, because different components in a proxy chain interpret the same request headers differently. A client can exploit the discrepancy between Pingora's forwarding behavior and a downstream intermediary's Connection-header processing to alter the headers ultimately received by the origin.
The underlying bug is incomplete hop-by-hop header sanitization in the HTTP/1 upstream request path. Pingora forwarded the downstream request through its upstream filtering logic without removing the Connection header, other hop-by-hop headers, or headers nominated by Connection, even though intermediaries are required to remove them.
This maps to CWE-444: Inconsistent Interpretation of HTTP Requests, because different components in a proxy chain interpret the same request headers differently. A client can exploit the discrepancy between Pingora's forwarding behavior and a downstream intermediary's Connection-header processing to alter the headers ultimately received by the origin.
Potential impact
- An attacker could bypass IP-based or header-based authorization controls
- Trusted forwarding headers could be removed before reaching the origin
- The origin could make access-control decisions using incomplete client identity information
- Proxy-chain security assumptions could be undermined
- Requests could be interpreted inconsistently across intermediary layers
- An attacker could bypass IP-based or header-based authorization controls
- Trusted forwarding headers could be removed before reaching the origin
- The origin could make access-control decisions using incomplete client identity information
- Proxy-chain security assumptions could be undermined
- Requests could be interpreted inconsistently across intermediary layers
General mitigation guidance
Mitigation generally focuses on consistent hop-by-hop header processing across every proxy layer.
Common defensive patterns include:
- Removing the Connection header and every header it nominates before forwarding requests upstream
- Stripping all HTTP/1 hop-by-hop headers at trust-boundary transitions
- Rejecting requests that nominate security-sensitive headers such as Host or forwarding headers
- Applying a secure-by-default upstream request policy rather than preserving arbitrary client headers
- Avoiding policies that restore legacy passthrough behavior when the origin relies on proxy-added headers
- Reducing input trust by overwriting, rather than accepting, client-supplied forwarding headers
- Ensuring origins accept identity and authorization headers only from explicitly trusted proxy paths
- Running origins with least privilege and using defense-in-depth authorization checks that do not depend solely on forwarding headers
Mitigation generally focuses on consistent hop-by-hop header processing across every proxy layer.
Common defensive patterns include:
- Removing the Connection header and every header it nominates before forwarding requests upstream
- Stripping all HTTP/1 hop-by-hop headers at trust-boundary transitions
- Rejecting requests that nominate security-sensitive headers such as Host or forwarding headers
- Applying a secure-by-default upstream request policy rather than preserving arbitrary client headers
- Avoiding policies that restore legacy passthrough behavior when the origin relies on proxy-added headers
- Reducing input trust by overwriting, rather than accepting, client-supplied forwarding headers
- Ensuring origins accept identity and authorization headers only from explicitly trusted proxy paths
- Running origins with least privilege and using defense-in-depth authorization checks that do not depend solely on forwarding headers
How teams detect issues like this
Detection approaches can include:
- Static analysis and configuration checks for proxy paths that forward Connection or hop-by-hop headers
- Code review searches for header-copying logic that runs before hop-by-hop sanitization
- Tests that compare headers received by the origin across HTTP/1 proxy chains
- Negative tests for Connection nominations targeting Host, X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto
- Policy enforcement requiring explicit allowlists for forwarded and security-sensitive headers
- Runtime logging of Connection headers, nominated fields, and the final upstream header set
Automated security review tools can help identify inconsistent header filtering, although chained integration tests are important for validating actual intermediary behavior.
Detection approaches can include:
- Static analysis and configuration checks for proxy paths that forward Connection or hop-by-hop headers
- Code review searches for header-copying logic that runs before hop-by-hop sanitization
- Tests that compare headers received by the origin across HTTP/1 proxy chains
- Negative tests for Connection nominations targeting Host, X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto
- Policy enforcement requiring explicit allowlists for forwarded and security-sensitive headers
- Runtime logging of Connection headers, nominated fields, and the final upstream header set
Automated security review tools can help identify inconsistent header filtering, although chained integration tests are important for validating actual intermediary behavior.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
