Go Chi CVE-2026-114437

Exploitation requires the target application to use chi's ClientIPFromXFF middleware configured with at least one trusted CIDR, AND to consume the resulting value via middleware.GetClientIP for a security-relevant purpose (IP allowlisting, rate limiting, geolocation, or audit logging). The attacker must be able to connect to the Go server directly rather than exclusively through the legitimate reverse proxy, because the bug is that RemoteAddr (the direct TCP peer) is never checked against the trusted CIDR. Limiting factors: the vulnerable middleware is opt-in and not part of chi's default routing; the attacker benefits from knowing the configured trusted CIDR to append a convincing proxy address; and if a fronting proxy strips or overwrites X-Forwarded-For and no direct network path to the Go server exists, exploitation is blocked. Deployments that do not derive trust from the client IP are unaffected in practice.

This is a moderate-severity logic flaw (CWE-348, Use of Less Trusted Source / IP spoofing) in the go-chi ClientIPFromXFF middleware, scored CVSS 4.0 6.3 by the reporter. The 4.0 vector (AV:N/AC:H/PR:N/UI:N) shows an unauthenticated, remotely reachable issue but with high attack complexity and only Low confidentiality and integrity impact (VC:L/VI:L) and no availability impact - consistent with trust/spoofing bugs rather than code execution. No EPSS score, CISA KEV listing, or public POC was provided in the input, so by the precision rule the status is 'no public exploit identified at time of analysis.' The real-world priority is conditional rather than universal: the flaw only matters for applications that both enable this specific middleware with a trusted-CIDR configuration AND make security decisions (access control, rate limiting, audit logging) based on the returned client IP. Where that pattern exists the bug is genuinely exploitable and meaningful; where it does not, impact is negligible. The AC:H rating is reasonable because the attacker must reach the Go server directly (bypassing legitimate proxies) and understand the configured trusted CIDRs. No signals conflict; the chief limiting factor is the non-default, configuration-dependent nature of the vulnerable code path.

An application uses chi's ClientIPFromXFF middleware with a trusted proxy CIDR and enforces IP-based access control or rate limiting via GetClientIP. An attacker who can reach the Go server directly (not through the real proxy) sends a request with a crafted X-Forwarded-For header appending a trusted-looking proxy address, causing the middleware to return an attacker-chosen client IP and thereby spoof their source to bypass IP allowlists, evade rate limits, or forge audit log entries. No public exploit code was identified in the provided data, though the technique is trivial to reproduce once the trusted CIDR is known.