EUVD-2026-112370
GHSA-h7wr-284f-5qvc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend small gzip-compressed request to Decompress-enabled route
-
DeliveryMiddleware decodes body without size cap
-
ExploitHandler read/bind inflates body in memory
-
ExecutionRepeated/concurrent requests exhaust memory and CPU
-
ImpactService denial of service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that the application has explicitly enabled Echo v4's opt-in Decompress middleware on a reachable route AND that a handler reads or binds the decompressed request body - the middleware is not enabled by default, which is the primary limiting factor. The attack requires no authentication (PR:N) and no user interaction (UI:N) and works against affected versions 4.0.0 through 4.16.0. Exposure is reduced where the application already enforces an effective body limit AFTER decompression (BodyLimit placed after Decompress); simply limiting the compressed request size does not bound the decoded size and does not mitigate the issue. |
| Impact | This is a real but conditional availability risk, not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) describes a network-reachable, unauthenticated, low-complexity attack with an attack requirement (AT:P) and a single impact of high availability loss (VA:H), yielding 8.2 - the score is driven entirely by denial of service (CWE-400/CWE-409 decompression bomb), with zero confidentiality or integrity impact. The vuln.today decision label is 'this_week', consistent with a serious DoS that is not under active exploitation. No EPSS score was supplied, and there is no CISA KEV listing, so exploitation status is 'no public exploit identified at time of analysis' - the provided references are the fix commit, the v4.16.1 release, the GHSA advisory and patch PR #3136, all remediation artifacts rather than exploit code. The AT:P requirement and the advisory both reflect the critical caveat that the Decompress middleware is opt-in and NOT enabled by default, which materially lowers real-world exposure versus the raw 8.2. Missing signals to note explicitly: no EPSS probability and no KEV status were provided, so widespread-exploitation likelihood cannot be quantified from the input. |
| Exploit ScenarioDerived | An attacker sends a small gzip-compressed HTTP request (a decompression/zip bomb) to an Echo v4 application that has opted into the Decompress middleware on an exposed route. Because the middleware does not bound the decoded size, when the handler reads or binds the body it expands to a very large in-memory payload; repeated or concurrent such requests exhaust memory or CPU and take the service down. No public exploit code is identified, but the technique (compression bomb) is well understood and the attack is network-reachable and unauthenticated per PR:N. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Unbounded gzip expansion in Echo v4's opt-in Decompress middleware (versions 4.0.0 through 4.16.0) allows a small compressed request to decode into a very large body, consuming excessive memory or CPU when a downstream handler reads or binds it; repeated or concurrent requests can exhaust server resources and cause denial of service. The middleware is not enabled by default, so exposure is limited to applications that explicitly wire it onto a reachable route and pass the decoded body to a handler, and exposure is further reduced where an effective body limit is applied after decompression. No public exploit code has been identified at time of analysis; the vendor fixed the issue in Echo v4.16.1 by adding a configurable maximum decompressed size.
RemediationAI
Upgrade to Echo v4.16.1, the vendor-released patch (https://github.com/labstack/echo/releases/tag/v4.16.1, fix commit 3fb0ba7e17645bb65611e2a08875d0a2f65c421f), and set DecompressConfig.MaxDecompressedSize to a value appropriate for your payloads rather than relying on the 100 MiB default applied when the field is zero; note that -1 disables the cap entirely and should be avoided on internet-facing routes, and that exceeding the cap returns ErrStatusRequestEntityTooLarge (HTTP 413) via normal reads, JSON binding and XML binding, so handlers must actually check body-read errors for the enforcement to take effect. Where upgrading is not immediately possible, the vendor-listed workarounds are to disable gzip request decompression on exposed routes (removing the decompression path entirely, at the cost of no longer accepting compressed request bodies) or to place BodyLimit after Decompress so the application limit applies to the decoded bytes rather than the compressed ones - placing the limit before Decompress does not mitigate the issue because the compressed size does not bound the expanded size. The vendor additionally recommends suitable request deadlines and concurrency limits to blunt repeated or concurrent abuse. Applications that already enforce an effective post-decompression body limit have reduced exposure but should still upgrade to obtain the built-in cap.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Echo is a Go HTTP web framework, distributed as the Go module github.com/labstack/echo/v4. Its Decompress middleware wraps an incoming request whose Content-Encoding is gzip in a transparent decompressing reader, so handlers can treat the request body as plaintext. Because gzip output is not bounded by input size, a highly compressed payload can expand by orders of magnitude; the middleware passed the decoded stream through without any cap, which is the improper handling of highly compressed data (CWE-409) that manifests as uncontrolled resource consumption (CWE-400) once a handler performs c.Bind(), JSON/XML decoding, or a full io.ReadAll on the body. The root cause is architectural rather than a parsing bug: any limit applied to the compressed Content-Length does not bound the number of bytes the decompressor emits, so a routine size check on the wire form provides a false sense of protection. The upstream fix commit adds a DecompressConfig.MaxDecompressedSize option (defaulting to 100 MiB when left at zero, with -1 explicitly disabling the cap); reads that exceed the cap surface as ErrStatusRequestEntityTooLarge (HTTP 413), including through JSON and XML binding, while bodies exactly at the configured limit remain valid, and streaming enforcement depends on callers actually handling body-read errors. The same commit also introduces capture limits for the BodyDump middleware (MaxRequestBytes and MaxResponseBytes, each defaulting to 5 MiB with -1 disabling), which bounds debugging middleware from buffering arbitrarily large payloads but is separate from the decompression cap. The trigger conditions are deployment-dependent: applications that never enable Decompress, or that disable gzip request decompression on exposed routes, are not affected.
Know when Go gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Network-reachable, unauthenticated, low-complexity request against an enabled middleware; impact is availability only (DoS), with no confidentiality or integrity effect, so A:H and C:N/I:N.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
Echo is a Go web framework. From 4.0.0 until 4.16.1, Echo v4's opt-in Decompress middleware exposes a gzip-decoded request stream without limiting its expanded size. A small compressed request can expand into a very large body when a handler reads or binds it, consuming excessive memory or CPU and allowing repeated or concurrent requests to cause denial of service. The middleware is not enabled by default, and limiting only the compressed request size does not bound the decoded size. This issue is fixed in 4.16.1.
Technical POC Analysis
The flaw is uncontrolled resource consumption, CWE-400, with the advisory also classifying it as CWE-409, improper handling of highly compressed data.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
CVE-2026-118261 is a high-severity (CVSS 8.2) unbounded gzip expansion vulnerability in Echo v4's opt-in Decompress middleware, affecting versions 4.0.0 through 4.16.0. Applications that have explicitly enabled this middleware on reachable routes and lack post-decompression body limits are at risk of memory or CPU exhaustion, leading to denial of service. Leadership should care because service disruption could impact customers and operations, but exposure is limited only to those who have opted in and not applied mitigating controls.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
The net/http package in Go through 1.6 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and there
Critical certificate validation bypass in Go crypto/tls during session resumption. If ClientCAs or RootCAs fields are mu
net/url in Go before 1.11.13 and 1.12.x before 1.12.8 mishandles malformed hosts in URLs, leading to an authorization by
Casdoor through 4.4.0 exposes its instance-wide built-in JWT signing private key unmasked through the /api/get-certs and
Host header injection in Nezha 2.2.3's OAuth2 redirect endpoint (/api/v1/oauth2/{provider}) allows an unauthenticated re
Session cross-wiring in SUSE NeuVector before 5.6.1 allows an unauthenticated remote attacker to obtain another user's a
Unauthenticated path traversal in Uber Kraken through 0.1.29 allows remote attackers to read files outside the configure
The "go get" implementation in Go 1.9.4, when the -insecure command-line option is used, does not validate the import pa
Denial of service in Temporal Server allows an authenticated caller holding at least namespace read permission to crash
Account takeover in Klever-Go's KleverUpdateAccountPermission built-in (all versions prior to 1.7.20) allows an attacker
Maliciously crafted on-chain account names processed by Klever-Go prior to 1.7.20 are spliced into Elasticsearch _bulk r
Exploit-DB