CVE-2026-72816 in go-chi's RealIP middleware is a design-level failure, not an operational oversight. The middleware reads X-Forwarded-For and similar headers directly from incoming requests with zero trust verification — it performs no validation that the request actually passed through a proxy you control. This wasn't a subtle bug; it was the default behavior, and the API signature gave developers no signal that they needed to configure trust boundaries.
The CVSS 6.5 rating is misleading because it assumes exploitability depends on improper deployment. But when a middleware makes the insecure option the path of least resistance — requiring zero configuration — a significant portion of production deployments fall into that 'improper' category. Go applications built on chi disproportionately serve infrastructure roles: API gateways, microservice backends, internal platforms. A spoofed IP in these contexts doesn't just bypass one service's rate limiting; it injects false identity into a distributed system where downstream services trust that value implicitly. The blast radius extends across your entire request chain.
The 5.3.0 fix introduced a trusted proxy configuration mechanism, but examine what actually changed. If the fix mandates explicit proxy whitelisting as a required parameter, that's a structural API change — and you need to verify your deployment can actually supply that configuration. Static IP whitelists break in Kubernetes environments with ephemeral pod IPs, Istio sidecars, and layered service mesh proxies. If the migration path is too friction-heavy, developers historically respond by removing the middleware entirely and writing their own realIP() in application code — recreating exactly the vulnerability the fix was meant to eliminate, now hidden from CVE tracking.
Check your dependency graph now. Go's module resolution can lock transitive dependencies to vulnerable versions if a downstream service pins a chi major version. go mod graph | grep chi to see what you're actually pulling. And audit any custom IP-handling middleware you may have added as a workaround — it likely re-implements the same unsanitized header reading this CVE exists to fix.