Cloudanix VulnDB

CVE-2026-114437

Medium · 4.8

CVSS

4.8

EPSS

0.1%

Published

Oct 21, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A web application could let outside visitors pretend to come from an approved address by sending a specially crafted request, potentially letting them slip past location-based security checks.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Privilege Gain
Component
Web Framework
Class
Authorization Bypass
Remediation
Upgrade
Effort
Low
Patch risk
Low

What it actually does

The ClientIPFromXFF middleware trusts any X-Forwarded-For entry whose first hop matches a configured CIDR without checking that http.Request.RemoteAddr itself belongs to that CIDR, allowing direct TCP clients to control the IP returned by GetClientIP.

Why it matters to the business

Attackers who can reach the server directly can impersonate any source IP, bypassing IP-based access controls, rate limits, or logging used for security decisions.

How an attack unfolds

An attacker opens a direct TCP connection to the Go server and supplies an X-Forwarded-For header containing a trusted proxy address followed by the desired client IP; because RemoteAddr is never validated against the trusted CIDR, GetClientIP returns the attacker-chosen value for any downstream authorization or logging logic.

How to fix it

Upgrade the chi package to version 5.4.0 or later; after upgrade, ensure ClientIPFromXFF is only used behind a terminating proxy whose address is explicitly listed in the trusted CIDR and that RemoteAddr validation is performed.

How to confirm the fix worked

After patching, send test requests both from within and outside the trusted CIDR while monitoring the IP returned by GetClientIP; confirm that only connections whose RemoteAddr matches the trusted list can influence the client IP value.

Typical attack path

  1. Establish a direct TCP connection to the listening Go server
  2. Craft an X-Forwarded-For header that begins with an address inside the configured trusted CIDR
  3. Append the desired spoofed client IP after the trusted entry
  4. Invoke application endpoints that call GetClientIP for access control or audit decisions

How to detect it

Review web server and application logs for requests whose reported client IP differs from the immediate TCP peer while X-Forwarded-For headers are present; correlate with authorization events that reference the spoofed IP.

What your security team should do

  • Upgrade chi to 5.4.0 or newer within the next maintenance window
  • Inventory all applications that import chi and use ClientIPFromXFF or GetClientIP
  • Replace or wrap IP-based authorization decisions with stronger authentication mechanisms
  • Add network-level controls so that only trusted reverse proxies can reach the Go servers directly

The record

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.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities