GHSA-h53f-rm2w-w7rg
Echo: X-Real-IP extractor trusts the header value instead of the sending peer
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Go | github.com/labstack/echo/v5 | >= 5.0.0, < 5.4.1 | 5.4.1 |
Details
As written in the advisory (Markdown source, shown as plain text).
## 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.
References
External links from the advisory. They lead to third-party sites.