Repository navigation
Update module github.com/labstack/echo/v4 to v4.16.1 [SECURITY] - #7
Merged
1bsv-renovate[bot] merged 1 commit intoOct 27, 2026
Conversation
1bsv-renovate
Bot
deleted the
renovate/go-github.com-labstack-echo-v4-vulnerability
branch
October 27, 2026 20:58
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v4.16.0→v4.16.1Echo: BodyDump captures request and response bodies without size limits in v4
GHSA-f48p-c9v4-h7xv
More information
Details
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.MaxRequestBytesandMaxResponseBytes, each defaulting to 5 MiB when zero. A value of-1explicitly restores unlimited capture. The complete request remains readable by the handler and the complete response is delivered to the client; only the callback's captured data is bounded. Request close behavior and read errors are preserved.Fix commit.
Workarounds
Disable BodyDump on exposed routes, particularly large uploads and downloads. Alternatively, enforce body-size limits before BodyDump and independently bound the responses that the application generates.
Credits
Reported by @q490107865. The patch also incorporates request-body preservation work from @jakezwang in #3105.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Echo: Rejected WebSocket upgrades can bypass Echo route-level access controls
GHSA-cxf3-9h37-7rr8
More information
Details
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 shows the missing upgrade-response validation in v4.0.0.
Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.
Fix commits: v4, v5.
Workarounds
Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.
Credits
Reported by @Duodum.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Echo: Decompress permits unbounded gzip expansion in v4
GHSA-h7wr-284f-5qvc
More information
Details
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-1explicitly disables the limit. Reading beyond the cap returnsErrStatusRequestEntityTooLarge(HTTP 413), including through JSON and XML binding. Bodies exactly at the configured limit remain valid. Streaming enforcement requires callers to handle body-read errors.Fix commit.
Workarounds
Disable gzip request decompression on exposed routes, or place BodyLimit after Decompress so the application limit applies to decoded bytes. Apply suitable request deadlines and concurrency limits as well.
Credits
Reported by @q490107865. The exact-limit behavior incorporates @Shubham-Padkonde's work in #3136.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Echo: WebSocket proxy can retain connections and handlers after client disconnect
GHSA-9969-6676-49h5
More information
Details
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. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.
Fix commits: v4, v5.
Workarounds
Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.
Credits
Reported by @irisitymichaelgrundberg.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Echo: WebSocket proxy can retain connections and handlers after client disconnect
GHSA-9969-6676-49h5
More information
Details
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. The patch uses Go's HTTP reverse proxy, preserves ordinary HTTP handling for rejected upgrades, and closes both sides of a WebSocket tunnel when either direction ends. It also covers an upstream that receives client EOF but deliberately keeps its side open.
Fix commits: v4, v5.
Workarounds
Disable WebSocket proxy routes until upgrading, or apply bounded connection lifetimes and resource limits at the frontend and upstream. Server idle timeouts alone may not cover hijacked WebSocket connections.
Credits
Reported by @irisitymichaelgrundberg.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Echo: Rejected WebSocket upgrades can bypass Echo route-level access controls
GHSA-cxf3-9h37-7rr8
More information
Details
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 shows the missing upgrade-response validation in v4.0.0.
Upgrade to v4.16.1 or v5.4.1. The patch routes WebSocket upgrades through Go's HTTP reverse proxy and enters a tunnel only after a valid upstream upgrade response. Rejected upgrades remain ordinary HTTP requests.
Fix commits: v4, v5.
Workarounds
Reject WebSocket upgrade requests before they reach affected Echo proxy routes, or enforce authorization independently at every upstream resource. Merely returning a non-101 response from the upstream does not prevent the vulnerable raw tunnel.
Credits
Reported by @Duodum.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Echo: BodyDump captures request and response bodies without size limits in v4
GHSA-f48p-c9v4-h7xv
More information
Details
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.MaxRequestBytesandMaxResponseBytes, each defaulting to 5 MiB when zero. A value of-1explicitly restores unlimited capture. The complete request remains readable by the handler and the complete response is delivered to the client; only the callback's captured data is bounded. Request close behavior and read errors are preserved.Fix commit.
Workarounds
Disable BodyDump on exposed routes, particularly large uploads and downloads. Alternatively, enforce body-size limits before BodyDump and independently bound the responses that the application generates.
Credits
Reported by @q490107865. The patch also incorporates request-body preservation work from @jakezwang in #3105.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Echo: Decompress permits unbounded gzip expansion in v4
GHSA-h7wr-284f-5qvc
More information
Details
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-1explicitly disables the limit. Reading beyond the cap returnsErrStatusRequestEntityTooLarge(HTTP 413), including through JSON and XML binding. Bodies exactly at the configured limit remain valid. Streaming enforcement requires callers to handle body-read errors.Fix commit.
Workarounds
Disable gzip request decompression on exposed routes, or place BodyLimit after Decompress so the application limit applies to decoded bytes. Apply suitable request deadlines and concurrency limits as well.
Credits
Reported by @q490107865. The exact-limit behavior incorporates @Shubham-Padkonde's work in #3136.
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
labstack/echo (github.com/labstack/echo/v4)
v4.16.1Compare Source
Security fixes
Upgrade with
go get github.com/labstack/echo/v4@v4.16.1.Go 1.26 or later is now required to use patched
golang.org/x/dependencies. Build deployments with a supported, patched Go toolchain.golang.org/x/netto v0.60.0 and related dependencies, addressing GO-2026-6617, GO-2026-6612, GO-2026-6611, GO-2026-6610 and GO-2026-6603.Behavior to review when upgrading
BodyDumpConfig.MaxRequestBytesandMaxResponseBytescontrol capture limits. Zero selects the 5 MiB default;-1disables a limit. These limits affect captured logging data only: handlers and clients still receive complete bodies.DecompressConfig.MaxDecompressedSizecontrols the decompressed-body limit. Zero selects the 100 MiB default;-1disables it. Apply any smaller application body limit after decompression, and handle request-body read errors.The proxy removes incoming
Forwardedheaders as defensive hardening. Backends relying on that header should use forwarding headers generated from the configured trusted IP extractor and scheme. WebSocket requests now honor the configured proxy transport, response modifier, target path and query in the same way as HTTP requests;wsandwsstargets remain supported.Other changes
This release includes router fixes for escaped colons, inline verbs and parameter storage, binding support for OpenAPI date formats, and documentation updates. Benchmark comparisons now run only for pull requests with shorter samples.
Thanks to @Duodum, @irisitymichaelgrundberg, @q490107865, @Hama1cco, @jakezwang and @Shubham-Padkonde for reports and contributions, and to the contributors credited in the individual commits.
Validation: upstream lint checks and race tests passed on Linux, macOS and Windows with Go 1.26 and 1.27. Local tests on patched toolchains, vet, staticcheck and govulncheck also passed; govulncheck reported no reachable vulnerabilities. The module graph still contains an advisory for the unused, unmaintained
golang.org/x/crypto/openpgppackage (GO-2026-5932), which Echo does not import and for which no fixed dependency version is available.Full changelog: labstack/echo@v4.16.0...v4.16.1
Configuration
📅 Schedule: (in timezone Etc/UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.