Spoofable X-Real-IP trust in Echo v5 IP extractor
Key facts
- Attack vector
- —
- Privileges required
- —
- User interaction
- —
- Attack complexity
- —
- Impact type
- —
- Confidentiality · integrity · availability
- —
- Fix status
- Fixed
No CVSS vector from any source. Fix status from GitHub.
Summary
Echo v5 versions from 5.0.0 before 5.4.1 (github.com/labstack/echo/v5) trust the X-Real-IP header value instead of the address of the direct network peer. An untrusted client can supply a loopback or private address that c.RealIP() returns under the ExtractIPFromRealIPHeader extractor's default trust options, because the header is not validated against the sending peer (CWE-348). An attacker who can reach Echo directly, or who passes through a proxy that forwards their X-Real-IP value, can spoof a client identity for applications that use this extractor for allowlists, rate limiting or audit logs.
Written with Claude Haiku 5.5 from the sources below · 2026-10-28
Description from the GitHub advisory
## Impact In Echo v5, `ExtractIPFromRealIPHeader` checked whether the address supplied in `X-Real-IP` belonged to a trusted range instead of checking the address of the direct network peer. An untrusted client could therefore supply a loopback or private address and have it returned by `c.RealIP()` with the extractor's default trust options. Applications using this extractor for IP allowlists, IP-based rate limiting, audit logs or forwarding headers could accept a spoofed client identity. Exploitation requires that the attacker can reach Echo directly or that an intervening proxy passes through the attacker's `X-Real-IP` value. Applications using the default direct IP extractor are unaffected. Echo v4 is unaffected by this v5 regression. ## Affected versions and patch All v5 releases from v5.0.0 through v5.4.0 are affected. Upgrade to [v5.4.1](https://github.com/labstack/echo/releases/tag/v5.4.1). The patch validates the direct peer before accepting a syntactically valid `X-Real-IP` value, restoring the v4 trust model. [Fix commit](https://github.com/labstack/echo/commit/1855061e572ae9dab727c811d8382f266bfbaaec). ## Workarounds Use `ExtractIPDirect` until upgrading, or ensure that only trusted proxies can reach Echo and that they replace client-supplied forwarding headers. Configure trusted proxy ranges narrowly for the deployment. ## Credits Reported and patched by @rm-Umar. @Duodum independently reported the same issue in GHSA-c3r7-8j36-7mx8, which is tracked as a duplicate of this advisory.
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| — | github.com/labstack/echo/v5 (Go) | 5.0.0 to before 5.4.1 | 5.4.1 | Patch available | GHSA-h53f-rm2w-w7rg |
- github.com/labstack/echo/v5 (Go) Vendor— Affected 5.0.0 to before 5.4.1 Fixed in 5.4.1 Patch available GHSA-h53f-rm2w-w7rg
Remediation
Upgrade github.com/labstack/echo/v5 to version 5.4.1. Until then, use ExtractIPDirect or make sure only trusted proxies can reach Echo and that they replace client-supplied forwarding headers. Echo v4 is unaffected by this v5 regression.
Written with Claude Haiku 5.5 from the sources below · 2026-10-28
- Fix · GHSA-h53f-rm2w-w7rg github.com/labstack/echo/v5 (Go) Fixed in 5.4.1 Advisory →
Timeline
- 2026-10-23 Threatist record created from GHSA-h53f-rm2w-w7rg
References
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences