Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
14 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
`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. 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` Threat model 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. This is the primary scenario. The application is vulnerable by default with no…
Recommended action: Upgrade to 4.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Echo v5.2.0 contains a bypass of the fix for GHSA-vfp3-v2gw-7wfq. The fix rejects encoded path separators such as `%2F` and `%5C` before static file path unescaping, but two traversal forms still bypass route-level middleware protections for static files. The primary bypass uses encoded dot-dot segments. A request such as `/public/%2E%2E/admin/secret.txt` passes the encoded-separator guard, is unescaped to `public/../admin/secret.txt`, then `path.Clean` resolves it to `admin/secret.txt`. If `/admin/*` is protected by middleware but the static filesystem is mounted at `/`, the protected file is returned through the public static route. A second bypass exists when `UseEscapedPathForMatching=true`. In that mode, the router normalizes encoded separators before the static handler checks the wildcard. The handler receives a decoded wildcard with no `%` characters, so the encoded-separator guard does not run on the original encoded path. Impact An unauthenticated attacker can…
Recommended action: Upgrade to 4.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Commit a9ede66a (PR #3006, issue #2599) silently fixed a path traversal vulnerability in the Echo web framework's static file middleware. Vulnerability The static middleware double-unescaped URL paths. Go's net/http already decodes Request.URL.Path, but middleware/static.go unconditionally called url.PathUnescape() again: ```go // BEFORE (vulnerable) pathUnescape := true ``` This reassembled path traversal sequences from double-encoded input. An attacker could send GET /%2e%2e%2fsecret.txt or /..%252fsecret.txt and the double-unescape would produce ../secret.txt. Fix ```go // AFTER (fixed) pathUnescape := false ``` The commit's test TestStatic_percentEncodedTraversalIsBlocked explicitly verifies traversal vectors are blocked. Impact Arbitrary file read from server filesystem via percent-encoded path traversal. References - Fix: https://github.com/labstack/echo/commit/a9ede66a - Issue: https://github.com/labstack/echo/issues/2599 - PR:…
Recommended action: Upgrade to 4.15.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Echo's dedicated open-redirect guard, `sanitizeURI`, decides whether a redirect target is a local path by inspecting exactly two byte positions: `uri[0]` and `uri[1]`. If the value begins with a control character such as a tab or a newline, followed by a separator pair, the guard does not fire and the value is written to the `Location` header unchanged. Browsers remove tab and newline characters from URLs before parsing them, and treat a backslash as a forward slash for HTTP and HTTPS URLs. A `Location` value of ``/\t/attacker.example`` is therefore resolved by the browser as an absolute URL on `attacker.example`. Confirmed end to end in a headless browser. Technical background The guard `middleware/slash.go:144` (duplicated verbatim at `echo.go:958`): ```go func sanitizeURI(uri string) string { // double slash `\\`, `//` or even `\/` is absolute uri for browsers and by redirecting request to that uri // we are vulnerable to open redirect attack. so replace all…
Recommended action: Upgrade to 4.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The c.Scheme() method in Echo (context.go:162-181) trusts the X-Forwarded-Proto, X-Forwarded-Protocol, and X-Url-Scheme request headers without validating that the value is http or https. The WWWRedirect() and NonWWWRedirect() middlewares use this unsanitized scheme to construct redirect URLs, allowing an attacker to inject arbitrary URI schemes into the Location response header. Affected Components - context.go:162-181 - Scheme() method returns attacker-controlled value verbatim - middleware/redirect.go:172-184 - redirectWWW/redirectNonWWW use unsanitized scheme Proof of Concept Confirmed injectable schemes: javascript, data, vbscript, file, ftp, ssh, telnet, gopher. Only WWWRedirect() and NonWWWRedirect() (and WithConfig variants) are affected. HTTPSRedirect, HTTPSWWWRedirect, HTTPSNonWWWRedirect are NOT affected (they hardcode https://). Impact - Open redirect to arbitrary scheme URLs when app is not behind a proxy that strips X-Forwarded-Proto - Cache poisoning when…
Recommended action: Upgrade to 4.15.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When `middleware.Static` is mounted globally (`e.Use(middleware.Static(...))`) and an application relies on a route- or group-level middleware guard to restrict a path that also falls under the served static root, a `%2F`-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for `StaticFS`/`StaticDirectoryHandler` in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the `middleware.Static` path. In addition, the `StaticConfig.EnablePathUnescaping` docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case. This is not path traversal: no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and `%2F`-encoded forms of the same path. Details Root cause — the router and the static handler…
Recommended action: Upgrade to 4.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The `Context.JSONP`, `Context.JSONPBlob`, and internal `jsonPBlob` helper in `context.go` directly concatenate the caller-supplied `callback` parameter into a JavaScript response without any validation, escaping, or allow-listing. This creates a high-impact reflected XSS that can be triggered by any route passing attacker-controlled data (query string, form, header, path param, etc.) into the callback. Present in current master and v5.1.0 (latest release). Vulnerable Code (verbatim) ```go func (c *Context) jsonPBlob(code int, callback string, i any) (err error) { c.writeContentType(MIMEApplicationJavaScriptCharsetUTF8) c.response.WriteHeader(code) if _, err = c.response.Write([]byte(callback + "(")); err != nil { return } if err = c.echo.JSONSerializer.Serialize(c, i, ""); err != nil { return } if _, err = c.response.Write([]byte(");")); err != nil { return } return } func (c *Context) JSONP(code int, callback string, i any) (err error) { return…
Recommended action: Upgrade to 4.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The `MethodOverride` middleware accepts any non-empty string as the override target method — including safe methods (GET, HEAD, OPTIONS, TRACE) — when rewriting a POST request. When `MethodOverride` is registered before `CSRF` in the post-routing middleware chain (`e.Use()`), it rewrites the request method to a safe method before `CSRF` evaluates it. The CSRF middleware then skips token validation for the now-safe method, allowing state-changing POST handlers to execute without any CSRF check. Both the legacy token path and the modern `Sec-Fetch-Site` protection path are bypassed simultaneously. Affected Component - `middleware/method_override.go` — `MethodOverrideConfig.ToMiddleware()` (lines 55–71): no whitelist on the override target method - `middleware/csrf.go` — `CSRFConfig.ToMiddleware()` (lines 188–189): safe-method bypass branch reads the already-rewritten method - `middleware/csrf.go` — `checkSecFetchSiteRequest()` (line 283): `Sec-Fetch-Site` safe check also…
Recommended action: Upgrade to 4.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/labstack/echo/v4 >= 4.15.0, < 4.16.1
Fixed in
4.16.1· Vendor fix available
Issue
Impact Echo's Proxy middleware could retain a handler, copy goroutines and network connections after a WebSocket client disconnected if the upstream kept its connection open. The raw proxy waited for both copy directions to finish without reliably closing the other connection when one direction ended. Rejected upgrade responses with HTTP keep-alive were one way to trigger this behavior. Repeated connections can accumulate resources and cause denial of service. The impact depends on the proxy route's accessibility, upstream behavior and configured connection deadlines. This is a medium-severity resource-retention issue; no confidentiality or integrity impact is claimed. Affected versions and patch Affected versions are v4.15.0 through v4.16.0 and v5.0.0 through v5.4.0. The regression was introduced by commit e2133320c7, merged in #2852. Upgrade to v4.16.1 or v5.4.1.…
Recommended action: Upgrade to 4.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Echo v4's opt-in Decompress middleware exposed a gzip-decoded request stream without limiting its expanded size. A small compressed request could therefore produce a very large decoded body. Handlers that read or bind that body could consume excessive memory or CPU, and repeated or concurrent requests could cause denial of service. The middleware is not enabled by default. A limit on the compressed request size alone does not bound the decompressed size. Applications that already apply an effective body limit after decompression have reduced exposure. Affected versions and patch Echo v4 versions through v4.16.0 are affected. Upgrade to v4.16.1. The patch adds `DecompressConfig.MaxDecompressedSize`, defaulting to 100 MiB when zero. A value of `-1` explicitly disables the limit. Reading beyond the cap returns `ErrStatusRequestEntityTooLarge` (HTTP 413), including through JSON and XML binding. Bodies exactly at the…
Recommended action: Upgrade to 4.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Echo's Proxy middleware selected a raw tunnel when the client requested a WebSocket upgrade, before validating whether the configured upstream accepted it. If the upstream returned an ordinary HTTP response and kept the connection alive, subsequent HTTP requests on that connection were forwarded directly to the same upstream without passing through Echo's router or route-specific middleware. This can bypass authentication or authorization enforced only at Echo's routes. Exploitation requires an accessible proxy route, an upstream that rejects the upgrade without closing the connection, and a target resource on that upstream without independent authorization. The issue does not provide arbitrary-host proxying or bypass the upstream's own authentication. Affected versions and patch The raw proxy implementation is present throughout the v4 and v5 release lines up to v4.16.0 and v5.4.0. Runtime reproductions confirmed v4.15.0, v4.16.0, v5.0.0 and v5.4.0; source history also…
Recommended action: Upgrade to 4.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Echo v4's opt-in BodyDump middleware read complete request bodies into memory and retained complete response bodies without a capture limit. A client able to submit large requests to a route using BodyDump could cause large allocations before the application handler ran. Large responses, including responses whose size can be influenced by a client, also caused an additional unbounded capture allocation. Repeated or concurrent requests can exhaust process memory and cause denial of service. BodyDump is not enabled by default. Deployments with effective request limits may reduce the request-side exposure; response capture requires separate consideration. Affected versions and patch Echo v4 versions through v4.16.0 are affected. Upgrade to v4.16.1. The patch adds `BodyDumpConfig.MaxRequestBytes` and `MaxResponseBytes`, each defaulting to 5 MiB when zero. A value of `-1` explicitly restores unlimited capture. The…
Recommended action: Upgrade to 4.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to improper sanitization of user input on Windows, the static file handler allows for directory traversal, allowing an attacker to read files outside of the target directory that the server has permission to read.
Recommended action: Upgrade to 4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Labstack Echo v4.8.0 was discovered to contain an open redirect vulnerability via the Static Handler component. This vulnerability can be leveraged by attackers to cause a Server-Side Request Forgery (SSRF). Version 4.9.0 contains a patch for the issue.
Recommended action: Upgrade to 4.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.