CVE-2026-114437

A flaw was found in chi. The ClientIPFromXFF middleware evaluates IP addresses in the X-Forwarded-For (XFF) HTTP header, but fails to verify that the direct incoming network connection originates from a trusted IP address range. A remote attacker who can connect directly to the server can exploit this flaw by supplying a forged proxy address in the header. This allows the attacker to spoof their client IP address, potentially bypassing IP-based access controls and security logging.

This vulnerability is rated as Moderate severity because exploitation requires direct network access to bypass reverse proxies and only affects services configured to rely on the optional ClientIPFromXFF middleware for security decisions. In standard Red Hat product architectures, backend components are deployed behind ingress controllers, load balancers, or API gateways that isolate endpoints and control header propagation. Consequently, the potential for IP spoofing is constrained to custom or non-standard deployments where untrusted network actors can establish direct connections to the application port.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

Restrict network exposure so that the application only accepts connections from trusted reverse proxies or load balancers, preventing direct client reachability:

1. Configure firewall rules on the host to only allow traffic from trusted proxy IP addresses to the application port:

firewall-cmd --permanent --zone=trusted --add-source=<TRUSTED_PROXY_IP>
firewall-cmd --permanent --remove-port=<PORT>/tcp
firewall-cmd --reload

2. In OpenShift or Kubernetes environments, apply an Ingress NetworkPolicy ensuring pod endpoints only accept traffic from designated ingress router controllers.
3. Configure the upstream reverse proxy (e.g., Envoy, HAProxy, or NGINX) to strip or sanitize incoming X-Forwarded-For headers from untrusted external clients before routing requests to backend services.

Caveats: Restricting direct access may interrupt client traffic if services were previously exposed directly without a proxy. Reloading firewalld with firewall-cmd --reload will briefly reapply filtering rules and may affect active network sessions.