Read the docs
TI-2026-80010 Aliases GHSA-f48p-c9v4-h7xv

Echo BodyDump captures request and response bodies without size limits

Priority LOW 38CWE-400Published · Updated

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

Fix Fixed github.com/labstack/echo/v4 (Go): 4.16.1

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
—github.com/labstack/echo/v4 (Go)4.0.0 to before 4.16.14.16.1Patch availableGHSA-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

  1. 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