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
13 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 5.4.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 5.4.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 5.2.0 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 5.4.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 5.1.1 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 5.4.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 5.4.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 5.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In Echo v5, `ExtractIPFromRealIPHeader` checked whether the address supplied in `X-Real-IP` belonged to a trusted range instead of checking the address of the direct network peer. An untrusted client could therefore supply a loopback or private address and have it returned by `c.RealIP()` with the extractor's default trust options. Applications using this extractor for IP allowlists, IP-based rate limiting, audit logs or forwarding headers could accept a spoofed client identity. Exploitation requires that the attacker can reach Echo directly or that an intervening proxy passes through the attacker's `X-Real-IP` value. Applications using the default direct IP extractor are unaffected. Echo v4 is unaffected by this v5 regression. Affected versions and patch All v5 releases from v5.0.0 through v5.4.0 are affected. Upgrade to v5.4.1. The patch validates the direct peer before accepting a syntactically valid `X-Real-IP`…
Recommended action: Upgrade to 5.4.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 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 5.4.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 5.4.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 v5's BodyDump middleware captured a bounded prefix, drained the remaining request body while ignoring read errors, and then replaced the body with the captured prefix. With an outer BodyLimit, an unknown-length request such as an HTTP/1.1 chunked request, and a BodyDump capture limit below the BodyLimit threshold, an overflow detected during that drain could be discarded. The handler could consequently process a truncated request and return success even though the original body exceeded the configured limit. This is a conditional size-policy bypass; no general authentication bypass, production data modification or denial of service is claimed. Known-length requests rejected before BodyDump runs are unaffected by this path. Affected versions and patch All v5 releases from v5.0.0 through v5.4.0 contain the affected drain-and-replace logic. Runtime reproduction confirmed v5.4.0; source comparison confirms the same request handling in v5.0.0. Upgrade to…
Recommended action: Upgrade to 5.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On Windows, Echo’s middleware.Static using the default filesystem allows path traversal via backslashes, enabling unauthenticated remote file read outside the static root. Details In middleware/static.go, the requested path is unescaped and normalized with path.Clean (URL semantics). path.Clean does not treat \ as a path separator, so ..\ sequences remain in the cleaned path. The resulting path is then passed to currentFS.Open(...). When the filesystem is left at the default (nil), Echo uses defaultFS which calls os.Open (echo.go:792). On Windows, os.Open treats \ as a path separator and resolves ..\, allowing traversal outside the static root. Relevant code: - middleware/static.go (path unescape + path.Clean + currentFS.Open) - echo.go defaultFS.Open → os.Open This is the same class as CVE-2020-36565 (fixed in v4 by switching to OS-aware cleaning), but in v5 the path.Clean + defaultFS combination reintroduces the Windows backslash traversal. PoC Windows only. Sample code…
Recommended action: Upgrade to 5.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.