Echo: Decompress permits unbounded gzip expansion in v4
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.
Source excerpt · OSVStreaming enforcement requires callers to handle body-read errors.
What to do
Upgrade to v4.16.1.
Apply suitable request deadlines and concurrency limits as well.
Affected packages
Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.
| Affected range | Recorded fix |
|---|---|
| From 4.0.0 before 4.16.1Semantic versions | 4.16.1 |
Version evidence: OSV · GHSA-h7wr-284f-5qvc
View original version evidence (0 explicit versions)
Affected products
Vendor version evidence. Product records are separate from automatic dependency matching.
labstack · GitHub_M
echo
1 range
labstack · GitHub_M
echo
Compare with this publisher’s ranges. This does not inspect your installation.
affected
>= 4.0.0, < 4.16.1
Other versions: unknown
Original source description
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 configured limit remain valid. Streaming enforcement requires callers to handle body-read errors.
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.
Inside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-118261View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Underlying weaknesses
The source’s classification of what caused the vulnerability.
Contributing organizations · 2
Assigning organization
Additional data publisher
What changed
Follow changes- CVE · CVE-2026-118261
Observed 2026-10-29T21:32:34.669Z · upstream updated 2026-10-29T20:54:55.973Z
Prioritization updated
before
[]
after
[ { "source": "CISA-ADP", "type": "SSVC", "role": "CISA Coordinator", "timestamp": "2026-10-29T15:28:34.378293Z", "decisions": [ { "name": "Exploitation", "value": "none" }, { "name": "Automatable", "value": "no" }, { "name": "Technical Impact", "value": "partial" } ] } ]
Large field values are marked as truncated previews. Original source snapshots remain retained.
Showing up to 50 most recent observed changes.