Labstack
Monthly
Path-based access control bypass in the LabStack Echo Go web framework (versions prior to 4.15.3 and 5.2.0) lets remote attackers retrieve protected static files without authorization. The flaw stems from the router matching routes on the raw encoded path (keeping %2F literal) while StaticDirectoryHandler decodes %2F to '/' before filesystem resolution, so a crafted URL slips past route-level guards. There is no public exploit identified at time of analysis and no CISA KEV listing; CVSS is 7.5 (confidentiality-only).
Echo's WWWRedirect() and NonWWWRedirect() middlewares build the Location header from Context.Scheme(), which returns the raw value of the X-Forwarded-Proto, X-Forwarded-Protocol or X-Url-Scheme request header without checking it is a web scheme, so an attacker who controls that header can make the redirect point at an arbitrary URI scheme such as javascript, data, file or gopher. Applications built on github.com/labstack/echo/v4 before 4.15.2 or /v5 before 5.1.1 are affected only if they mount one of those two redirect middlewares and run without an edge proxy that overwrites or strips the forwarded-scheme headers; the HTTPSRedirect, HTTPSWWWRedirect and HTTPSNonWWWRedirect variants hardcode https:// and are unaffected. The advisory documents a public proof-of-concept request verified against a live server, and per the CVSS vector (AC:H, UI:R) a victim must also interact with the manipulated redirect for impact, which keeps realistic exposure narrow; KEV status was not provided.
Spoofed forwarded-scheme headers let remote clients defeat Echo's HTTPS enforcement: Context.Scheme() in LabStack Echo before 4.16.0 and 5.4.0 reads X-Forwarded-Proto, X-Forwarded-Protocol, X-Forwarded-Ssl and X-Url-Scheme from any request without validating the source, so an unauthenticated attacker (CVSS PR:N) who reaches an HTTP listener directly can send 'X-Forwarded-Proto: https' and skip HTTPSRedirect entirely, or, behind a TLS-terminating proxy that passes client headers through, send 'X-Forwarded-Proto: http' to suppress the Strict-Transport-Security header while the browser still receives the response over HTTPS. The attack requires victim interaction (UI:R) and a man-in-the-middle position or a header-passing proxy to convert the downgrade into real data exposure, which is why it rates 5.9 rather than critical, and risk drops sharply where a trusted proxy overwrites these headers and direct backend access is blocked. Fixes ship in v4.16.0 and v5.4.0; proof-of-concept curl and Go test snippets are published in the advisory, though no CISA KEV entry exists and the issue is triaged as this-month rather than emergency.
An open redirect in the Go web framework Echo lets an attacker craft a link on a trusted domain that sends victims to an arbitrary external site when the AddTrailingSlash or RemoveTrailingSlash middleware is configured with a redirect status set. The framework's sanitizeURI guard inspects only the first two bytes of the redirect target, so a literal TAB byte (delivered as %09) placed before the separator pair, for example /%09/attacker.example/x/, slips past the check and is written unmodified into the Location header, where browsers strip the TAB and resolve the value as an absolute URL on the attacker's host. All users of echo/v4 below 4.16.0 and echo/v5 below 5.4.0 are affected only if those middlewares are registered with a non-zero RedirectCode; a public PoC reference exists and the mechanism was confirmed end to end in a headless browser, but there is no CISA KEV entry and no EPSS data in the supplied sources. This is a medium-severity issue (CVSS 6.1, CWE-601) whose exploitability depends on user interaction: the victim has to click and follow the crafted link.
CSRF protection in Labstack Echo can be skipped entirely when the MethodOverride middleware rewrites a POST to a safe method (GET, HEAD, OPTIONS or TRACE) before the CSRF middleware runs, letting the original state-changing POST handler execute without token validation or a Sec-Fetch-Site check. Affected are echo v4 before 4.16.0 and echo v5 before 5.4.0, but only in a specific non-default setup: MethodOverride registered with e.Use() ahead of CSRF and configured with a browser-settable getter such as MethodFromForm('_method') or MethodFromQuery, plus an authenticated victim lured to an attacker page (CVSS 3.1 5.3, AV:N/AC:H/PR:N/UI:R, C:N/I:H/A:N). The default X-HTTP-Method-Override header getter is not reachable from a cross-site form, and applications using e.Pre() as documented or placing CSRF first are unaffected; there is no CISA KEV entry and the advisory supplies a public proof-of-concept reproducer rather than confirmed exploitation in the wild.
Unauthenticated remote file read in Echo web framework versions 5.0.0-5.0.2 on Windows allows attackers to traverse outside the static root directory and access arbitrary files via backslash path sequences in requests. The vulnerability stems from improper path normalization where path.Clean() does not treat backslashes as separators, but the underlying os.Open() call on Windows does, enabling directory traversal. Public exploit code exists for this medium-severity vulnerability, though a patch is available in version 5.0.3.
Labstack Echo v4.8.0 was discovered to contain an open redirect vulnerability via the Static Handler component. Rated critical severity (CVSS 9.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Path-based access control bypass in the LabStack Echo Go web framework (versions prior to 4.15.3 and 5.2.0) lets remote attackers retrieve protected static files without authorization. The flaw stems from the router matching routes on the raw encoded path (keeping %2F literal) while StaticDirectoryHandler decodes %2F to '/' before filesystem resolution, so a crafted URL slips past route-level guards. There is no public exploit identified at time of analysis and no CISA KEV listing; CVSS is 7.5 (confidentiality-only).
Echo's WWWRedirect() and NonWWWRedirect() middlewares build the Location header from Context.Scheme(), which returns the raw value of the X-Forwarded-Proto, X-Forwarded-Protocol or X-Url-Scheme request header without checking it is a web scheme, so an attacker who controls that header can make the redirect point at an arbitrary URI scheme such as javascript, data, file or gopher. Applications built on github.com/labstack/echo/v4 before 4.15.2 or /v5 before 5.1.1 are affected only if they mount one of those two redirect middlewares and run without an edge proxy that overwrites or strips the forwarded-scheme headers; the HTTPSRedirect, HTTPSWWWRedirect and HTTPSNonWWWRedirect variants hardcode https:// and are unaffected. The advisory documents a public proof-of-concept request verified against a live server, and per the CVSS vector (AC:H, UI:R) a victim must also interact with the manipulated redirect for impact, which keeps realistic exposure narrow; KEV status was not provided.
Spoofed forwarded-scheme headers let remote clients defeat Echo's HTTPS enforcement: Context.Scheme() in LabStack Echo before 4.16.0 and 5.4.0 reads X-Forwarded-Proto, X-Forwarded-Protocol, X-Forwarded-Ssl and X-Url-Scheme from any request without validating the source, so an unauthenticated attacker (CVSS PR:N) who reaches an HTTP listener directly can send 'X-Forwarded-Proto: https' and skip HTTPSRedirect entirely, or, behind a TLS-terminating proxy that passes client headers through, send 'X-Forwarded-Proto: http' to suppress the Strict-Transport-Security header while the browser still receives the response over HTTPS. The attack requires victim interaction (UI:R) and a man-in-the-middle position or a header-passing proxy to convert the downgrade into real data exposure, which is why it rates 5.9 rather than critical, and risk drops sharply where a trusted proxy overwrites these headers and direct backend access is blocked. Fixes ship in v4.16.0 and v5.4.0; proof-of-concept curl and Go test snippets are published in the advisory, though no CISA KEV entry exists and the issue is triaged as this-month rather than emergency.
An open redirect in the Go web framework Echo lets an attacker craft a link on a trusted domain that sends victims to an arbitrary external site when the AddTrailingSlash or RemoveTrailingSlash middleware is configured with a redirect status set. The framework's sanitizeURI guard inspects only the first two bytes of the redirect target, so a literal TAB byte (delivered as %09) placed before the separator pair, for example /%09/attacker.example/x/, slips past the check and is written unmodified into the Location header, where browsers strip the TAB and resolve the value as an absolute URL on the attacker's host. All users of echo/v4 below 4.16.0 and echo/v5 below 5.4.0 are affected only if those middlewares are registered with a non-zero RedirectCode; a public PoC reference exists and the mechanism was confirmed end to end in a headless browser, but there is no CISA KEV entry and no EPSS data in the supplied sources. This is a medium-severity issue (CVSS 6.1, CWE-601) whose exploitability depends on user interaction: the victim has to click and follow the crafted link.
CSRF protection in Labstack Echo can be skipped entirely when the MethodOverride middleware rewrites a POST to a safe method (GET, HEAD, OPTIONS or TRACE) before the CSRF middleware runs, letting the original state-changing POST handler execute without token validation or a Sec-Fetch-Site check. Affected are echo v4 before 4.16.0 and echo v5 before 5.4.0, but only in a specific non-default setup: MethodOverride registered with e.Use() ahead of CSRF and configured with a browser-settable getter such as MethodFromForm('_method') or MethodFromQuery, plus an authenticated victim lured to an attacker page (CVSS 3.1 5.3, AV:N/AC:H/PR:N/UI:R, C:N/I:H/A:N). The default X-HTTP-Method-Override header getter is not reachable from a cross-site form, and applications using e.Pre() as documented or placing CSRF first are unaffected; there is no CISA KEV entry and the advisory supplies a public proof-of-concept reproducer rather than confirmed exploitation in the wild.
Unauthenticated remote file read in Echo web framework versions 5.0.0-5.0.2 on Windows allows attackers to traverse outside the static root directory and access arbitrary files via backslash path sequences in requests. The vulnerability stems from improper path normalization where path.Clean() does not treat backslashes as separators, but the underlying os.Open() call on Windows does, enabling directory traversal. Public exploit code exists for this medium-severity vulnerability, though a patch is available in version 5.0.3.
Labstack Echo v4.8.0 was discovered to contain an open redirect vulnerability via the Static Handler component. Rated critical severity (CVSS 9.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.