CVE-2026-118657: Echo: HTTPS Redirect and HSTS Bypass via Unconditional Trust of Forwarded Scheme Headers

Published Oct 28, 2026
·
Updated

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.

Affected Software

1 affected component
Labstack Echo<4.16.0, <5.4.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Echo to a version that resolves this vulnerability.

    Fixed in 4.16.0
  2. Upgrade

    Upgrade Echo to a version that resolves this vulnerability.

    Fixed in 5.4.0
  3. Compensating control

    Ensure a trusted TLS-terminating proxy overwrites forwarded scheme headers and prevent direct access to the backend.

Event History

Oct 28, 2026
CVE Published
via MITRE·08:14 PM
Data Sourced
via MITRE·08:14 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are realistically exposed to the redirect bypass?

Deployments are exposed when clients can reach the Echo application directly over plaintext HTTP. Such a client can claim an HTTPS scheme in forwarded headers, causing HTTPSRedirect to treat the request as already secure.

2

When can HSTS be suppressed despite the browser using HTTPS?

This can occur behind a TLS-terminating proxy if the proxy passes through an attacker-controlled forwarded scheme header. A client can claim an HTTP scheme, causing Echo to omit the Strict-Transport-Security header even though the response is delivered over HTTPS.

3

What mitigations are available if upgrading is not immediately possible?

Prevent direct access to the Echo backend and configure the trusted proxy to overwrite forwarded scheme headers rather than passing client-supplied values. These controls reduce the practical risk described for both behaviors.

4

Which releases contain the fix?

The issue is fixed in Echo 4.16.0 and 5.4.0. Versions prior to those releases are affected.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203