Echo BodyDump captures request and response bodies without size limits
Key facts
- Attack vector
- —
- Privileges required
- —
- User interaction
- —
- Attack complexity
- —
- Impact type
- Denial of service
- Confidentiality · integrity · availability
- —
- Fix status
- Fixed
No CVSS vector from any source. Fix status from GitHub. Impact type from CWE-400.
Summary
Echo v4 versions from 4.0.0 before 4.16.1 are affected, and CISA's KEV catalog does not list this issue. The opt-in BodyDump middleware, which is not enabled by default, reads complete request bodies into memory and keeps complete response bodies without a capture limit, so a client that submits large requests to a route using BodyDump can trigger large allocations before the handler runs. Large responses, including those whose size a client can influence, also cause an unbounded capture allocation. Repeated or concurrent requests can exhaust process memory and cause denial of service (CWE-400, CWE-770).
Written with Claude Haiku 5.5 from the sources below · 2026-10-28
Description from the GitHub advisory
## 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](https://github.com/labstack/echo/releases/tag/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 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](https://github.com/labstack/echo/commit/3fb0ba7e17645bb65611e2a08875d0a2f65c421f). ## 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](https://github.com/labstack/echo/pull/3105).
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| — | github.com/labstack/echo/v4 (Go) | 4.0.0 to before 4.16.1 | 4.16.1 | Patch available | GHSA-f48p-c9v4-h7xv |
- github.com/labstack/echo/v4 (Go) Vendor— Affected 4.0.0 to before 4.16.1 Fixed in 4.16.1 Patch available GHSA-f48p-c9v4-h7xv
Remediation
Upgrade to Echo v4.16.1. The patch adds BodyDumpConfig.MaxRequestBytes and MaxResponseBytes, each defaulting to 5 MiB when zero, and a value of -1 restores unlimited capture. Until the upgrade is applied, disable BodyDump on exposed routes, particularly large uploads and downloads, or enforce body-size limits before BodyDump and independently bound the responses the application generates.
Written with Claude Haiku 5.5 from the sources below · 2026-10-28
- Fix · GHSA-f48p-c9v4-h7xv github.com/labstack/echo/v4 (Go) Fixed in 4.16.1 Advisory →
Timeline
- 2026-10-23 Threatist record created from GHSA-f48p-c9v4-h7xv
References
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences