CVE-2026-92284 in Caddy
Summary
by MITRE • 09/23/2026
Caddy is an extensible server platform that uses TLS by default. In version 2.11.3 and earlier, in modules/caddyhttp/replacer.go, resolving http.request.body reads the complete request body with an unbounded io.Copy before request-body middleware limits apply, allowing memory exhaustion and process termination.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in Caddy versions prior to 2.11.3 represents a critical resource management flaw within the HTTP server's request processing pipeline. As an extensible server platform that prioritizes security by enabling TLS by default, Caddy is designed to handle high volumes of web traffic efficiently. However, the specific implementation detail located in modules/caddyhttp/replacer.go introduces a significant weakness during the initial phase of request handling. Before any middleware responsible for enforcing request body size limits can execute its validation logic, the system attempts to resolve placeholders related to the HTTP request body. This resolution process triggers an unbounded io.Copy operation that reads the entire incoming request payload into memory immediately upon receipt.
This architectural oversight creates a direct path for denial of service attacks through resource exhaustion. Because the reading of the complete request body occurs prior to the application of middleware limits, there is no mechanism in place to restrict the amount of data processed during this specific placeholder resolution step. An attacker can exploit this behavior by sending HTTP requests with extremely large or infinite payloads. The server will attempt to allocate memory proportional to the size of these malicious inputs without any cap, leading rapidly to excessive memory consumption on the host system.
The operational impact of this flaw is severe and immediate. As the unbounded copy operation consumes available RAM, the Caddy process becomes increasingly unstable. Eventually, the operating system's out-of-memory killer may terminate the process, or the application itself may crash due to allocation failures. This results in a complete denial of service for all users attempting to access services hosted on that instance. The vulnerability effectively neutralizes one of the primary advantages of using Caddy as a high-performance reverse proxy and web server, rendering it vulnerable to simple yet effective resource exhaustion attacks even when configured with strict body size limits elsewhere in its middleware chain.
From a classification perspective, this issue aligns closely with CWE-400, which describes uncontrolled resource consumption. The attack vector leverages the application's failure to limit the amount of resources consumed during input processing, specifically targeting memory allocation mechanisms. In terms of offensive security frameworks such as MITRE ATT&CK, this vulnerability facilitates Denial of Service (T1499) by enabling attackers to disrupt service availability through resource exhaustion techniques. It also touches upon CWE-787, out-of-bounds write or access, in the broader context of memory safety issues that can lead to process termination, although the primary mechanism here is uncontrolled allocation rather than buffer overflow exploitation.
Mitigation for this vulnerability requires an immediate upgrade to Caddy version 2.11.3 or later, where the developers have addressed the ordering issue within the request processing pipeline. Until such an update is applied, administrators should consider implementing network-level protections, such as rate limiting and strict payload size restrictions at the load balancer or reverse proxy layer preceding Caddy. These external controls can prevent excessively large requests from reaching the vulnerable application logic, thereby mitigating the risk of memory exhaustion while a permanent patch is deployed within the server software itself.