Echo: HTTPS Redirect and HSTS Bypass via Unconditional Trust of Forwarded Scheme Headers
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| labstack | echo | — | — |
| go | github.com/labstack/echo/v5 |
5.4.0 未満 |
5.4.0 |
| go | github.com/labstack/echo/v4 |
4.16.0 未満 |
4.16.0 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Description
Context.Scheme() unconditionally trusts four client-controlled HTTP headers to determine the request scheme, with no mechanism to configure trusted sources. This allows a remote unauthenticated attacker to bypass HTTPS redirect enforcement and suppress HSTS headers.
The trusted headers (checked in this order of precedence):
X-Forwarded-ProtoX-Forwarded-ProtocolX-Forwarded-SslX-Url-Scheme
Threat model
Scenario A — Directly exposed application (vulnerable by default):
The Echo application listens on HTTP and is reachable directly by clients (no L7 proxy in front), or an attacker can bypass the proxy and reach the backend directly. In this case, the attacker has full control over all request headers. Sending X-Forwarded-Proto: https defeats the HTTPSRedirect middleware entirely — traffic stays on plaintext HTTP, enabling man-in-the-middle attacks.
This is the primary scenario. The application is vulnerable by default with no misconfiguration required — simply using e.Pre(middleware.HTTPSRedirect()) as documented is sufficient.
Scenario B — Behind L7 proxy with header sanitization (reduced risk):
If the application is strictly behind a correctly configured L7 proxy that always overwrites X-Forwarded-Proto and there is no direct access to the backend, the practical risk is lower. However, this relies on perimeter controls external to the framework, not on the framework itself. As Echo's own IP-extraction documentati…
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory