CVE-2026-118657 in Echo
Summary
by MITRE • 10/28/2026
Echo is a Go web framework. Prior to 4.16.0 and 5.4.0, Context.Scheme unconditionally trusts forwarded scheme headers from any client. A client that reaches Echo directly over plaintext HTTP can claim an HTTPS scheme and bypass HTTPSRedirect because the request is treated as already secure. Separately, behind a TLS-terminating proxy that passes an attacker-controlled header, a claimed HTTP scheme can suppress the Strict-Transport-Security header even though the browser receives the response over HTTPS. The practical risk is reduced when a trusted proxy overwrites the headers and direct backend access is prevented, but the framework previously had no trusted-source configuration for this decision. This issue is fixed in 4.16.0 and 5.4.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Echo web framework for Go contains a critical security vulnerability related to how it handles forwarded scheme headers from clients. Prior to versions 4.16.0 and 5.4.0, the Context.Scheme method unconditionally trusts any X-Forwarded-Proto or similar header provided by the client without validation against a trusted source list. This design flaw allows an attacker who can send HTTP requests directly to the Echo server over plaintext connections to manipulate the perceived protocol scheme of the request. By setting headers that indicate HTTPS, such as X-Forwarded-Proto: https, the attacker tricks the framework into believing the connection is secure when it is not.
This misrepresentation has significant implications for security middleware and routing logic within applications built on Echo. Specifically, it enables bypassing of the HTTPSRedirect middleware which relies on Context.Scheme to determine whether a redirect to an HTTPS URL is necessary. If a client claims the scheme is HTTPS while actually communicating over HTTP, the framework will not initiate a redirect, leaving sensitive data transmitted in plaintext and vulnerable to interception via man-in-the-middle attacks. This represents a classic case of insecure direct object references or improper trust boundary enforcement where user-controlled input dictates security-critical state decisions without adequate validation.
In environments behind TLS-terminating proxies, such as load balancers or reverse proxies like Nginx or HAProxy, the vulnerability manifests differently but with equally severe consequences. When these proxies forward requests to backend Echo servers, they may pass along scheme headers that reflect their own connection status rather than the original client's intent. If an attacker can control or inject specific headers into this chain, even indirectly through header injection techniques in upstream services, they might cause the Echo server to believe it is serving content over HTTP when it is actually being served over HTTPS via the proxy. This confusion leads to the suppression of security-critical response headers such as Strict-Transport-Security (HSTS). The absence of HSTS means browsers will not enforce future connections to be secure, potentially allowing downgrade attacks or cookie theft in subsequent interactions.
The root cause lies in the lack of a trusted-source configuration mechanism within Echo prior to these updates. Without explicit whitelisting of proxy IP addresses or header sources that are authorized to set scheme information, the framework defaults to trusting all incoming headers regardless of their origin. This violates fundamental principles of secure system design which dictate that security decisions must be based on verified and authenticated inputs rather than untrusted external data. The vulnerability aligns with CWE-287 Improper Authentication as it involves misidentification due to trusted input failure, and also relates to CWE-16 Configuration issues where the default configuration is insecure by trusting all sources.
Mitigation requires upgrading Echo to version 4.16.0 or 5.4.0 which introduces mechanisms for configuring trusted proxies and headers. Administrators should ensure that their deployment architecture prevents direct client access to backend servers, enforcing communication only through authorized TLS-terminating proxies. Furthermore, proxy configurations must be set to overwrite scheme headers with values derived from the actual connection protocol rather than forwarding potentially malicious client-supplied values. Implementing these controls ensures that Context.Scheme accurately reflects the true security state of the connection, thereby preserving the integrity of HTTPS redirects and HSTS enforcement mechanisms essential for protecting user data in transit.