CVE-2026-118657

## 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): 1. `X-Forwarded-Proto` 2. `X-Forwarded-Protocol` 3. `X-Forwarded-Ssl` 4. `X-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 documentation states: *"you must not trust HTTP headers unconditionally."* ### Root cause `context.go`, lines 161–181: ```go func (c *Context) Scheme() string { if c.IsTLS() { return "https" } if scheme := c.request.Header.Get(HeaderXForwardedProto); scheme != "" { return scheme } if scheme := c.request.Header.Get(HeaderXForwardedProtocol); scheme != "" { return scheme } if ssl := c.request.Header.Get(HeaderXForwardedSsl); ssl == "on" { return