CVE-2026-118260: 
Wolfi vulnerability analysis and mitigation

CVE-2026-118260 is an Uncontrolled Resource Consumption vulnerability in the BodyDump middleware of the Echo Go web framework (labstack/echo v4). The middleware reads complete request bodies into memory before handlers execute and retains complete response bodies for the dump callback without any capture size limits, enabling unauthenticated attackers to exhaust process memory and cause denial of service. It affects Echo v4 versions from 4.0.0 up to (but not including) 4.16.1, and was disclosed on October 22, 2026. It carries a CVSS v4.0 base score of 8.2 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). When the opt-in BodyDump middleware is enabled, it calls io.ReadAll() on the full request body before passing control to the application handler, and separately buffers the entire response body into a bytes.Buffer for the dump callback — neither operation imposes a size cap. An unauthenticated network attacker with access to any route protected by BodyDump can submit arbitrarily large request bodies or trigger large response bodies, causing repeated or concurrent unbounded memory allocations that exhaust the process heap. Notably, external request-size limits (e.g., a reverse proxy body limit) may constrain the request-side vector but do not bound response capture, leaving a residual attack surface (GitHub Advisory, Fix Commit).

Successful exploitation results in process memory exhaustion and application crash, constituting a denial-of-service condition. Because the vulnerability is reachable by unauthenticated clients and requires only network access to a route using BodyDump, availability impact is high. There is no confidentiality or integrity impact — the vulnerability does not expose data or allow modification of application state (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at the time of disclosure. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is 0.0, reflecting low current exploitation probability. Exploitation requires that the target application has explicitly enabled the BodyDump middleware, which is not active by default, reducing the overall attack surface (Feedly, GitHub Advisory).

1. Reconnaissance: Identify applications built on Echo v4 (versions 4.0.0–4.16.0) that expose HTTP endpoints. Indicators may include Go-specific response headers or framework fingerprints.
2. Identify BodyDump-enabled routes: Probe application routes for logging or debugging behavior consistent with BodyDump middleware (e.g., request/response body logging in application logs or side-channel responses).
3. Send large request bodies: Submit HTTP POST or PUT requests with very large bodies (e.g., hundreds of megabytes) to a BodyDump-enabled route. Since io.ReadAll() is called without a limit, each request causes a large heap allocation before the handler runs.
4. Trigger large responses: Alternatively or additionally, craft requests that cause the application to generate large response bodies (e.g., requesting large data exports), which are fully buffered by the middleware's response capture.
5. Repeat or parallelize: Send repeated or concurrent such requests to compound memory pressure, ultimately exhausting the process heap and causing an out-of-memory crash or severe degradation (GitHub Advisory).

• Network: Unusually large HTTP POST/PUT requests (hundreds of MB) to application endpoints; high volume of concurrent large-body requests from one or few source IPs.
• Logs: Application or access logs showing repeated requests with very large Content-Length values to the same route; Go runtime out-of-memory (OOM) panic stack traces in application logs referencing middleware/body_dump.go or io.ReadAll.
• Process: Rapid, sustained growth in Go process RSS/heap memory (/proc/<pid>/status or runtime metrics); OOM kills recorded in system logs (dmesg, journalctl) for the Echo application process.
• Application Metrics: Sudden spike in memory usage correlated with incoming request volume; increased GC pressure or GC pause times visible in Go runtime metrics (GitHub Advisory).

Upgrade Echo v4 to version 4.16.1 or later, which introduces BodyDumpConfig.MaxRequestBytes and MaxResponseBytes fields, each defaulting to 5 MiB (set to -1 to restore unlimited capture). The fix uses io.LimitReader for request capture and a custom bodyDumpLimitedWriter for response capture, ensuring complete bodies are still delivered to handlers and clients while only the logged/callback data is bounded. If immediate upgrade is not possible, disable BodyDump middleware on routes exposed to untrusted clients, or enforce upstream body-size limits (e.g., via a reverse proxy or Echo's BodyLimit middleware) and independently bound application response sizes (GitHub Advisory, Release v4.16.1).

The vulnerability was reported by community contributor @q490107865 and patched by the LabStack Echo maintainers in a coordinated release that also addressed several other security issues (WebSocket proxy vulnerabilities, decompression bomb, and dependency upgrades). The fix commit incorporates request-body preservation work from @jakezwang (PR #3105). No significant broader media coverage or notable external researcher commentary has been identified beyond the GitHub advisory and standard vulnerability aggregator entries (GitHub Advisory, Release v4.16.1).