GHSA-fq95-v8xc-jm3v: Medium severity go/github.com/fabiolb/fabio vulnerability
Affected: github.com/fabiolb/fabio >= 1.6.6 through 1.7.1 and master HEAD (c75f8a6).
Summary The v1.6.6 fix for CVE-2025-48865 sweeps the client Connection header against a hardcoded allowlist protectHeaders (proxy/httpheaders.go:28-36) containing only the 7 X-Forwarded family headers. Fabio also injects three operator-configured server-side trust headers that are NOT in that allowlist, so the original hop-by-hop stripping attack still works against them.
Details The three unprotected trust headers and where fabio sets them: - ClientIPHeader (proxy.header.clientip) - httpheaders.go:73 r.Header.Set(cfg.ClientIPHeader, remoteIP) - TLSHeader (proxy.header.tls) - httpheaders.go:153 r.Header.Set(cfg.TLSHeader, cfg.TLSHeaderValue) (TLS connections) - RequestID (proxy.header.requestid) - httpproxy.go:90 r.Header.Set(p.Config.RequestID, id())
Order of operations in HTTPProxy.ServeHTTP: (1) line 90 sets RequestID; (2) line 175 calls addHeaders, which sweeps the Connection header (keeping the three configured names because they are absent from protectHeaders) and then sets ClientIPHeader/TLSHeader; (3) line 223 runs the Go httputil.ReverseProxy, whose removeHopByHopHeaders (Go stdlib net/http/httputil/reverseproxy.go) iterates the inbound Connection header and h.Dels every listed header. The three trust headers fabio just set are therefore deleted before the request reaches the backend.
PoC Configure proxy.header.clientip=X-Client-IP, proxy.header.requestid=X-Request-ID. Raw request: GET / HTTP/1.1 Host: foo.com Connection: close, X-Client-IP, X-Request-ID Backend sees X-Client-IP: <empty> and X-Request-ID: <empty>. Baseline (Connection: close) => backend sees the real client IP and a request id. The same works for proxy.header.tls over TLS (Connection: close, X-Secure strips the TLS assertion). Reproduced by the two PASS-ing tests in proxy/poccve48865incompletetest.go on master HEAD (Go 1.26.4). Control: X-Forwarded-For (in protectHeaders) survives, confirming the gap is specific to the configured headers.
Impact Where a backend trusts these fabio-set headers, an external unauthenticated client can strip/downgrade the trust signal: bypass/poison IP-based ACL or audit that reads the clientip header, downgrade a TLS-terminated request to appear non-TLS to a backend keying off the TLS header, or drop request-id correlation. Scope: deployments that enable the relevant proxy.header. option (all empty by default). Fix: add the configured ClientIPHeader/TLSHeader/RequestID names to the protectHeaders set (or strip their token from the inbound Connection header) inside addHeaders.
Parent: CVE-2025-48865 / GHSA-q7p4-7xjv-j3wf (fixed in v1.6.6). This is an incomplete-fix sibling - the same hop-by-hop stripping primitive applies to the operator-configured trust headers the allowlist does not cover.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/fabiolb/fabioto a version that resolves this vulnerability.Fixed in 1.7.2 - Configuration
Inside addHeaders, add the configured ClientIPHeader, TLSHeader, and RequestID names to the protectHeaders set, or strip their tokens from the inbound Connection header so the Go ReverseProxy cannot remove the Fabio-injected trust headers.
github.com/fabiolb/fabio protectHeaders = Include the configured ClientIPHeader, TLSHeader, and RequestID names
Event History
Frequently Asked Questions
Which deployments are exposed?
The affected range is fabio versions 1.6.6 through 1.7.1, as well as master at commit c75f8a6. Exposure concerns deployments using the operator-configured ClientIPHeader, TLSHeader, or RequestID trust headers.
What does an attacker need to exploit this issue?
An unauthenticated network client can send a Connection header that names one of the configured trust headers. Because those headers are not included in the hardcoded protection allowlist, the hop-by-hop header stripping behavior can remove them.
What can be affected by a successful request?
The affected trust signals are the configured client IP header, TLS indicator header, and request ID header. The described effect is removal of these proxy-injected headers before they reach the backend, which can undermine backend decisions or logging that rely on them.
Is a fixed release or temporary workaround identified?
The provided data references commit 240526a8004077edad4fb96d25b382bfc3901357, but does not identify a fixed release version or a temporary workaround. Until a remediation is confirmed, deployments should assess whether backends rely on the configured trust headers listed in the advisory.