CVE-2026-118265 in Echo
Summary
by MITRE • 10/28/2026
Echo is a Go web framework. From 5.0.0 until 5.4.1, Echo v5's ExtractIPFromRealIPHeader validates whether the client-supplied X-Real-IP value belongs to a trusted range instead of validating the direct network peer. A client reaching Echo directly, or through a proxy that preserves the header, can supply a loopback or private address and have Context.RealIP return that spoofed identity. Applications using the extractor for IP allowlists, rate limiting, audit logs, or forwarding headers can consequently trust an attacker-controlled address; the default direct extractor and Echo v4 are unaffected. This issue is fixed in 5.4.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified within the Echo web framework version 5 through 5.4.1 represents a critical misconfiguration in how client IP addresses are resolved, specifically affecting the ExtractIPFromRealIPHeader function. In standard HTTP architectures, determining the true origin of a request is complicated by the presence of intermediaries such as reverse proxies, load balancers, or content delivery networks. These intermediaries often modify headers to reflect the original client's address rather than their own internal IP addresses. Commonly used headers for this purpose include X-Forwarded-For and X-Real-IP. The Echo framework provides mechanisms to parse these headers securely by validating that the source of the header is a trusted proxy, thereby preventing attackers from spoofing their origin via manipulated HTTP headers. However, in versions 5.0.0 through 5.4.1, the logic governing ExtractIPFromRealIPHeader contained a flaw where it validated whether the value supplied in the X-Real-IP header belonged to a trusted range of proxy servers, rather than validating that the actual network peer connecting to the Echo server was one of those trusted proxies.
This architectural oversight creates a significant security gap known as HTTP Request Smuggling or IP Spoofing via misconfigured trust boundaries. When an application relies on Context.RealIP for critical security decisions, it assumes the returned address is authentic and untampered with by the end-user client. Because Echo v5 validated the content of the header against trusted ranges instead of validating the source connection itself, any client that could reach the Echo server directly or through a proxy that preserves headers unmodified was able to inject arbitrary values into the X-Real-IP header. An attacker could supply loopback addresses such as 127.0.0.1 or private network ranges like 192.168.x.x, causing the framework to return these spoofed identities instead of the actual client IP address. This behavior effectively bypasses any security controls that depend on accurate source identification, allowing attackers to masquerade as internal systems or trusted entities within a local network topology.
The operational impact of this vulnerability is severe for applications implementing access control lists, rate limiting mechanisms, audit logging, or header forwarding based on client IP addresses. If an application uses the RealIP value to enforce allowlists that permit traffic from specific private ranges, such as internal monitoring services or administrative interfaces, an external attacker can trivially bypass these restrictions by setting X-Real-IP to a permitted address. Similarly, rate limiting algorithms that track requests per source IP would fail to throttle malicious actors who continuously rotate their spoofed IPs or claim to be local clients exempt from throttling policies. In audit logs and forensic analysis, the recorded origin of attacks would be falsified, complicating incident response efforts by obscuring the true attacker location. This flaw is distinct in that it specifically affects Echo v5 implementations using this extractor; the default direct IP extraction method and previous versions like Echo v4 remain unaffected as they do not exhibit this specific validation logic error regarding header source verification versus content range checking.
To mitigate this vulnerability, organizations running affected versions of the Echo framework must upgrade immediately to version 5.4.1 or later, where the issue has been resolved by correcting the trust boundary validation logic. Until an upgrade is feasible, developers should avoid using ExtractIPFromRealIPHeader for security-critical decisions and instead rely on direct peer address extraction methods that do not parse potentially untrusted headers from external sources. It is also advisable to configure reverse proxies at the network edge to strip or overwrite X-Real-IP headers with verified values before they reach the application server, ensuring that only trusted infrastructure can set these fields. This vulnerability aligns with CWE-287 Improper Authentication and CWE-918 Server-Side Request Forgery (SSRF) implications when used in conjunction with internal service discovery mechanisms. From a threat modeling perspective using MITRE ATT&CK techniques, this flaw facilitates T1046 Network Service Discovery by allowing attackers to probe internal services under the guise of trusted IPs, and supports T1078 Valid Accounts if combined with credential-based attacks that rely on IP whitelisting for authentication bypass.