CVE-2026-118262

In the Echo Go web framework prior to 4.15.2 and 5.1.1, Context.Scheme returns values from X-Forwarded-Proto, X-Forwarded-Protocol, or X-Url-Scheme headers without validating that they are supported web schemes. WWWRedirect and NonWWWRedirect use that value to construct a Location header, so an attacker controlling a forwarded scheme header can cause a redirect to use an arbitrary URI scheme. Exploitation requires an affected redirect middleware and user interaction with the response; the HTTPS-specific redirect variants hardcode HTTPS and are unaffected.

In the Echo Go web framework prior to 4.16.0 and 5.4.0, Context.Scheme unconditionally trusts forwarded scheme headers from any client. A client that reaches Echo directly over plaintext HTTP can claim an HTTPS scheme and bypass HTTPSRedirect because the request is treated as already secure. Separately, behind a TLS-terminating proxy that passes an attacker-controlled header, a claimed HTTP scheme can suppress the Strict-Transport-Security header even though the browser receives the response over HTTPS.

In the Echo Go web framework prior to 4.16.0 and 5.4.0, sanitizeURI checks only the first two bytes of a redirect target before deciding whether it begins with an absolute-path separator pair. When AddTrailingSlash or RemoveTrailingSlash is configured with a redirect status, a slash, TAB, separator path form can evade the guard, be emitted in the Location header, and be normalized by a browser into an attacker-controlled host.

In Echo before 4.15.3 and 5.2.0, middleware.Static can decode an already decoded Request.URL.Path a second time. Double-encoded separators can be reconstructed before filesystem resolution, reaching a file under a guarded route when static middleware is registered globally.

In Echo before 4.16.0 and 5.4.0, static file handlers can normalize dot segments after route matching and serve a file through a public static route even though the direct path is protected by route-level middleware. This is an incomplete fix for CVE-2026-55677.

In Echo from 4.0.0 until 5.1.0, Context.RealIP falls back to client-supplied X-Forwarded-For or X-Real-IP when Echo.IPExtractor is unset, and the default RateLimiter uses that result as the client identifier. An attacker can rotate forwarded-address values to obtain new rate-limit buckets and bypass IP-based throttling.

In Echo before 4.16.0 and 5.4.0, Context.JSONP and Context.JSONPBlob concatenate an unvalidated callback value into a JavaScript response. A route passing attacker-controlled input as the callback can return executable script syntax, enabling reflected cross-site scripting.

In Echo from 4.0.0 until 5.4.0, the Proxy middleware can preserve an attacker-supplied X-Real-IP header and forward it to an upstream service when Echo.IPExtractor is not configured. A remote client can thus make upstream services receive a spoofed client address.

In the Echo Go web framework before 4.16.0 and 5.4.0, a globally mounted middleware.Static instance can interpret an encoded request path differently from the router. The router matches the still-encoded path while the static handler uses the decoded URL.Path, potentially exposing files.

In the Echo Go web framework prior to 4.16.0 and 5.4.0, the MethodOverride middleware accepts a safe HTTP method as the override target for a POST request. When MethodOverride is registered before CSRF in the post-routing middleware chain, route selection retains the original state-changing POST handler but the override changes the method before CSRF evaluates it, causing both token validation and Sec-Fetch-Site checks to be skipped. A cross-site exploit requires an authenticated victim and an override value controllable by a browser-submitted request, such as the form getter used by the advisory reproducer; the default X-HTTP-Method-Override header getter is not settable by a cross-site form.