GHSA-9g5q-2w5x-hmxf — chi Middleware Vulnerable to Potential IP Spoofing via `X-Forwarded-For` Header in `Request.RemoteAddr` Resolution

Affected: Go: github.com/go-chi/chi/middleware, Go: github.com/go-chi/chi/v2/middleware, Go: github.com/go-chi/chi/v3/middleware, Go: github.com/go-chi/chi/v4/middleware, Go: github.com/go-chi/chi/v5/middleware

### Summary The vulnerability allows the `Request.RemoteAddr` to be spoofed when determining the request source IP via the `X-Forwarded-For` header. This could result in misidentification of the request source and potentially compromise access control and logging integrity.

### Details Currently, the `RealIP()` implementation splits the `X-Forwarded-For` header by `,` and uses the first IP. https://github.com/go-chi/chi/blob/v5.1.0/middleware/realip.go#L50-L54

However, relying on the first IP in the `X-Forwarded-For` header is insecure because it can be manipulated by attackers to falsify the source IP.

Malicious Case: 1. A malicious client sends a request with a forged IP in the X-Forwarded-For header: `X-Forwarded-For: <forged-ip>` 2. The proxy appends the actual client’s IP and forwards the request: `X-Forwarded-For: <forged-ip>,<client-ip>` 3. If the server always uses the first IP, it becomes vulnerable to IP spoofing.

Ideally, the implementation should verify IPs starting from the end of the `X-Forwarded-For` header value, skipping trusted IPs within the system, and using the first untrusted IP as the actual client IP.

For example, the `labstack/echo` web framework processes the `X-Forwarded-For` header by checking IPs from the end, skipping trusted IPs, and using the first untrusted IP as the client's ip. https://github.com/labstack/echo/blob/v4.13.2/ip.go#L261-L273

### PoC #### 1. Run the Go application with the following code: ```go package main

import (…

Most recent entries from all

GHSA-9g5q-2w5x-hmxf — chi Middleware Vulnerable to Potential IP Spoofing via `X-Forwarded-For` Header in `Request.RemoteAddr` Resolution