CVE-2026-116131 in HTTP::Body
Summary
by MITRE • 10/28/2026
HTTP::Body versions before 1.23_01 for Perl allow memory and temporary file exhaustion via an unlimited number of form fields and multipart parts.
The urlencoded parser splits the whole body on its separators at once, creating one scalar per separator before any field is stored. This costs about 90 bytes of memory per separator byte. The multipart parser creates a temporary file for every part that carries a filename. Neither parser limits how many fields or parts a body may hold.
A remote attacker can exhaust worker memory with a body made of separators, or create thousands of temporary files with one request of small file parts.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
The HTTP::Body module for Perl, prior to version 1.23_01, contains critical resource exhaustion vulnerabilities that stem from inadequate input validation and unbounded memory allocation strategies within its parsing logic. This vulnerability affects applications relying on this library to parse incoming HTTP request bodies, particularly those handling form data or multipart file uploads. The core technical flaw lies in the design of both the URL-encoded parser and the multipart parser, which fail to impose limits on the number of fields or parts they process from a single client submission. In the case of the urlencoded parser, the implementation splits the entire request body by separator characters simultaneously upon receipt. This approach results in the creation of one scalar variable for every separator byte found in the input stream. Each of these scalars consumes approximately ninety bytes of memory overhead, meaning that an attacker can trigger a linear and rapid increase in memory consumption proportional to the size of the malicious payload. There is no mechanism to cap the number of resulting fields or to limit the total memory footprint allocated for parsing form data, allowing a single request to consume significant server resources.
Similarly, the multipart parser exhibits a severe lack of constraints regarding file uploads by creating a temporary disk file for every part that includes a filename attribute. The library does not restrict the quantity of parts within a single multipart message nor does it limit the total number of files created on the filesystem during parsing. This design flaw enables an attacker to generate thousands of small, ephemeral files with a single HTTP request. While each individual file may be negligible in size, the cumulative effect includes exhausting available disk space and overwhelming the operating system's inode table or file descriptor limits. The combination of these two distinct failure modes means that both memory resources on the application server and storage resources on the underlying filesystem are vulnerable to depletion through carefully crafted HTTP requests.
The operational impact of this vulnerability is significant, primarily manifesting as a denial-of-service condition against services utilizing affected versions of HTTP::Body. A remote attacker can exploit these flaws without authentication by sending specially constructed POST requests containing either an excessively large number of form fields or a multipart body with numerous file parts. The resulting resource exhaustion leads to application crashes, worker process termination, or complete server unresponsiveness as the system runs out of memory or disk space. This type of attack is particularly dangerous in high-traffic environments where even brief periods of service disruption can have substantial business implications. Furthermore, if the affected Perl processes are part of a larger cluster, the failure of one node due to resource exhaustion could trigger cascading failures across dependent services that rely on its availability.
From a classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write in terms of memory allocation behavior and more accurately with CWE-400: Uncontrolled Resource Consumption. The specific technique used by the attacker to exhaust system resources via crafted input is categorized under MITRE ATT&CK T1496: Resource Hijacking, specifically within the sub-category of Denial of Service through resource exhaustion. Understanding these mappings helps security teams prioritize remediation efforts and align defensive measures with established industry frameworks for vulnerability management.
Mitigation strategies should focus on immediate version updates and architectural safeguards. The primary recommendation is to upgrade HTTP::Body to version 1.23_01 or later, where the developers have addressed these parsing inefficiencies by implementing appropriate limits on field counts and part quantities. For organizations unable to patch immediately due to dependency constraints, defensive coding practices must be employed at the application layer. This includes enforcing strict size limits on incoming request bodies using web server configurations such as Nginx's client_max_body_size or Apache's LimitRequestBody directives. Additionally, implementing rate limiting and connection throttling can help mitigate the impact of volumetric attacks aimed at resource exhaustion. It is also advisable to review any custom parsing logic that might bypass these library-level protections, ensuring that all input streams are validated for size and complexity before being processed by vulnerable components.