Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

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

GHSA-9g5q-2w5x-hmxf is a CWE-345 vulnerability in github.com/go-chi/chi/middleware. A fix is available for github.com/go-chi/chi/middleware — see the affected versions and patch details below.

Also known asCVE-2026-72817GO-2026-5775
Published
Updated
Affected
5 pkgs
Patched
1 / 5
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-9g5q-2w5x-hmxf.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs14th percentile — riskier than 14% of all scored CVEsHighest risk
0.00%0.25%0.49%0.74%0.1%0.2%0.2%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

5 pkgs affected
🐹github.com/go-chi/chi/middleware🐹github.com/go-chi/chi/v2/middleware🐹github.com/go-chi/chi/v3/middleware🐹github.com/go-chi/chi/v4/middleware🐹github.com/go-chi/chi/v5/middleware

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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:

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 Packages

5 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/go-chi/chi/middleware≥ 0.9.0No fix
🐹Gogithub.com/go-chi/chi/v2/middlewareall versionsNo fix
🐹Gogithub.com/go-chi/chi/v3/middlewareall versionsNo fix
🐹Gogithub.com/go-chi/chi/v4/middlewareall versionsNo fix
🐹Gogithub.com/go-chi/chi/v5/middlewareall versions5.3.0go get github.com/go-chi/chi/v5/middleware@v5.3.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/go-chi/chi/middleware, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    No patched version of github.com/go-chi/chi/middleware has shipped for GHSA-9g5q-2w5x-hmxf yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

A flaw in the go-chi/chi RealIP middleware allows remote attackers to spoof source IP addresses (`Request.RemoteAddr`). The middleware parses the first IP address in the `X-Forwarded-For` header without verifying if the immediate HTTP proxy peer is trusted. An unauthenticated attacker can prepend an arbitrary IP…

Workaround published by Red Hat
Disable the default `RealIP` middleware and replace it with a proxy-aware middleware (such as `httputil.ReverseProxy` or custom header parsing) that strictly validates upstream reverse proxies against an explicit list of trusted CIDR ranges before accepting `X-Forwarded-For` headers.
Source: Red Hat security advisory for GHSA-9g5q-2w5x-hmxf (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Hardened Imagesspire1-14-main-1.14.7-0.4.hum1RHSA-2026:49718
Red Hat Hardened Imagesspire1-15-main-1.15.2-0.4.hum1RHSA-2026:49732
Red Hat Hardened Imagescosign-main-3.1.3-0.1.hum1RHSA-2026:54420

Frequently Asked Questions

### 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 th
O3 Security · Impact-Aware SCA

Is GHSA-9g5q-2w5x-hmxf in your dependencies?

Find it across Go, including transitive dependencies.

chi Middleware Vulnerable to Potential IP Spoofing via…