CVE-2026-118658 in Echo
Summary
by MITRE • 10/28/2026
Echo is a 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 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. This issue is fixed in 4.15.2 and 5.1.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The Echo web framework for Go, widely utilized for building high-performance REST APIs and microservices, contained a significant security vulnerability related to the handling of HTTP headers that influence protocol scheme determination. Specifically, prior to versions 4.15.2 and 5.1.1, the Context.Scheme method was designed to infer the network protocol used by the client connection based on standard proxy-related headers such as X-Forwarded-Proto, X-Forwarded-Protocol, or X-Url-Scheme. These headers are commonly set by reverse proxies like Nginx or load balancers to indicate whether the original request arrived via HTTP or HTTPS when the backend server is connected over plain HTTP. However, the implementation failed to validate that the values contained within these headers corresponded only to supported and safe web schemes such as http or https. This lack of input validation created a vector for header injection attacks where an attacker could manipulate the perceived scheme of the request by supplying arbitrary protocol strings in these forwarded headers.
The operational impact of this flaw is most severe when combined with Echo’s redirect middleware, specifically WWWRedirect and NonWWWRedirect functions. These utilities are designed to enforce canonical URLs by ensuring that requests use either www or non-www subdomains while preserving the original scheme. Because they rely on Context.Scheme to determine whether to generate an http:// or https:// prefix in the Location header of a 3xx redirect response, the absence of validation allows an attacker to inject arbitrary URI schemes into these redirects. For instance, if an application uses WWWRedirect and a client request includes X-Forwarded-Scheme: javascript:, the resulting redirect location could be constructed as javascript:///... rather than https://www.example.com/.... This behavior enables open redirect vulnerabilities that can lead to phishing attacks, credential theft via malicious links, or potentially other exploitation vectors depending on how downstream clients handle non-standard schemes. It is important to note that this vulnerability does not affect HTTPS-specific redirect variants which hardcode the scheme as https and thus bypass the dynamic scheme resolution logic entirely.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation, as the framework failed to restrict input values to an expected set of safe strings. It also relates to CWE-601 URL Redirection to Untrusted Site Open Redirect, given that the manipulated headers result in redirects to arbitrary destinations controlled by the attacker. In terms of MITRE ATT&CK mapping, this vulnerability facilitates techniques associated with T1583 Acquire Infrastructure for phishing campaigns or T1189 Drive-by Compromise if combined with other client-side exploitation methods, although its primary utility lies in social engineering through deceptive URLs that appear legitimate due to the correct domain but utilize a malicious scheme. The attack requires user interaction because the redirect must be followed by a victim’s browser or HTTP client for the arbitrary scheme to execute any potential side effects associated with non-standard protocols.
To mitigate this vulnerability, organizations using affected versions of Echo should upgrade immediately to version 4.15.2 or 5.1.1 where the Context.Scheme method has been patched to strictly validate that incoming header values correspond only to http and https schemes. For applications unable to update promptly, a temporary workaround involves implementing custom middleware that sanitizes X-Forwarded-Proto, X-Forwarded-Protocol, and X-Url-Scheme headers before they are processed by Echo’s context object. This preprocessing step should ensure that any value not explicitly matching the allowed whitelist of web schemes is either stripped or defaulted to https if the application operates exclusively over TLS. Additionally, developers should review their use of redirect middleware to ensure that scheme-dependent redirects are protected against header manipulation and consider enforcing strict Content-Security-Policy headers to mitigate potential client-side impacts from successful open redirect attacks.