CVE-2026-114437
Description
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.
Statement
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.
Mitigation
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>2. In OpenShift or Kubernetes environments, apply an Ingress NetworkPolicy ensuring pod endpoints only accept traffic from designated ingress router controllers.
firewall-cmd --permanent --remove-port=<PORT>/tcp
firewall-cmd --reload
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.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 4.8 | N/A | 4.8 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | High | N/A | High |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | Low | N/A | Low |
| Integrity Impact | Low | N/A | Low |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
cve.org: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
