Summary
chi Middleware Vulnerable to Potential IP Spoofing via X-Forwarded-For Header in Request.RemoteAddr Resolution
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:
- A malicious client sends a request with a forged IP in the X-Forwarded-For header:
X-Forwarded-For: <forged-ip> - The proxy appends the actual client’s IP and forwards the request:
X-Forwarded-For: <forged-ip>,<client-ip> - 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:
package main
import (
"fmt"
"log"
"net/http"
"github.com/go-chi/chi/v5/middleware"
)
func main() {
// Set handler to print the remote address
handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(
w,
fmt.Sprintf("remote addr: %s (want 192.0.2.1)", r.RemoteAddr),
)
})
// Use RealIP middleware
log.Fatal(http.ListenAndServe(":8080", middleware.RealIP(handler)))
}
2. Send a request to the server using curl with a manipulated X-Forwarded-For header:
$ curl localhost:8080 -H 'X-Forwarded-For: 192.0.2.2, 192.0.2.1'
remote addr: 192.0.2.2 (want 192.0.2.1)
Impact
This vulnerability can lead to a request source IP spoofing issue, which may allow attackers to bypass access controls or falsify request logs. It primarily affects systems that rely on X-Forwarded-For to determine the actual client IP, particularly in scenarios where intermediary proxies or load balancers are involved.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-9G5Q-2W5X-HMXF? GHSA-9G5Q-2W5X-HMXF is a high-severity security vulnerability in github.com/go-chi/chi/middleware (go), affecting versions >= 0.9.0, <= 1.5.5. It is fixed in 5.3.0.
- Which packages are affected by GHSA-9G5Q-2W5X-HMXF?
github.com/go-chi/chi/middleware(go) (versions >= 0.9.0, <= 1.5.5)github.com/go-chi/chi/v2/middleware(go) (versions <= 2.1.1)github.com/go-chi/chi/v3/middleware(go) (versions <= 3.3.5)github.com/go-chi/chi/v4/middleware(go) (versions <= 4.1.3)github.com/go-chi/chi/v5/middleware(go) (versions < 5.3.0)
- Is there a fix for GHSA-9G5Q-2W5X-HMXF? Yes. GHSA-9G5Q-2W5X-HMXF is fixed in 5.3.0. Upgrade to this version or later.
- Is GHSA-9G5Q-2W5X-HMXF exploitable, and should I be worried? Whether GHSA-9G5Q-2W5X-HMXF is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-9G5Q-2W5X-HMXF is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-9G5Q-2W5X-HMXF? Upgrade
github.com/go-chi/chi/v5/middlewareto 5.3.0 or later.