~ / search / GHSA-h53f-rm2w-w7rg

GHSA-h53f-rm2w-w7rg

Echo: X-Real-IP extractor trusts the header value instead of the sending peer

Source: GitHub Advisory Database (reviewed) Moderate CVE-2026-118265

Packages

EcosystemPackageAffectedFixed 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.