CVE-2026-115817 in Starman
Summary
by MITRE • 10/25/2026
Starman versions before 0.4019 for Perl allow a stalled request body to hold a worker indefinitely, as read_timeout covers only the headers.
Content-Length and chunked request bodies are read with blocking reads and no deadline. A client that sends complete headers and then stalls or trickles the body keeps the worker waiting until it disconnects.
A remote attacker can take every worker with a few such connections, five with the default worker count, so the server stops answering requests.
Version 0.4019 applies read_timeout to each wait for body data and adds a body_timeout limit, 300 seconds by default, on the total time to read a body.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in Starman versions prior to 0.4019 represents a critical resource exhaustion flaw rooted in improper input validation and timeout configuration for HTTP request bodies. As an asynchronous Perl web server, Starman relies on worker processes to handle incoming connections efficiently. The core technical deficiency lies in the handling of Content-Length and chunked transfer encoding headers versus their corresponding body data. While the initial read_timeout setting correctly applies a deadline to the reception of HTTP headers, it fails to extend this protection to the subsequent reading of the request payload. This architectural oversight means that once the headers are successfully parsed, the worker process enters a blocking state to await incoming bytes from the client without any associated timeout mechanism or deadline for termination.
This design flaw creates a severe availability risk through denial-of-service attacks. A remote attacker can exploit this behavior by establishing connections with Starman and transmitting valid HTTP headers followed by an incomplete or stalled request body. By deliberately slowing down the transmission of data, known as slowloris-style attack vectoring, or simply disconnecting after sending headers but before completing the body transfer, the attacker forces the worker process to remain in a waiting state indefinitely. Since each such connection occupies one worker thread, and typical configurations often utilize a limited pool of workers, an adversary can exhaust all available resources with relatively few connections. For instance, with the default worker count set to five, only five stalled requests are required to render the server completely unresponsive to legitimate traffic, effectively causing a total service outage.
From a classification perspective, this vulnerability aligns with CWE-400, which denotes Uncontrolled Resource Consumption, specifically manifesting as resource exhaustion due to insufficient timeout controls on input operations. It also maps closely to ATT&CK technique T1499, Endpoint Denial of Service, particularly the sub-category of Slowloris or similar low-and-slow attacks that aim to consume server resources over time rather than through high-volume traffic spikes. The lack of a deadline for body reads violates fundamental principles of secure coding regarding resource lifecycle management and defensive programming against malformed or malicious client behavior.
The remediation strategy implemented in Starman version 0.4019 directly addresses these deficiencies by enforcing strict temporal boundaries on all phases of request processing. The update extends the read_timeout logic to cover every wait for body data, ensuring that individual chunks are subject to timeout constraints. Furthermore, a new configuration parameter called body_timeout was introduced, which imposes an absolute limit on the total duration allowed for reading an entire request body. By defaulting this value to 300 seconds, administrators gain control over how long they will tolerate slow or stalled uploads and downloads. This dual-layered approach ensures that even if individual chunk reads are delayed, the overall connection cannot persist indefinitely, thereby preserving worker availability and maintaining service continuity against such exploitation attempts.