Hi,
The following vulnerabilities were published for golang-github-labstack-echo.
Note the security-tracker references contains as well direct links to
the rspective GHSA's and information on fixing commits. For unstable
though it might be sensible to move to the newest upstream version?
CVE-2026-118260[0]:
| Echo is a Go web framework. From 4.0.0 until 4.16.1, Echo v4's opt-
| in BodyDump middleware reads complete request bodies into memory
| before handlers run and retains complete response bodies for the
| dump callback without capture limits. An unauthenticated client that
| can reach a route using BodyDump can submit large bodies or
| influence large responses, causing repeated or concurrent
| allocations that exhaust process memory. BodyDump is not enabled by
| default, and external request limits may reduce request-side
| exposure but do not bound response capture. This issue is fixed in
| 4.16.1.
CVE-2026-118261[1]:
| Echo is a Go web framework. From 4.0.0 until 4.16.1, Echo v4's opt-
| in Decompress middleware exposes a gzip-decoded request stream
| without limiting its expanded size. A small compressed request can
| expand into a very large body when a handler reads or binds it,
| consuming excessive memory or CPU and allowing repeated or
| concurrent requests to cause denial of service. The middleware is
| not enabled by default, and limiting only the compressed request
| size does not bound the decoded size. This issue is fixed in 4.16.1.
CVE-2026-118262[2]:
| Echo is a Go web framework. From 4.15.0 until 4.16.1 and 5.4.1,
| Echo's Proxy middleware can retain a handler, copy goroutines, and
| network connections after a WebSocket client disconnects when the
| upstream keeps its connection open. The raw proxy waits for both
| copy directions without reliably closing the peer connection when
| one direction ends, including when a rejected upgrade response uses
| HTTP keep-alive. Repeated connections can accumulate resources and
| cause denial of service, depending on proxy-route accessibility,
| upstream behavior, and connection deadlines. This issue is fixed in
| 4.16.1 and 5.4.1.
CVE-2026-118264[3]:
| Echo is a Go web framework. From 4.0.0 until 4.16.1 and 5.4.1,
| Echo's Proxy middleware selects a raw tunnel from a client WebSocket
| upgrade request before verifying that the configured upstream
| accepted the upgrade. If the upstream rejects the upgrade with an
| ordinary keep-alive response, later HTTP requests on the connection
| are sent directly to that upstream without passing through Echo's
| router or route-specific middleware. This can bypass authentication
| or authorization enforced only by Echo routes, but requires an
| accessible proxy route, a cooperating rejected-upgrade response, and
| a target without independent upstream authorization. This issue is
| fixed in 4.16.1 and 5.4.1.
CVE-2026-118266[4]:
| Echo is a Go web framework. Prior to 4.16.0 and 5.4.0, Echo's
| 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 that a
| browser-submitted request can control, 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. This issue is
| fixed in 4.16.0 and 5.4.0.
CVE-2026-118651[5]:
| Echo is a Go web framework. 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 therefore make upstream services
| receive a spoofed client address, undermining IP-based access
| controls, rate limiting, audit logging, or geographic restrictions
| that trust Echo's forwarded identity. This issue is fixed in Echo
| 5.4.0.
CVE-2026-118652[6]:
| Echo is a Go web framework. Prior to 4.16.0 and 5.4.0, Context.JSONP
| and Context.JSONPBlob concatenate an unvalidated callback value into
| a JavaScript response. A route that passes attacker-controlled input
| as the callback can return executable script syntax, allowing
| reflected cross-site scripting when a user loads the crafted
| response. The vulnerable jsonPBlob path performs no callback
| validation or escaping, and exploitation requires an application
| route that exposes attacker control over the callback argument. This
| issue is fixed in 4.16.0 and 5.4.0.
CVE-2026-118653[7]:
| Echo is a Go web framework. From 4.0.0 until 5.1.0, Context.RealIP
| falls back to client-supplied X-Forwarded-For or X-Real-IP values
| when Echo.IPExtractor is unset, and the default RateLimiter uses
| that result as its client identifier. A remote attacker can rotate
| arbitrary forwarded-address values to obtain new rate-limit buckets
| and bypass IP-based throttling used for controls such as brute-force
| or request-volume protection. This issue is fixed in Echo v5.1.0.
CVE-2026-118654[8]:
| Echo is a Go web framework. Prior to 4.16.0 and 5.4.0, Echo's static
| file handlers can normalize dot segments after route matching and
| serve a file through a public static route even though the
| corresponding direct path is protected by route-level middleware. An
| unauthenticated attacker can read files that an application intended
| to protect with route-level middleware, when those files are also
| reachable through a static filesystem mount after path
| normalization. This vulnerability is the result of an incomplete fix
| for CVE-2026-55677. This issue is fixed in 4.16.0 and 5.4.0.
CVE-2026-118655[9]:
| Echo is a Go web framework. Prior to 4.15.3 and 5.2.0,
| middleware.Static can decode an already decoded Request.URL.Path a
| second time. Double-encoded separators can consequently be
| reconstructed before filesystem resolution. This can reach a file
| under a guarded route when the static middleware is registered
| globally. This issue is fixed in 4.15.3 and 5.2.0.
CVE-2026-118656[10]:
| Echo is a 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. This issue is fixed in
| 4.16.0 and 5.4.0.
CVE-2026-118657[11]:
| 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.
CVE-2026-118658[12]:
| 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.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-118260
https://www.cve.org/CVERecord?id=CVE-2026-118260
[1] https://security-tracker.debian.org/tracker/CVE-2026-118261
https://www.cve.org/CVERecord?id=CVE-2026-118261
[2] https://security-tracker.debian.org/tracker/CVE-2026-118262
https://www.cve.org/CVERecord?id=CVE-2026-118262
[3] https://security-tracker.debian.org/tracker/CVE-2026-118264
https://www.cve.org/CVERecord?id=CVE-2026-118264
[4] https://security-tracker.debian.org/tracker/CVE-2026-118266
https://www.cve.org/CVERecord?id=CVE-2026-118266
[5] https://security-tracker.debian.org/tracker/CVE-2026-118651
https://www.cve.org/CVERecord?id=CVE-2026-118651
[6] https://security-tracker.debian.org/tracker/CVE-2026-118652
https://www.cve.org/CVERecord?id=CVE-2026-118652
[7] https://security-tracker.debian.org/tracker/CVE-2026-118653
https://www.cve.org/CVERecord?id=CVE-2026-118653
[8] https://security-tracker.debian.org/tracker/CVE-2026-118654
https://www.cve.org/CVERecord?id=CVE-2026-118654
[9] https://security-tracker.debian.org/tracker/CVE-2026-118655
https://www.cve.org/CVERecord?id=CVE-2026-118655
[10] https://security-tracker.debian.org/tracker/CVE-2026-118656
https://www.cve.org/CVERecord?id=CVE-2026-118656
[11] https://security-tracker.debian.org/tracker/CVE-2026-118657
https://www.cve.org/CVERecord?id=CVE-2026-118657
[12] https://security-tracker.debian.org/tracker/CVE-2026-118658
https://www.cve.org/CVERecord?id=CVE-2026-118658
Regards,
Salvatore