CVE-2026-114437 in chi
Summary
by MITRE • 10/21/2026
In the Golang Chi web framework, the ClientIPFromXFF middleware skips any X-Forwarded-For entry in a configured trusted CIDR but never verifies that the direct TCP peer in http.Request.RemoteAddr belongs to that CIDR. A client that can reach the Go server directly can therefore append a trusted-looking proxy address and choose the client IP returned by middleware.GetClientIP.
This issue affects chi before 5.4.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/21/2026
The Chi web framework for Golang contains a critical logic flaw within its ClientIPFromXFF middleware that undermines the integrity of client identification in reverse proxy environments. This vulnerability stems from an incomplete validation process where the middleware attempts to determine the true IP address of a connecting user by parsing the X-Forwarded-For header, which is commonly used by load balancers and proxies to pass along original client addresses. The middleware operates under the assumption that if it encounters an entry in this header that matches a configured list of trusted CIDR blocks, it can safely trust subsequent entries or use those entries as valid indicators of origin without verifying the actual network path taken by the request.
The core technical flaw lies in the failure to verify that the direct TCP peer address, accessible via http.Request.RemoteAddr, actually belongs to one of the configured trusted CIDRs before processing the X-Forwarded-For header. In a properly secured architecture, only requests originating from known and trusted infrastructure components should be allowed to manipulate client IP headers. However, because Chi does not enforce this prerequisite check, any external actor who can establish a direct TCP connection to the Go server is able to inject arbitrary values into the X-Forwarded-For header. By appending an address that falls within the configured trusted CIDR range, an attacker can trick the middleware into accepting their spoofed IP as legitimate or bypassing further validation steps intended for untrusted sources.
This misconfiguration leads to significant operational impacts regarding security and compliance. Attackers can perform client IP spoofing, effectively masking their true identity while appearing to originate from a trusted internal network segment. This capability facilitates unauthorized access in systems that rely on IP-based authentication or authorization controls, allowing adversaries to bypass firewalls, intrusion detection systems, or rate-limiting mechanisms designed for specific subnets. Furthermore, it compromises the accuracy of audit logs and forensic analysis, as recorded client IPs will reflect manipulated values rather than actual connection endpoints, hindering incident response efforts and potentially violating data protection regulations that require accurate user identification.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, specifically regarding the failure to validate source identity in network protocols. It also relates to CWE-915 Improper Modification of Objects During Multithreading or Execution if concurrent requests exploit race conditions, though primarily it is an issue of logic flow and trust boundary violation similar to CWE-436 Interpretation Error. In terms of adversary tactics, this flaw supports the MITRE ATT&CK technique T1078 Valid Accounts when used in conjunction with IP whitelisting bypasses, allowing attackers to operate under the guise of trusted infrastructure components without possessing valid credentials for those systems.
To mitigate this vulnerability, organizations using versions of Chi prior to 5.4.0 should upgrade immediately to version 5.4.0 or later where this logic has been corrected. For environments unable to patch immediately, a temporary workaround involves implementing custom middleware that explicitly validates http.Request.RemoteAddr against the trusted CIDR list before allowing any processing of X-Forwarded-For headers. This ensures that only requests arriving from authorized proxy servers are permitted to influence client IP determination. Additionally, security teams should review their network architecture to ensure that direct external access to application servers is restricted by firewall rules, thereby reducing the attack surface available for this specific exploitation vector and enforcing strict trust boundaries between public-facing entry points and backend services.