<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 29 Oct 2026 23:40:53 +0000</lastBuildDate>
    <item>
      <title>GHSA-2ffq-g2xg-c22p — Echo: HTTPS Redirect and HSTS Bypass via Unconditional Trust of Forwarded Scheme Headers</title>
      <link>https://db.gcve.eu/vuln/ghsa-2ffq-g2xg-c22p</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/labstack/echo/v5, Go: github.com/labstack/echo/v4&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;`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.&lt;/p&gt;
&lt;p&gt;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`&lt;/p&gt;
&lt;p&gt;### Threat model&lt;/p&gt;
&lt;p&gt;**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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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&amp;#39;s own IP-extraction documentat…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/labstack/echo/v5, Go: github.com/labstack/echo/v4&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;`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.&lt;/p&gt;
&lt;p&gt;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`&lt;/p&gt;
&lt;p&gt;### Threat model&lt;/p&gt;
&lt;p&gt;**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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;**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&amp;#39;s own IP-extraction documentat…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-2ffq-g2xg-c22p</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-118657</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-118657</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: golang-github-labstack-echo.v2, Ubuntu:20.04:LTS: golang-github-labstack-echo.v3, Ubuntu:22.04:LTS: golang-github-labstack-echo, Ubuntu:22.04:LTS: golang-github-labstack-echo.v2, Ubuntu:22.04:LTS: golang-github-labstack-echo.v3, Ubuntu:24.04:LTS: golang-github-labstack-echo, Ubuntu:26.10: golang-github-labstack-echo, Ubuntu:26.04:LTS: golang-github-labstack-echo&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: golang-github-labstack-echo.v2, Ubuntu:20.04:LTS: golang-github-labstack-echo.v3, Ubuntu:22.04:LTS: golang-github-labstack-echo, Ubuntu:22.04:LTS: golang-github-labstack-echo.v2, Ubuntu:22.04:LTS: golang-github-labstack-echo.v3, Ubuntu:24.04:LTS: golang-github-labstack-echo, Ubuntu:26.10: golang-github-labstack-echo, Ubuntu:26.04:LTS: golang-github-labstack-echo&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-118657</guid>
    </item>
  </channel>
</rss>
